Rocky...new class in future release?

xxxJasonxxx posted on Tuesday, September 16, 2008

Rocky:

I noticed you included a "ConnectionManager" class in CSLA 3.5 for sharing database connections between objects.  Is there any chance we'll see a similar "TransactionManager" class in a future version of CSLA?  I've run into an unusual situation where I need to share, not a connection, but a transaction between editable root objects.  (or is that functionality already there and I've missed it?)

Thanks,

Jason

detritus replied on Tuesday, September 16, 2008

Check this: http://forums.lhotka.net/forums/thread/26158.aspx

ajj3085 replied on Tuesday, September 16, 2008

I would think that shared a connection on which a transaction is active would have each BO use that transaction.

xxxJasonxxx replied on Tuesday, September 16, 2008

ajj3085....if you are given an SqlTransaction object you can derive the related SqlConnection object, but not the other way around (look at the members on the 2 classes and you'll see what I mean).

tmg4340 replied on Tuesday, September 16, 2008

True... but if you use the new TransactionScope object (in the System.Transactions namespace), or the TransactionalAttribute that's in the framework (which directs the DataPortal to use a TransactionScope), then you can let .NET automatically enlist your objects in an active transaction.  This is the new "preferred approach" to transactional programming within .NET.  And if you use the same connection, then the transaction is not promoted to a distributed one.  It's this scenario that spawned the creation of the ConnectionManager class.

Having said that, if you need something similar for transactions, you could certainly create one yourself, using the ConnectionManager class as a model.

HTH

- Scott

ajj3085 replied on Tuesday, September 16, 2008

But if you're using ConnectionManager, you're getting the exact same connection object each time it's called.  So some other BO that wants to save two roots at once, for example, would use the connection manager to start the connection, set a transaction, and then call an internal SaveSelf method on each root object to save.

They'll use connection manager as well.. and get the connection already opened and with a transaction set.

Check out the code I posted earlier; it works, I do the same thing only using a ContextManager because I'm using linq... but the DataContext is equivolent to a connection.

RockfordLhotka replied on Tuesday, September 16, 2008

This is not a bad idea though. While TransactionScope is the better model overall, it doesn't work with Oracle or other non-SQL Server databases, and people might need to resort to Manual transactions. In that case a TransactionManager would be helpful.

I'll add it to the wish list.

xxxJasonxxx replied on Tuesday, September 16, 2008

Thanks Rocky!

In the meantime, I'll research the "TransactionScope" you guys suggested.

nermin replied on Tuesday, September 16, 2008