{"id":421,"date":"2011-11-18T22:58:46","date_gmt":"2011-11-18T11:58:46","guid":{"rendered":"http:\/\/ntsblog.homedev.com.au\/?p=421"},"modified":"2013-01-24T02:22:13","modified_gmt":"2013-01-23T15:22:13","slug":"distributed-transaction-failure-race-condition","status":"publish","type":"post","link":"https:\/\/ntsblog.homedev.com.au\/index.php\/2011\/11\/18\/distributed-transaction-failure-race-condition\/","title":{"rendered":"Distributed Transaction Failure &#8211; Race Condition"},"content":{"rendered":"<div id=\"ntsbl-594056105\" class=\"ntsbl-before-content ntsbl-entity-placement\"><script async src=\"\/\/pagead2.googlesyndication.com\/pagead\/js\/adsbygoogle.js?client=ca-pub-6288941070289539\" crossorigin=\"anonymous\"><\/script><ins class=\"adsbygoogle\" style=\"display:inline-block;width:728px;height:90px;\" \ndata-ad-client=\"ca-pub-6288941070289539\" \ndata-ad-slot=\"9356781486\"><\/ins> \n<script> \n(adsbygoogle = window.adsbygoogle || []).push({}); \n<\/script>\n<\/div><p>I have a process that is using MSDTC (Microsoft Distributed Transaction Co-ordinator) to manage the transaction.<\/p>\n<p>The transaction is controlled inside a c# .Net windows form executable that manages the transaction by the TransactionScope() object.<\/p>\n<p>The transaction is maintained across 2 SQL server and an Oracle server and it all works&#8230; most of the time.<\/p>\n<p>All transactions are opened inside a using statement, as follows <\/p>\n<p>[csharp]<br \/>\nusing (TransactionScope scope = new TransactionScope())<br \/>\n[\/csharp]<br \/>\nOr similar.<\/p>\n<p>The overview of the .exe is it monitors a queue of jobs to process. It processes the work inside the transaction successfully commits, and then after that updates the status on the job queue to success or failure.<\/p>\n<p>When there is an application error, the program throws an exception which means it ends the main transaction and in an outer transaction updates the status to failure.<\/p>\n<p>Intermittently when the core logic was throwing errors on  many jobs the entire process would fail with the following error:<\/p>\n<pre>Connection currently has transaction enlisted.  Finish current transaction and retry.<\/pre>\n<p>But it was intermittent. I had the same 12 jobs throwing errors on every run and sometimes it would crash with the above error after 2 jobs, 8 jobs, 4 jobs or it would actually not crash at all. On my development box I could not replicate it at all?<\/p>\n<p>So I figured I had a race condition.<br \/>\n<H2>The fix<\/H2><br \/>\nAfter the main transaction block of code and before opening the next TransactionScope object to update the status, I put a 100ms sleep.<br \/>\n[csharp]<br \/>\n    \/\/ Stop race condition<br \/>\n    System.Threading.Thread.Sleep(100);<\/p>\n<p>    item.Success = false; \/\/ &lt;&#8211; this is my object for updating the success or failure<br \/>\n    using (TransactionScope scope = new TransactionScope())<br \/>\n    {<br \/>\n        context.SubmitChanges();<br \/>\n        scope.Complete();<br \/>\n    }<br \/>\n[\/csharp]<\/p>\n<p>The problem has disappeared. I think the re-opening of a new TransactionScope() object did not allow enough time for MSDTC to close the previous transaction and it was crashing.<\/p>\n<p>Cheers<br \/>\nJohn<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I have a process that is using MSDTC (Microsoft Distributed Transaction Co-ordinator) to manage the transaction. The transaction is controlled inside a c# .Net windows [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-421","post","type-post","status-publish","format-standard","hentry","category-c"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/posts\/421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/comments?post=421"}],"version-history":[{"count":0,"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/posts\/421\/revisions"}],"wp:attachment":[{"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/media?parent=421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/categories?post=421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ntsblog.homedev.com.au\/index.php\/wp-json\/wp\/v2\/tags?post=421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}