none
Distributed transaction failure? RRS feed

  • Question

  • Hi All,

     

    In some application we’ve the distributed transaction, which combine request in two separate SQL 2005 Servers. We are using a TransactionScope, as it recommended in MSDN. Nothing special:

     

    using (TransactionScope tsTran = new TransactionScope())

    {

    // create first connection:

           using (SqlConnection sqlCn1 = <NEW_CONNECTION_2_FIRST_SQL> )

           {

                  using (SqlCommand sqlCmd1 = sqlCn1.CreateCommand())

    {

          

    sqlCmd1.ExecuteNonQuery();

     

    // create second connection:

    using (SqlConnection sqlCn2 = <NEW_CONNECTION_2_SECOND_SQL> )

    {

    using (SqlCommand sqlCmd2 = sqlCn2.CreateCommand())

    {

                        

    sqlCmd2.ExecuteNonQuery(); // Here get SqlException

    }

    }

    }

           }

     }

     

    But: We’ve got SqlException with “New request is not allowed to start because it should come with valid transaction descriptor” then more then one transaction executing at once.

     

    Any suggestions?

    Thursday, June 21, 2007 5:58 PM

All replies

  • Are you calling a stored procedure that operates transactionally on a table in a threaded environment?

     

    Thanks,

     

    John (MSFT)

    Thursday, June 21, 2007 9:20 PM
  • Yes, I am.

    From 10 up to around thousand threads...

     

    Seems this problem is part of this: http://support.microsoft.com/?id=916002

    But, I've got outsides feedbacks, where shown what this is not final solving:

     

    Cit.:

    System.Transactions.TransactionScope is unreliable when involved in rollbacks of successive TransactionScope scopes, one after the next. Instead of getting expected errors, transactions fail to start, and you get exceptions with the Mesage "New request is not allowed to start because it should come with valid transaction descriptor."

    Does not matter if run in debug mode, or run from command line in debug mode or release mode.

    A select statement must preceed the insert in the same overal transaction scope.

    A trigger must exist on the table that is selected and then inserted.

    Does not matter if transaction scope work happens on a second thread or the program's main thread.

     

    This is similar to posting FDBK23449

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=b19ac45c-1e5e-4ba0-8e7b-2242a8d929fe

    However, that post's code works as it should.

    This current new post however is still failing.

     

    Comments

    Is there any status update for this bug? Will there be a hot fix for it?

    Posted by The Hog Dog on 5/16/2006 at 8:22 AM

    This problem still exists after installing SQL 2005 SP1.

    Posted by The Hog Dog on 5/31/2006 at 7:35 AM

    After applying the hot fix in KB916002 (http://support.microsoft.com/Default.aspx?id=916002), the "New request is not allowed to start because it should come with valid transaction descriptor." problem seems to go away. However, after increasing the iterations in the main loop per FDBK50746 (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=35eea8b4-c8ea-4f7c-8e7e-290d7162ece0), I now get the errors identified in that bug: "Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached." Those errors started happening for me on iteration 109. The issue with this bug (FDBK46530) may have been solved on the surface, but it seems like it is not completely solved. With KB916002 applied, after 100+ rollbacks caused by a database, you won't be able to even open a connection, much less start a transaction on it. The rollbacks here seem to use up or corrupt the connection pool. FDBK50746 is very much reproducable. Please review the steps to reproduce on that bug. I don't consider either bug FDBK46530 or FDBK50746 closed in any way.

    Posted by The Hog Dog on 6/7/2006 at 7:42 AM

     

    I changed the code to explicitly Close connections using a try...finally clause, and I still get connection pool timeout errors. I've attached the updated code as TransactionScopeTest_Post_FDBK50746_KB916002.zip. This code also has the main loop counter increased to 500 per FDBK50746.

    Posted by The Hog Dog on 6/7/2006 at 8:08 AM

     

    What happened to all the comments from other users that had been posted in the disucssion area? There was a lot of feedback there. Did you guys get tired of seeing how many people are upset by the bugs and just clobber their comments? Are the comments going to be restored? How about, is anybody in the product development teams even looking at this new web site at all?

    Posted by The Hog Dog on 6/13/2006 at 11:34 AM

      

     

    Friday, June 22, 2007 8:45 AM