The Curious Nature of Transactions in ADO.NET and LINQ

| by Jonathan Allen Follow 576 Followers on Aug 16, 2007. Estimated reading time: 1 minute |

Transactions in LINQ rely on TransactionScope, a .NET 2.0 class that uses a distinctly non-OO design pattern that relies on gloabls.

TransactionScope is used to implicitly attach a transaction to a set of changes. Unlike the Transaction object in ADO.NET, TransactionScope is not limited to a single database connection. One of the most common use cases is running a transaction across multiple servers.

When a TransactionScope object is created, it automatically registers itself as the transaction for the thread. All transaction aware operations will automatically use this transaction, with no need to pass the transaction object to the object. Examples of transaction aware objects include the SqlCommand class and LINQ to SQL objects.

One serious side effect of this design is that the link between transactions and operations are not explicit.

Public Sub OperationWithTransaction() 
Using t As New Transactions.TransactionScope
End Using
End Sub

In the above example, when OperationWithTransaction is called everything in the Operation1 function is associated with the transaction. This happens even though the transaction is not explicitly passed to the method. This can make debugging Operation1 problematic, especially when the transaction scope is created several layers up the stack trace.

A final note, when using multi-threading, a given TransactionScope only applies to the current thread.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Another issue... by darren pruitt

MS DTC has to be running on the machine and any remote servers require the Allow Remote DTC access enabled.

No they do not by Frans Bouma

They don't 'rely' on transactionscope. Furthermore, the article you link to is about linq-to-sql, which uses ADO.NET transactions under the hood, and not about linq in general.

Furthermore, the article's point is to make the database introduce locks on the rows read/written so these locks will cause a deadlock failure which the author finds better than reporting the plain exception.

I really can't understand why you would use a deadlock exception to signal concurrency errors, especially as it would kill scalability and the alternative is already there and is scalable: simply compare old values or use a timestamp column.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you