We used to use DAAB for some legacy business objects and now we've decided to use TransactionScope for some new business objects. Now we have to call the new business object within the old business object code. The old business object code would look like this when the new business object is called within it:
Database db = DatabaseFactory.CreateDatabase();
// create connection instance
DbConnection dbConnection = db.CreateConnection();
dbConnection.Open(); // open connection
// create transaction instance & start the transaction
DbTransaction dbTransaction = dbConnection.BeginTransaction();
// do some old business object insert/update
// now call the new business object
newBO.Update();
// commit transaction
dbTransaction.Commit();
The new business object has code in it as follows:
using (TransactionScope scope = new TransactionScope())
{
// do some update/insert
scope.Complete();
}
The question is, is this going to work?
My current belief is that it will work based on:
- this MSDN article which says that if the transaction was created outside the scope, the creator of the transaction is still responsible for commit/rolling it back - which is my case basically, it will work perfectly if this is true.
- a partial trace of the TransactionScope I complete also indicates that a commit is not necessarily committed on dispose of TransactionScope but I couldn't completely finish the trace so I'm not 100% sure if my trace was accurate
However, there are a few articles on TransactionScope including this post on SO which doesn't mention this scenario and just say that the transaction(s) will be rolled back without specifying if the transaction was created by the TransactionScope itself or not.
So my question: from Your experience, which is the case?
a) transaction created outside of the TransactionScope is committed on the dispose of the scope
OR
b) transaction created outside the TransactionScope is not committed on the disposing and the creator has to take care of rollback & commit?
