Telerik OpenAccess Classic

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

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.

Most database systems do not completely satisfy the isolation property of the ACID principle because this would lead to performance problems. In practice, for many applications the occurrence of certain concurrency anomalies is acceptable; as either they can handle them or an occurrence of such an anomaly does not strongly influence the application's purpose. Therefore, certain relaxation in terms of total isolation, are in use to increase the scalability of the application. ANSI SQL-92 defines such relaxations as isolation levels. Different isolation levels are defined on the basis of whether the occurrence of one or more particular concurrency anomalies is allowed or prohibited.

The following table summarizes, which anomalies are possible in the isolation levels supported by OpenAccess ORM:

Isolation Level

Dirty Read

Lost updates

Non-repeatable Read

Phantom Read

READ COMMITTED

not possible

possible

possible

possible

NO LOST UPDATES

not possible

not possible

possible

possible

REPEATABLE READ

not possible

not possible

not possible

possible

The READ COMMITTED and REPEATABLE READ isolation levels refer to the ANSI definition. In addition, however, OpenAccess ORM introduces a level of isolation that is not contained in the ANSI definition: NO_LOST_UPDATES. 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.

Phantom reads may occur at all isolation levels. When this is not acceptable, the application must ensure additional isolation. OpenAccess ORM offers several mechanisms for this application-side synchronization:

 

Explicit locking: Setting explicit locks can synchronize access to objects or whole object graphs. Using locks is described in the Explicit Locking section.

 

Synchronization with objects: A client can change the values of objects to allow or disallow certain operations, on the same, for other clients.