Why is System.Transactions TransactionScope default Isolationlevel Serializable

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.

Leave a Comment