TransactionScope timeout issue with SqlConnection and LTM (some operations are not rolled back) - by Marcin Kosieradzki

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 266095 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 3/29/2007 2:50:45 PM
Access Restriction Public


using (TransactionScope ts = new TransactionScope())
  //Operation1 on connection
  //Timeout occurs here
  //Operation2 on connection

Operation1 is rolled back
Operation2 is not rolled back
Sign in to post a comment.
Posted by Jared Moore on 8/20/2010 at 11:37 AM
Thanks for reporting this issue. It is now fixed in .Net 4.0, so instead of executing in AutoCommit mode, Operation2 will now throw the exception “System.InvalidOperationException: The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.”

You are correct that EnlistTransaction(null) with Explicit Unbind did not work as documented. This has also been fixed in .Net 4.0.

Jared Moore
Software Development Engineer in Test
ADO.NET Managed Providers and DataSet Team
Posted by Mark A. Nicholson on 7/28/2009 at 12:21 AM
The following statement is INCORRECT: "Explicit Unbinding is the new behavior. With this behavior, the connection remains bound to the transaction until it is closed or an explicit Enlist(null) call is made."

You cannot unbind a SQL connection from an enlisted transaction using SqlConnection.EnlistTransaction(null); -- EVER! Once the SqlConnection is enlisted in a transaction, it can only be unbound from the transaction under the following circumstances:

1. "TransactionBinding = Explicit Unbind" was specified in the connection string -- when SqlConnection is closed (or disposed).
2. "TransactionBinding = Implict Unbind" was specified in the connection string -- when the transaction ends (is committed, is aborted or times-out).

Any attempt to call SqlConnection.EnlistTransaction(null); will result in an InvalidOperationException: "Connection currently has transaction enlisted. Finish current transaction and retry."
Posted by Microsoft on 8/17/2007 at 3:09 PM
This problem existed in Whidbey as well, and is an underlying design mis-match between System.Transactions and ADO.Net data providers. A option for new behavior has been added for the Orcas release.

The option: "Transaction Binding" keyword has been added as a valid SqlClient connection string option. Possible values are "Implicit Unbind" and "Explicit Unbind". e.g. ";Transaction Binding=Explicit Unbinding"

Implicit Unbinding is the default value if the keyword is not present. It is also the v2.0 behavior. With this behavior, the connection switches to auto-commit mode as soon as the transaction completes, which happens on a background thread during transaction timeout in the associated scenario. Subsequent executions on the connection are NOT associated with the transaction, and will commit or rollback separately.

Explicit Unbinding is the new behavior. With this behavior, the connection remains bound to the transaction until it is closed or an explicit Enlist(null) call is made. At at the start of each execute, if the transaction at System.Transactions.Transaction.Current is not the transaction bound to the connection, or if that transaction is not active, an exception will be thrown.
Posted by Microsoft on 5/11/2007 at 4:57 PM

Thank you for reporting this issue. We are currently investigating this issue and developing a fix for this. As we know more we will update this report and confirm the fix.

Carl Perry
Program Manager ADO.NET
Posted by Microsoft on 3/30/2007 at 1:18 AM
Thanks for your feedback. We have reproduced this bug, and we are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution. Thank you, Visual Studio Product Team.
Posted by Microsoft on 3/29/2007 at 6:34 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see Thank you, Visual Studio Product Team.