Telerik OpenAccess Classic

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

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.

This section describes how pessimistic concurrency control is achieved with OpenAccess ORM and discusses the advantages and disadvantages of OpenAccess ORM pessimistic concurrency control.

When using pessimistic concurrency control an object scope is permanently coupled to a database connection. Furthermore, the OpenAccess ORM transaction is directly associated with a database transaction.

How the concurrency control mechanism is implemented depends on the backend and its configuration. For example, if the isolation level is set to REPEATABLE READ, some database systems put a read lock on the respective rows if a SELECT-statement is executed, while other database systems use a versioning approach instead of read-locks. Therefore, you may experience that with different database systems but the same isolation level, readers may or may not block writers.

OpenAccess ORM obtains a write lock by issuing a SELECT FOR UPDATE or a semantically equivalent statement depending on which backend is used. Whether a write-lock is obtained or not, depends on whether PESSIMISTIC_EXPLICIT or PESSIMISTIC_WRITE_LOCK_WHEN_FETCHED is used. In case of , PESSIMISTIC_EXPLICIT no implicit write lock is fetched; all write locking must be done manually by calling the method ITransaction.Lock( theObject, theLockMode ). For PESSIMISTIC_WRITE_LOCK_WHEN_FETCHED, write-locks are applied to all objects when retrieving them.

A future release will also offer PESSIMISTIC_IMPLICIT with implicit write-locks only applied to objects that are actually changed.

A particular isolation level is set in the application configuration file. Following is an example:

Copy Code
<backendconfigurations>
  <backendconfiguration id="mssqlConfiguration" backend="mssql">
    <mappingname>mapping-mssqlConfiguration</mappingname>
    <isolationLevel>SERIALIZABLE</isolationLevel>
  </backendconfiguration>
</backendconfigurations>

The allowed isolation values are:

 

READ_COMMITTED

 

READ_UNCOMMITTED

 

REPEATABLE_READ

 

SERIALIZABLE

Not all isolation values are supported by all database backends.

Firebird waits for parallel transaction commit when READ_COMMITTED is used. Therefore, READ_UNCOMMITTED should be used, which does not block, and yet reads committed only.

Explicit Locking

Besides the automatic set of locks, it is also possible to manually set a lock. For this purpose, the OpenAccess ORM API provides the following method in the ITransaction interface:

Copy Code
public void Lock( Object target, LockMode mode)

Both methods try to apply a lock for the object obj. If the lock is not granted, Lock throws a LockNotGrantedException. The LockMode enum contains the values READ, WRITE, DELETE.

In case of Oracle, by design, only write/write conflicts lead to an LockNotGranted exception, i.e., read/write conflicts will not lead to concurrency conflicts. Other database backends will also throw read/write conflicts.

Advantages and Disadvantages of Pessimistic Concurrency Control

OpenAccess ORM pessimistic concurrency control offers the following advantages:

 

Conflicts are detected early. Additionally, if the applications are able to perform activities outside the control of the database rollback capabilities (such as printing a document), these activities do not take place if a conflict occurs, so there is no need to undo them.

OpenAccess ORM pessimistic concurrency control has the following disadvantages:

 

Certain sequences of operations are rejected even though they do not violate the chosen degree of isolation. By allowing these operations to be accepted, a higher concurrency can be achieved and thus a higher scalability is possible.

 

Hot spot objects can seldom be written. Hot spot objects are objects that are very often requested by many different transactions. Conflicts are very likely to happen, and therefore most of the requests for a write lock will be rejected.