Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > Metadata Extension Reference > db-optimistic-locking

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.

Controls optimistic locking for a class. Optimistic locking prevents changes made in one transaction from overwriting changes committed by another transaction after the instance in the first transaction had been read.

All the optimistic locking modes add extra where-clauses to the update statement to check that the instance has not been changed since it was read. If no row is modified by the update then that means that, some concurrent transaction has changed that row meanwhile and an OptimisticVerificationException is thrown. This is done even if the transaction is using pessimistic locking as other concurrent transactions may be using optimistic locking.

DB Optimistic Locking Options

Optimistic Locking Options



Do not detect concurrent updates


OpenAccess ORM uses this method by default for optimistic concurrency control. It uses a version column to detect concurrent updates. The version number is incremented on every update and the previous version number is included in the where clause. This is the fastest and safest optimistic concurrency control mode.


Use a timestamp column to detect concurrent updates. The timestamp is set on every update and the previous value is included in the where clause. This may not be safe if updates happen quicker than the resolution of the timestamp field. It is included to support legacy database schemas.


Include the previous value of all changed columns in the where clause. This provides more fine grained optimistic locking as different transactions may modify different fields of the same instance. This mode can be used when the database schema is fixed. Float and double fields are excluded as they are not exact.


This setting is only for Oracle. When used the Pseudo column ora_rowscn will be used during optimistic concurrency checks. It will compare the SCN value of the object with the one on the Oracle server. Note that the SCN value is set by the Oracle server after a record has been modified. Also please note that the setting in the app.config file is referred as "backend".

The version and timestamp optimistic concurrency control modes require an extra column for locking. For this, by default, OpenAccess ORM automatically adds a suitable column to the table, which is named "voa_version" or "voa_timestamp", or you can specify an existing field from your class using a nested field-name extension. This is useful if the class requires a version number or last modified date field for some other purpose. The value for this field will be filled in automatically on commit (refer to the autoset extension for more information).

Copy Code
<class name="Customer">
     <extension key="db-optimistic-locking" value="timestamp">
          <extension key="field-name" value="lastModifiedDate" />

The same can be achieved by using this:

app.config Copy Code
<class name="Customer">
<extension key="db-optimistic-locking" value="backend" />

You can use both – “timestamp” and “backend” values for MSSQL but only the “backend” value is available for Oracle since the name of the column cannot be changed.

ora_rowscn is available for every oracle table and it is not created by Telerik OpenAccess ORM.