Accessing diposed transaction object in Mindscape.LightSpeed.UnitOfWork.SystemTransactionCompletedEvent

It seems there is a problem in the private method Mindscape.LightSpeed.UnitOfWork.SystemTransactionCompletedEvent, which is assigned to the Transaction.Current.TransactionCompleted as the event handler in the overriden UnitOfWork.SaveChanges(bool reset) method. Here is fragment of the event handler's code: private void SystemTransactionCompletedEvent(..., TransactionEventArgs e) { e.Transaction.TransactionCompleted -= SystemTransactionCompletedEvent; ...... // here is the "diposed transaction" exception thrown } e.Transaction is not null, but disposed. So accessing any member of this disposed instance leads to throwing corresponding exception. This situation arises when running this fragment of code: Guid id = Guid.Empty; using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required)) { ...... // real code removed // context.UnitOfWorkScope.Current is UnitOfWork instance context.UnitOfWorkScope.Current.Add(newData); context.UnitOfWorkScope.Current.SaveChanges(); // *** this line leads to throwing some exception, because of foreign key constraints *** ....... //real code removed id = newData.Id; scope.Complete(); }// *** at this line current thread breaks when "accessing disposed transaction" exception is thrown - seeing that in the thread and call stack windows. Resume: One thread calls UnitOfWork.SaveChanges, UnitOfWork.SaveChanges assigns the event hanlder method for the TransactionCompleted. When peforming save, exception is thrown, the created TransactionScope instance is disposed (the last line in the using(....){...} block), then asynchronously, in second thread SystemTransactionCompletedEvent event handler is called, but the transaction object is already disposed. We think the problem is the code of the SystemTransactionCompletedEvent method, since it supposes, that transaction is not disposed. Are we right? Can we avoid the "diposed transaction" exception in some way, e.g. using some synchronization objects? Do we (for you) obviously ignore some aspect of Lightspeed? Thanks a lot in advance for your reactions.

It seems there is a problem in the private method

Mindscape.LightSpeed.UnitOfWork.SystemTransactionCompletedEvent,

which is assigned to the Transaction.Current.TransactionCompleted as the event handler in the overriden

UnitOfWork.SaveChanges(bool reset)

method.

Here is fragment of the event handler's code:

private void SystemTransactionCompletedEvent(..., TransactionEventArgs e)
    {
      e.Transaction.TransactionCompleted -= SystemTransactionCompletedEvent;
...... // here is the "diposed transaction" exception thrown
    }

e.Transaction is not null, but disposed. So accessing any member of this disposed instance leads to throwing corresponding exception.

This situation arises when running this fragment of code:

Guid id = Guid.Empty;
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
{
...... // real code removed

// context.UnitOfWorkScope.Current is UnitOfWork instance

context.UnitOfWorkScope.Current.Add(newData);
context.UnitOfWorkScope.Current.SaveChanges(); // *** this line leads to throwing some exception, because of foreign key constraints ***
....... //real code removed
  id = newData.Id;
  scope.Complete();
}// *** at this line current thread breaks when "accessing disposed transaction" exception is thrown - seeing that in the thread and call stack windows.

 

Resume:

One thread calls UnitOfWork.SaveChanges, UnitOfWork.SaveChanges assigns the event hanlder method for the TransactionCompleted. When peforming save, exception is thrown, the created TransactionScope instance is disposed (the last line in the using(....){...} block), then asynchronously, in second thread SystemTransactionCompletedEvent event handler is called, but the transaction object is already disposed.

We think the problem is the code of the SystemTransactionCompletedEvent method, since it supposes, that transaction is not disposed.

Are we right?
Can we avoid the "diposed transaction" exception in some way, e.g. using some synchronization objects? Do we (for you) obviously ignore some aspect of Lightspeed?

Thanks a lot in advance for your reactions.

