High volume site using ADO.NET TransactionScope vs ExecuteCommand on NOLOCK, READ UNCOMMITTED directly?

Question

Just read this interesting article by Omar on his blog Linq to SQL solve Transaction deadlock and Query timeout problem using uncommitted reads and at the end Javed Hasan star

Answer 1

Regarding transactions in .Net and the (somehow surprising) side-effect of the DTC, this document Introducing System.Transactions in the .NET Framework 2.0 by Juval Lowy explains things very well and is still fully valid (.Net4). Worth reading. (I would also have posting a comment... if I could.)

Answer 2

First of all please avoid uncommitted reads, they can cause lots of issues. A much better approach is just to set the database to snapshot isolation. This is what Jeff did.

Jeff basically said: "bla bla bla, be real, bla bla bla, database theoreticians, bla bla bla, READ UNCOMMITTED can be useful for REAL production apps that don't need data consistency." Jeff is not a DBA, fortunately there are many DBAs out here on SO.

The problem with Omar's approach is that it can leak connections with "read uncommitted" isolation level in to your connections pool which could wreak havoc in your website. Meaning random statement may be executed in read uncommitted.

Javed approach would be much better because on dispose MS have the chance to clean stuff up on the connection.

EDIT If you are having performance issues with Javed's approach you could look at rolling your own transaction manager.

Some things you probably want to do:

• Hold a stack of current transactions
• Confirm you are on the creator thread when a transaction is committed
• Reset the transaction isolation to its previous state on dispose
• Rollback on dispose if the transaction was not committed.
• Support nested rollbacks.

Answer 3

{My (poor) reputation prevents me from posting comments so I put this as an answer}

If you use IsolationLevel via System.Transactions and create a new Linq context within the transaction block, SQL Server ends up trying to call DTC to coordinate the transaction. That just happened to me and was quite unexpected.

Answer 4

I'm a developer on a tools team in the SQL Server group at Microsoft. Many applications are not super-sensitive to transaction consistency, especially if you writing an app which does reporting or something where occasionally inconsistent data is not the end of the world. Of course, if you writing a financial application or something else which has very low tolerance for data inconsistency, you probably want to explore other solutions.

If do choose to use uncommitted reads, I have blogged a handy solution using extension methods in C#.