Sharing a transaction via CriteriaBase?

Sharing a transaction via CriteriaBase?

Old forum URL: forums.lhotka.net/forums/t/11727.aspx


JCardina posted on Tuesday, November 27, 2012

I have a read only object which fetches inventory values.  It needs to optionally accept a transaction object because it's sometimes used to simply display values to the user but at other times it's used by an inventory adjustment object which needs to check current inventory before making changes inside an isolated transaction.

I'm experimenting with passing the transaction as part of a complex criteria (I also need two Guid's so there are three parameters).

When I try to specify the managed propery for the transaction like this inside my CriteriaBase class I get a complaint from visual studio:

public static readonly PropertyInfo<IDbTransaction> TransactionProperty = RegisterProperty<IDbTransaction>(c => c.TransactionProperty);

"Cannot convert lambda expression to type 'Csla.PropertyInfo<System.Data.IDbTransaction>' because it is not a delegate type"

Is there any reason why I need to use the managed properties in my CriteriaBase derived class?  I'm a little confused as to why I need them to simply pass data from one object to another.

Is there a better way to share transactions between objects than this?  

RockfordLhotka replied on Tuesday, November 27, 2012

This is the reason for the various transaction/connection/context types in the Csla.Data namespace.

I discuss their use in the 'Using CSLA 4' ebook, and they are specifically designed to "flow" connections/transactions between your DAL components without having to deal with the complexity you are currently facing.

JCardina replied on Wednesday, November 28, 2012

Ahhh!  I've read all the ebooks but I missed that somehow the first time around, I'll dig through it, thanks Rocky!

[I don't know how I missed that before, was it added in a later revision from the first book release?]

JCardina replied on Monday, December 03, 2012

Just an FYI for any future readers of this issue: If you can't use the built in transaction types in the csla namespace as I can't it *is* possible to use the far simpler method of setting a shared transaction property in the enlisted other object.  You just need to set it's backing property to nonserializable and it works fine.

So just create a property in the secondary object that will be enrolled in the transaction that holds the shared transaction, give it a backing field set to nonserializable and Bob's your lobster.

Copyright (c) Marimer LLC