1 out of 3 rated this helpful - Rate this topic

IsolationLevel Enumeration

Specifies the transaction locking behavior for the connection.

Namespace:  System.Data
Assembly:  System.Data (in System.Data.dll)
public enum IsolationLevel
Member name Description
Supported by the XNA Framework Unspecified A different isolation level than the one specified is being used, but the level cannot be determined.

When using OdbcTransaction, if you do not set IsolationLevel or you set IsolationLevel to Unspecified, the transaction executes according to the isolation level that is determined by the driver that is being used.

Supported by the XNA Framework Chaos The pending changes from more highly isolated transactions cannot be overwritten.
Supported by the XNA Framework ReadUncommitted A dirty read is possible, meaning that no shared locks are issued and no exclusive locks are honored.
Supported by the XNA Framework ReadCommitted Shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in non-repeatable reads or phantom data.
Supported by the XNA Framework RepeatableRead Locks are placed on all data that is used in a query, preventing other users from updating the data. Prevents non-repeatable reads but phantom rows are still possible.
Supported by the XNA Framework Serializable A range lock is placed on the DataSet, preventing other users from updating or inserting rows into the dataset until the transaction is complete.
Supported by the XNA Framework Snapshot Reduces blocking by storing a version of data that one application can read while another is modifying the same data. Indicates that from one transaction you cannot see changes made in other transactions, even if you requery.

The IsolationLevel values are used by a .NET Framework data provider when performing a transaction.

The IsolationLevel remains in effect until explicitly changed, but it can be changed at any time. The new value is used at execution time, not parse time. If changed during a transaction, the expected behavior of the server is to apply the new locking level to all statements remaining.

.NET Framework

Supported in: 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Supported in: 4, 3.5 SP1

Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2

The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Considerations using IsolationLevel.Snapshot
Using the IsolationLevel.Snapshot, one should take into consideration, that - as far as I observed it - inside one TransactionScope on SQL Server, only one SqlConnection can be open at a time. Trying to open another SqlConnection while one is already open, the SQL Server Native Client tries to promote the transaction via the Distributed Transaction Coordinator, which fails. The error message says that a snapshot transaction cannot be promoted.

Using a stateless data access layer, which opens a connection, performs the database access (i.e. execute a stored procedure), and closes the connection immediately, having only one connection open at a time is not a limitation.

Of course, having multiple clients / threads, each  with its own TransactionScope, concurrent database access is not an issue. The limitation takes place only inside the same TransactionScope.