C# 4 and .NET 4

isolation level ❘ 625
The problems that you can encounter if you don’t completely isolate the scope outside the transaction can be
divided into three categories:
➤
➤
➤
Dirty reads — Another transaction can read records that are changed within the transaction. Because
the data that is changed within the transaction might roll back to its original state, reading this
intermediate state from another transaction is considered “dirty” — the data has not been committed.
You can avoid this by locking the records to be changed.
Nonrepeatable reads — When data is read inside a transaction, and while the transaction is running,
another transaction changes the same records. If the record is read once more inside the transaction,
the result is different — nonrepeatable. You can avoid this by locking the read records.
Phantom reads — When a range of data is read, for example, with a WHERE clause. Another
transaction can add a new record that belongs to the range that is read within the transaction. A
new read with the same WHERE clause returns a different number of rows. Phantom reads can be a
specific problem when doing an UPDATE of a range of rows. For example, UPDATE Addresses SET
Zip=4711 WHERE (Zip=2315) updates the ZIP code of all records from 2315 to 4711. After doing
the update, there may still be records with a ZIP code of 2315 if another user added a new record with
ZIP 2315 while the update was running. You can avoid this by doing a range lock.
When defining the isolation requirements, you can set the isolation level. This is set with an
IsolationLevel enumeration that is configured when the transaction is created (either with the constructor
of the CommittableTransaction class or with the constructor of the TransactionScope class). The
IsolationLevel defines the locking behavior. The next table lists the values of the IsolationLevel
enumeration.
isolaTion leVel
ReadUncommitted
ReadCommitted
RepeatableRead
Serializable
Snapshot
Unspecified
Chaos
desCriPTion
With ReadUncommitted, transactions are not isolated from each other. With this level,
there is no wait for locked records from other transactions. This way, uncommitted
data can be read from other transactions — dirty reads. This level is usually used
just for reading records where it does not matter if you read interim changes
(for example, reports).
ReadCommitted waits for records with a write-lock from other transactions. This way, a
dirty read cannot happen. This level sets a read-lock for the current record read
and a write-lock for the records being written until the transaction is completed.
Reading a sequence of records, with every new record that is read, the prior record is
unlocked. That’s why nonrepeatable reads can happen.
RepeatableRead holds the lock for the records read until the transaction is
completed. This way, the problem of nonrepeatable reads is avoided. Phantom reads
can still occur.
Serializable holds a range lock. While the transaction is running, it is not possible to
add a new record that belongs to the same range from which the data is being read.
The isolation level Snapshot is possible only with SQL Server 2005 and later versions.
This level reduces the locks as modified rows are copied. This way, other transactions
can still read the old data without the need to wait for an unlock.
The level Unspecified indicates that the provider is using an isolation level value that
is different from the values defined by the IsolationLevel enumeration.
The level Chaos is similar to ReadUncommitted, but in addition to performing the
actions of the ReadUncommitted value, Chaos does not lock updated records.
The next table gives you a summary of the problems that can occur as a result of setting the most commonly
used transaction isolation levels.
www.it-ebooks.info