Why is System.Transactions TransactionScope default Isolationlevel Serializable

I am just wondering what a good reason to use Serializable as the default Isolationlevel may be when creating a System.Transactions TransactionScope, because I cannot think of any (and it seems that you cannot change the default via web/app.config so you always have to set it in your code)

using(var transaction = TransactionScope()) 
{
    ... //creates a Transaction with Serializable Level
}

Instead I always have to write boilerplate code like this:

var txOptions = new System.Transactions.TransactionOptions();
txOptions.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted;

using(var transaction = new TransactionScope(TransactionScopeOption.Required, txOptions)) 
{
    ...
}

Any ideas?

Solution 1:

The fact Serializable is the default comes from times when .NET wasn't even released (before year 1999), from DTC (Distributed Transaction Coordinator) programming.

DTC uses a native ISOLATIONLEVEL enumeration:

ISOLATIONLEVEL_SERIALIZABLE Data read by a current transaction cannot be changed by another transaction until the current transaction finishes. No new data can be inserted that would affect the current transaction. This is the safest isolation level and is the default, but allows the lowest level of concurrency.

.NET TransactionScope is built on top of these technologies.

Now, the next question is: why DTC defines ISOLATIONLEVEL_SERIALIZABLE as the default transaction level? I suppose it's because DTC was designed around year 1995 (before 1999 for sure). At that time, the SQL Standard was SQL-92 (or SQL2).

And here is what SQL-92 says about transaction levels:

An SQL-transaction has an isolation level that is READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, or SERIALIZABLE. The isolation level of an SQL-transaction defines the degree to which the operations on SQL-data or schemas in that SQL-transaction are affected by the effects of and can affect operations on SQL-data or schemas in concurrent SQL-transactions. The isolation level of a SQL- transaction is SERIALIZABLE by default. The level can be explicitly set by the <set transaction statement>.

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.

Solution 2:

A useful way to cut down writing boilerplate code is to wrap it in a builder class like so:

public static class TransactionScopeBuilder
{
    /// <summary>
    /// Creates a transactionscope with ReadCommitted Isolation, the same level as sql server
    /// </summary>
    /// <returns>A transaction scope</returns>
    public static TransactionScope CreateReadCommitted()
    {
        var options = new TransactionOptions
        {
            IsolationLevel = IsolationLevel.ReadCommitted,
            Timeout = TransactionManager.DefaultTimeout
        };

        return new TransactionScope(TransactionScopeOption.Required, options);
    } 
}

Then you can use it like this when creating a transaction scope:

using (var scope = TransactionScopeBuilder.CreateReadCommitted())
{
    //do work here
}

You can add other common transaction scope defaults to the builder class as you need them.