Telerik OpenAccess Classic

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

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.

Operations on persistent classes in a database are always performed in the context of a transaction. A transaction is an ordered sequence of operations that transforms a database from one state of consistency to another state of consistency.

When using Telerik OpenAccess ORM and persistent classes, the following operations require a transaction:


Insertion of new objects into the database by an explicit call to IObjectScope.Add(obj) or by persistence-by-reachability.


Deletion of objects by calling IObjectScope.Remove(obj).


Modification of existing objects, i.e., changing the field values of objects in memory (transparent persistence).


Reading of objects from the database using any of the mechanisms described in Object Retrieval.

ACID Properties

The data in the OpenAccess ORM database is maintained in a transactional consistent state according to the standard definition of ACID transactions.


The “Atomicity” property states that within a transaction, changes to the values in persistent instances are either executed in their entirety or none are executed, i.e. if one part of the transaction fails, the entire transaction fails. A transaction, therefore, must not leave intermediate states in the database—even when errors occur. The Using Transactions in OpenAccess ORM section describes how atomicity is achieved using the OpenAccess ORM begin, commit, and rollback operations.


The “Consistency” property states that before the beginning and after the end of a transaction, the state of a database must be consistent. This means, in particular, that after the rollback of a transaction, (the transaction was not successfully processed due to an error) the consistent state of the database must be reestablished. OpenAccess ORM assures that changes to the values of persistent instances are consistent with changes to other values in the same instance. OpenAccess ORM, however, does not assure referential integrity; i.e., that references to other persistent instances can always be resolved.


The “Isolation” property requires that changes to values in persistent instances are isolated from changes to the same instance in other transactions. For a given transaction, it should appear as though it is running independently from all others associated with the database. Refer to the Concurrency Control section for descriptions of the options for achieving different degrees of transactional isolation in OpenAccess.


The “Durability” property states that if a transaction has been committed successfully, all its changes must be durable in the database, i.e. any transaction committed to a database will not be lost. This is guaranteed by the database backend (For some databases, the backend may be disabled or may not be available).

These principles are reflected in the OpenAccess ORM API and runtime system.