v System.Transactions.Transaction.get_TransactionInformation() v Mindscape.LightSpeed.UnitOfWork.SystemTransactionCompletedEvent(Object sender, TransactionEventArgs e) v C:\development\projects\wirmim\Program.v2.0\Lib\Mindscape.LightSpeed\Src\Framework\UnitOfWork.cs:řádek 514 v System.Transactions.TransactionCompletedEventHandler.Invoke(Object sender, TransactionEventArgs e) v System.Transactions.InternalTransaction.FireCompletion() v System.Transactions.TransactionStatePromotedAborted.EnterState(InternalTransaction tx) v System.Transactions.TransactionStateDelegatedAborting.ChangeStatePromotedAborted(InternalTransaction tx) v System.Transactions.DurableEnlistmentDelegated.Aborted(InternalEnlistment enlistment, Exception e) v System.Transactions.SinglePhaseEnlistment.Aborted() v System.Data.SqlClient.SqlDelegatedTransaction.Rollback(SinglePhaseEnlistment enlistment) v System.Transactions.TransactionStateDelegatedAborting.EnterState(InternalTransaction tx) v System.Transactions.TransactionStateDelegated.Rollback(InternalTransaction tx, Exception e) v System.Transactions.Transaction.Rollback() v System.Transactions.TransactionScope.InternalDispose() v System.Transactions.TransactionScope.Dispose() v BluePixel.Wirmim.Extensions.LightSpeedEntity.Add(WirmimContext context, B newData) v C:\development\projects\wirmim\Program.v2.0\BluePixel.Wirmim\Extensions\LightSpeedEntity.cs:řádek 88 v BluePixel.Wirmim.Extensions.LightSpeedEntity.Save(WirmimContext context, B newData) v C:\development\projects\wirmim\Program.v2.0\BluePixel.Wirmim\Extensions\LightSpeedEntity.cs:řádek 135 v WorkingDataLayerContext.Save(B businessObject, Type typeOfExceptionWhichShouldNotBeLogged) v C:\development\projects\wirmim\Program.v2.0\BluePixel.Wirmim.UnitTestCommon\WorkingDataLayerContext.cs:řádek 132 v WorkingDataLayerContext.Save(B businessObject) v C:\development\projects\wirmim\Program.v2.0\BluePixel.Wirmim.UnitTestCommon\WorkingDataLayerContext.cs:řádek 107 v Stores.BusinessLayer.Test.OrderedItemTest.ConcurencyChangedPropertiesTestWithTwoUnitsOfWork() v C:\development\projects\wirmim\Program.v2.0\BluePixel.Wirmim.Stores\Stores.BusinessLayer.Test\OrderedItemTest.cs:řádek 265

Hi,

We are seeing the same behaviour when TransactionScope wraps a unitOfWork. Are suggested solutions/work arounds?

Regards

We have not been able to reproduce this.  We expect .NET to call the TransactionCompleted event before it disposes the transaction (and this is what appears to happen in our tests) -- otherwise the TransactionEventArgs would be useless.

Could you provide us with a simple console project or NUnit test that reproduces this behaviour?  Thanks!

 Hi,

We have created the sample console project which runs in windows 7 but not windows xp.

On windows xp, it throws the error:

Cannot access a disposed object.
Object name: 'Transaction'.

Stack trace:

   at System.Transactions.Transaction.get_TransactionInformation()
   at Mindscape.LightSpeed.UnitOfWork.(Object , TransactionEventArgs )
   at System.Transactions.TransactionCompletedEventHandler.Invoke(Object sender, TransactionEventArgs e)
   at System.Transactions.InternalTransaction.FireCompletion()
   at System.Transactions.TransactionStatePromotedCommitted.EnterState(InternalTransaction tx)
   at System.Transactions.TransactionStatePromotedBase.ChangeStatePromotedCommitted(InternalTransaction tx)
   at System.Transactions.DurableEnlistmentDelegated.Committed(InternalEnlistment enlistment)
   at System.Transactions.SinglePhaseEnlistment.Committed()
   at System.Data.SqlClient.SqlDelegatedTransaction.SinglePhaseCommit(SinglePhaseEnlistment enlistment)
   at System.Transactions.TransactionStateDelegatedCommitting.EnterState(InternalTransaction tx)
   at System.Transactions.TransactionStateDelegated.BeginCommit(InternalTransaction tx, Boolean asyncCommit, AsyncCallback asyncCallback, Object asyncState)
   at System.Transactions.CommittableTransaction.Commit()
   at System.Transactions.TransactionScope.InternalDispose()
   at System.Transactions.TransactionScope.Dispose()
   at LSTestConsole.Manager.SettleHireOrder() in C:\temp\lightspeed\LsTestConsole\Src\Manager.cs:line 39
   at LSTestConsole.Program.Main(String[] args) in C:\temp\lightspeed\LsTestConsole\Src\Program.cs:line 16
   at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

Steps to reproduce

1) Extract the zip file

2) Restore the database file DB\LsTestDb.bak

3) Open solution with Visaul studio 2008

4) F5 and run console app

Simple console test app attached in this post

Thanks!  Unfortunately, it looks like the zip file went awry -- could you re-post please?  You can attach a file via the Options tab.

You're too fast for me -- ignore previous message!  Thanks again!

This appears to be a confirmed bug in the .NET Framework:

http://social.msdn.microsoft.com/forums/en-US/windowstransactionsprogramming/thread/937ba955-bd4a-425d-9f35-f1286b140a60/

http://connect.microsoft.com/VisualStudio/feedback/details/294197/getting-a-objectdisposedexception-in-a-transactioncompleted-when-transactionscope-ends

I am not sure what your code is trying to do but it was not clear to me why you needed two nested units of work here.  I found that if you do all the work in one unit of work, or dispose the first unit of work before starting the second unit of work, the exception does not occur.