Concurrency Control Concepts

Concurrency Control in RAP

 

Concurrency control prevents concurrent and interfering database access of different users. It ensures that data can only be changed if data consistency is assured.

 

RESTful applications are designed to be usable by multiple users in parallel. If more than one user has transactional database access, you must make sure that every user only executes changes based on the current state of the data so the data stays consistent. In addition, you must make sure that sure that users do not change the same data at the same time.

 

There are two approaches to regulate concurrent writing access to data. Both of them must be used in the ABAP RESTful Application Programming Model to ensure consistent data changes.

 

Pessimistic Concurrency Control

Pessimistic concurrency control prevents simultaneous modification access to data on the database by more than one user.

 

Pessimistic concurrency control is done by exclusively locking data sets for the time a modification request is executed. The data set that is being modified by one user cannot be changed by another user at the same time by using a global lock table.

 

The lifetime of such an exclusive lock is tied to the session life cycle. The lock expires once the lock is actively removed after the successful transaction or with the timeout of the ABAP session.

 

In managed scenarios, the business object framework assumes all of the locking tasks. You do not have to implement the locking mechanism in that case. If you do not want the standard locking mechanism by the managed business object framework, you can create an unmanaged lock in the managed scenario. In unmanaged scenarios, the application developer has to implement the method for lock and implement the locking mechanism. This will be covered later in this course.

 

Optimistic Concurrency Control

Optimistic concurrency control enables transactional access to data by multiple users at the same time, while avoiding inconsistencies and unintentional changes of already modified data.

 

The approach of optimistically controlling data relies on the concept that every change on a data set is logged by a specified field, called the ETag field. Most often, the ETag field contains a timestamp, a hash value, or any other versioning that precisely identifies the version of the data set.

 

Concurrency control based on ETags is independent of the ABAP session and instances are not blocked to be used by other clients.

 

Optimistic concurrency control is only relevant when consuming business objects via OData. That is why the ETag is also referred to as OData ETag.

 

Pessimistic Concurrency Control

Locking During UPDATE Operation

 

Technically, pessimistic concurrency control is ensured by using a global lock table. Before data is changed on the database, the corresponding data set receives a lock entry in the global lock table.

 

Every time a lock is requested, the system checks the lock table to determine whether the request collides with an existing lock. If this is the case, the request is rejected. Otherwise, the new lock is written to the lock table. After the change request has been successfully executed, the lock entry on the lock table is removed. The data set is available to be changed by any user again.

 

The lifetime of such an exclusive lock is tied to the session life cycle. The lock expires once the lock is actively removed after the successful transaction or with the timeout of the ABAP session.

The example illustrates how the lock is set on the global lock table during an UPDATE operation. The client that first sends a change request makes an entry in the global lock table. During the time of the transaction, the second client cannot set a lock for the same entity instance in the global lock tables and the change request is rejected. After the successful update of client 1, the lock is removed and the same entity instance can be locked by any user.

 

Optimistic Concurrency Control

ETag Check in UPDATE Operation