Click here to Skip to main content
12,501,882 members (47,474 online)
Click here to Skip to main content
Add your own
alternative version


9 bookmarked

.NET TransactionScope and its default Transaction Isolation level issue

, 1 Feb 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
.NET TransactionScope and its default Transaction Isolation level issue.


We often use the .NET Framework TransactionScope object to manage/handle database transactions. Often we create an instance of TransactionScope object like the following:

var scope = new
TransactionScope(TransactionScopeOption.Required, new TimeSpan(0, 0, 1, 0)) 


var scope = new TransactionScope() 

or use some other overloaded constructor. Everything works fine. But the story begins when a timeout exception message comes.


Actually it is a deadlock exception. So anyone can think it happened for concurrent user access for same resource (database row) and it might be a very rare case and ignore it. But unfortunately it comes again and again and you cannot overlook it. I start rnd for understanding the reason why the deadlock happens again and again. Why is it happening? First I start investigating the TransactionScope object. I tried to find if there are any issues in that component. Finally I got my answer. The investigating result is the TransactionScope object's default Isolation Level is Serializable. That is the culprit for raising such a deadlock exception for some scenarios. If we need to fix that we should use other isolation levels like ReadCommitted, etc. As we know SQL Server uses ReadCommitted as the default Isolation Level. It is recommended to use that for general purposes.

How to Fix

Create a factory method in the business layer (considering transaction will be managed by the Business Layer).

The Factory method body is as follows:

public static TransactionScope CreateTransactionScope()
    var transactionOptions = new TransactionOptions 
        IsolationLevel = IsolationLevel.ReadCommitted,
        Timeout = net TimeSpan(0,0,0,0,10,0) //assume 10 min is the timeout time
    return new TransactionScope(TransactionScopeOption.Required, transactionOptions); 

Use of Factory method

Instead of creating a TransactionScope object with default constructor like the following

using (var scope = new 
TransactionScope(TransactionScopeOption.Required, new TimeSpan(0, 0, 1, 0)))

we can create that object with the help of a factory method and it will fulfill our purpose.

using (var scope =  CreateTransactionScope() )   { 


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

S. M. Ahasan Habib
Program Manager IXORA Solution Ltd.
Bangladesh Bangladesh
Mostly I work with MS technologies (ASP.NET MVC, WPF, C#, SQL Server, SSRS, SharePoint, Entity Framework, MSTest, Enterprise Library, MEF, WCF, WebAPI, MS Excel, IIS).
Non MS technologies which I love and use (Resharper, NHiberNet, JQuery, AngularJS, KnockoutJS, NodeJS, Python, MSpec, RihnoMock, Crystal Report, Subversion, Crome)

You may also be interested in...


Comments and Discussions

QuestionWill this work in this scenario? Pin
iamlarph217-Feb-13 21:18
memberiamlarph217-Feb-13 21:18 
AnswerRe: Will this work in this scenario? Pin
S. M. Ahasan Habib17-Feb-13 22:20
memberS. M. Ahasan Habib17-Feb-13 22:20 
GeneralRe: Will this work in this scenario? Pin
iamlarph217-Feb-13 23:27
memberiamlarph217-Feb-13 23:27 
GeneralRe: Will this work in this scenario? Pin
S. M. Ahasan Habib18-Feb-13 0:29
memberS. M. Ahasan Habib18-Feb-13 0:29 
Oh now understand properly your question. The answer is yes the other transaction will be delayed. But how much delated it depends of the isolation policy you set. All transcation isolation level is fine but just you need to identify which will be best based on your reauirement. If i say little more then, when you use transactionscope or any other transaction component, it will lock the rows. With setting isolation level you can define policy how rows will be read/add/edit/delete. One example may be
WAITFOR DELAY '00:01:00'
Read Commited
under READ COMITTED, the second SELECT may return any data. A concurrent transaction may update the record, delete it, insert new records. The second select will always see the new data.
under SERIALIZABLE reads the second select is guaranteed to see exactly the same rows as the first. No row can change, nor deleted, nor new rows could be inserted by a concurrent transaction.

In detail about transaction isolation level you may visit this link
GeneralRe: Will this work in this scenario? Pin
iamlarph218-Feb-13 1:42
memberiamlarph218-Feb-13 1:42 
GeneralMy vote of 5 Pin
SRIRAM 26-Feb-13 0:02
memberSRIRAM 26-Feb-13 0:02 
GeneralRe: My vote of 5 Pin
S. M. Ahasan Habib7-Feb-13 0:30
memberS. M. Ahasan Habib7-Feb-13 0:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.160919.1 | Last Updated 1 Feb 2013
Article Copyright 2013 by S. M. Ahasan Habib
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid