http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I'm having the same problem over here. The problem is indeed that the Dispose causes the Commits to be executed on a background thread, and returns immediately. For me this is a big problem, because after the commit my application (which is a console application) exits, and some of the commits are never executed. To make things worse: there is no way of knowing when the commits are done. Even the Transaction.TransactionCompleted event is fired before all commits have executed. The only solution I have found so far is to either do a Thread.Sleep for a certain time, or to build in the loop below to check if some worker threads are still busy. If you have found a better solution, I would be glad to know... int workerThreads = 0; int completionPortThreads = 0; int maxWorkerThreads; int maxCompletionPortThreads; ThreadPool.GetMaxThreads(out maxWorkerThreads, out maxCompletionPortThreads); while(workerThreads!=maxWorkerThreads || completionPortThreads!=maxCompletionPortThreads) { Thread.Sleep(10); ThreadPool.GetAvailableThreads(out workerThreads, out completionPortThreads); } http://ayende.com/4528/who-stole-my-transaction#comment17http://ayende.com/4528/who-stole-my-transaction#comment17Sun, 18 Jul 2010 10:36:38 GMTThis is very worrying. What's the point of transactions where you can't be sure if they've been committed or not? http://ayende.com/4528/who-stole-my-transaction#comment16http://ayende.com/4528/who-stole-my-transaction#comment16Tue, 01 Jun 2010 15:50:38 GMTFrank, With Volatile, you don't actually get DTC http://ayende.com/4528/who-stole-my-transaction#comment15http://ayende.com/4528/who-stole-my-transaction#comment15Sun, 30 May 2010 11:04:28 GMTEnlistVolatile works as you expect but the stack trace looks very different - don't know enough about all this business to see where the exact differences are. All in all it is an amazing find indeed. Looks like the EnlistmentNotification implementations out there don't really commit in the Commit implementation of the EnlistmentNotification instance, as this apparently would be a pretty bad place to do so. http://ayende.com/4528/who-stole-my-transaction#comment14http://ayende.com/4528/who-stole-my-transaction#comment14Sun, 30 May 2010 09:38:36 GMTJohn, There is no IDbTransaction used anywhere here. http://ayende.com/4528/who-stole-my-transaction#comment13http://ayende.com/4528/who-stole-my-transaction#comment13Sun, 30 May 2010 06:29:30 GMTThe documentation For IDBTransaction says thatit is for use with relational databases. It should probably read that it is for use with a database that implements locking strategies. Given that RavenDB does not use locks, but rather MVCC, would it be possible to create your own non-IDBTransaction implementation so that MSDTC would not be utilized? http://ayende.com/4528/who-stole-my-transaction#comment12http://ayende.com/4528/who-stole-my-transaction#comment12Sun, 30 May 2010 00:46:08 GMTGreg, The problem isn't with the async, the problem is that Dispose returns before the transaction is actually committed. http://ayende.com/4528/who-stole-my-transaction#comment11http://ayende.com/4528/who-stole-my-transaction#comment11Sat, 29 May 2010 20:50:00 GMTSasha, That is a _big_ problem, what happen if you don't rely on locks for transactions? Case in point, and how we got this error, is a case where we work in a lock free transactional system (MVCC). If you read immediately after the transaction, you don't get locked, you get the _committed version_, which isn't what you just finished committing. http://ayende.com/4528/who-stole-my-transaction#comment10http://ayende.com/4528/who-stole-my-transaction#comment10Sat, 29 May 2010 20:49:19 GMTIf you enable tracing on System.Transactions, you'll see that the transactions are committing and disposing when the using block goes out of scope, but the notification callback sometimes happens after the TransactionScope constructors are called on the next iteration. This leads me to believe that it's probably using an AsyncCallback http://ayende.com/4528/who-stole-my-transaction#comment9http://ayende.com/4528/who-stole-my-transaction#comment9Sat, 29 May 2010 18:38:04 GMTBoth Prepare() and Commit() execute on a thread different from the main thread, that executes TransactionScope.Dispose(). The documentation is accurate in that you will not observe the Dispose() method returning before the Prepare() method has been synchronously called and the DTC decided to commit the transaction. However, my understanding of the documentation (and the actual implementation) is that the Commit() method is called after the transaction outcome has been decided, and all the parties involved have no way of effecting any changes to the transaction. If everyone properly uses transactions or at least locks everything properly, there shouldn't be any visible problem as a result of this. For example, say that after the end of the tx scope you start another transaction that relies on the changes committed by the first transaction. The first transaction would not have released its locks before the Commit() method returned, so the second transaction will wait for these locks if it relies on the same data. In other words, how is this such a big problem? http://ayende.com/4528/who-stole-my-transaction#comment8http://ayende.com/4528/who-stole-my-transaction#comment8Sat, 29 May 2010 16:06:43 GMTSorry - my failure to get Rollback called was a bug on my side. But your observation still stands. http://ayende.com/4528/who-stole-my-transaction#comment7http://ayende.com/4528/who-stole-my-transaction#comment7Sat, 29 May 2010 15:52:15 GMTWeird. It appears that you're right. I also failed to get Rollback being called after forcing rollback from the prepare method by calling preparingEnlistment.ForceRollback(). I hope some from the framework team would answer this. Have you filed a Connect bug on this? (I know you don't believe in Connect, but still). http://ayende.com/4528/who-stole-my-transaction#comment6http://ayende.com/4528/who-stole-my-transaction#comment6Sat, 29 May 2010 15:43:25 GMTDo you still get the error if you use call the TransactionScope constructor with TransactionScopeOption.RequiresNew? http://ayende.com/4528/who-stole-my-transaction#comment5http://ayende.com/4528/who-stole-my-transaction#comment5Sat, 29 May 2010 14:31:27 GMTSteve, Yes http://ayende.com/4528/who-stole-my-transaction#comment4http://ayende.com/4528/who-stole-my-transaction#comment4Sat, 29 May 2010 13:46:09 GMTIs it a distributed transaction (therefore managed by MSDTC) ? http://ayende.com/4528/who-stole-my-transaction#comment3http://ayende.com/4528/who-stole-my-transaction#comment3Sat, 29 May 2010 12:10:26 GMTRelease & Debug With & without debugger. Inlining doesn't matter http://ayende.com/4528/who-stole-my-transaction#comment2http://ayende.com/4528/who-stole-my-transaction#comment2Sat, 29 May 2010 11:13:00 GMTDebug or Release build? Running under debugger? Perhaps disable inlining? http://ayende.com/4528/who-stole-my-transaction#comment1http://ayende.com/4528/who-stole-my-transaction#comment1Sat, 29 May 2010 10:37:32 GMT