Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Isolation levels
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > Transactions > Isolation levels

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

Isolation level

Controls the transaction locking and row versioning behavior. The isolation level describes the degree to which the data being updated is visible to other transactions.
Detailed descriptions of all possible anomalies can be found in the Concurrency Anomalies topic.

Isolation level Dirty read Lost updates Non-repeatable read Phantom read
READ UNCOMMITTED yes yes yes yes
READ COMMITTED no yes yes yes
REPEATABLE READ no no no yes
SERIALIZABLE no no no no
SNAPSHOT no no no no
NO LOST UPDATES no no yes yes


    The READ UNCOMMITTED isolation level allows a task to read data that can be in the middle of being modified by another transaction, uncommitted changes to data in the database. This is also known as dirty read. Values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction.


    The READ COMMITTED isolation level specifies that a transaction can read only committed changes to data. It cannot read data that has been modified but not committed by other transactions. Data can be changed by other transactions between individual statements within the current transaction. If a transaction needs to read a row that has been modified by an incomplete transaction in another session, the transaction waits until the first transaction completes.


    It means that the transaction will lock all the data that is used in the query and another transaction cannot update the data until the current transaction completes. Other transactions can insert new rows that match the search conditions of statements issued by the current transaction. If the current transaction then retries the statement it will retrieve the new rows, which results in phantom reads.


    This is the most restrictive isolation level which prevents other user from updating ot insrting rows into the data set until the transaction completes. The SERIALIZABLE isolation level also specifies that statements cannot read uncommitted changes to data in the database.


    In databases, SNAPSHOT isolation specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of the transaction. A transaction executing under snapshot isolation appears to operate on a personal snapshot of the database, taken at the start of the transaction. Data modifications made by other transactions after the start of the current transaction are not visible to statements executing in the current transaction. The transaction itself will successfully commit only if no updates are made to the data by any concurrent updates made since that snapshot.


    NO_LOST_UPDATES is defined as a degree of isolation in between READ_COMMITTED and REPEATABLE_READ. For NO_LOST_UPDATES, non-repeatable reads and phantom reads are allowed, but lost updates are not allowed.

Setting the isolation level is done inside the backendconfiguration section of the App.config file as shown in the following example.

App.config Copy Code
<backendconfiguration id="mssqlConfiguration" backend="mssql">