Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
How to: Use Backend Specific Concurrency Mechanisms
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > Concurrency Control > How to: Use Backend Specific Concurrency Mechanisms

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.

The Concurrency control is a process used to identify the data modifications which are made by multiple users at once. This method ensures that the transactions are executed following the ACID rules:

  • Atomicity - if one part of the transaction fails the entire transaction fails;
  • Consistency - every transaction must leave the database in a consistent state;
  • Isolation - no interference between the transactions;
  • Durability - the values persist if the data had been committed even if the system crashes;

 

There are two major categories of concurrency control mechanisms:

  • Optimistic - before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rollbacks;
  • Pesimistic - blocks operations of transaction that would cause violation of synchronization rules;

 

Telerik OpenAccess ORM supports several modes for Optimistic Concurrency control – version, timestamp, changed, backend and none. You can find more information on each of them here.

In this article we discuss how to use the ‘backend’ concurrency mode.

Certain backends provide a built-in data type to maintain the version of a row. User can create a column with this datatype and the server updates the value of this column automatically on every update of the row.  Following is a list of backends that provide a built-in data type along with the data type:

  • Microsoft SqlServer family  - 'rowversion/timestamp'  - It uses 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. Every timestamp value is unique and accurately represents an instant in time;
  • Oracle - ORA_ROWSCN - It returns, for each row, the upper bound system change number (SCN) of the most recent change to the row. This pseudo column is useful for determining approximately when a row was last updated.  Note that the SCN value is set by the Oracle server after a record has been modified;

 

The ‘backend’ concurrency mode is applicable during Reverse mapping an existing schema as well as while creating tables from the class model, using the Forward mapping approach.

 

Reverse Mapping: The Reverse mapping wizard detects a timestamp column (for MS SqlServer) and treats that as a version column. When the class is generated using the wizard, the appropriate mapping entries are added to the app.config so that this column is used during concurrency checks.

Forward Mapping:

  • Run the Forward Mapping Wizard;
  • Locate and click on the class node;
  • On the right inside the Concurrency Control box select backend from  the ‘Verify by’ combo-box .  If the class has a field with the required type (System.SByte, System.Int16, System.Int32, System.Int64) you can select this field in the ‘Field’ combobox.  If you do not have a field, select default. OpenAccess will create a timestamp column in the table and will use it for concurrency checks;

 

 

For details of the related mapping please refer to the metadata extension reference.