Description

Specifies the RAP locking mechanism for a RAP BO entity. The RAP locking mechanism  is based on the SAP lock concept. It  prevents simultaneous modification access to data on the database by more than one user. This is also known as pessimistic concurrency control. Whenever a lock is requested for a specific entity instance, its lock master and all lock-dependent entity instance are locked for editing by a different user, in other words, as soon as one node receives a locking request, the whole BO instance is locked. Lock master entities are locked on each locking request of one of their lock-dependent entities.

The following rules apply:

• The root node must be declared as lock master entity.
• Each child entity must be declared as lock-dependent entity using the syntax lock dependent by _Assoc. Locking requests of lock-dependent entity instances are delegated to the lock master entity.
• Each RAP BO entity must be defined as lock master or lock dependent entity.
• The association _Assoc from the lock-dependent entity to the lock master entity must be explicitly defined in the entity behavior definition using the syntax association _AssocToLockMaster { }. The association must also be defined in the underlying CDS data model.

In a managed RAP BO, the locking mechanism is handled by the managed RAP BO provider, so that no implementation in the ABAP behavior pool is required. If the optional addition unmanaged is used, the lock mechanism must be implemented manually in the method FOR LOCK of the behavior pool, just like in the unmanaged scenario. It is then invoked at runtime.

In an unmanaged RAP BO, the RAP handler method FOR LOCK must be implemented for lock master entities.

Setting Locks

If a lock is defined for a RAP BO entity, the entity instances in question are implicitly locked during the runtime of the following modify operations:

• update
• delete
• create by association
• action
• Note: The optional addition lock:none is available for actions. It can be used to prevent the locking mechanism for the entity instance for which an action is executed.
• Note:  create: In a managed RAP BO, the newly created key values (if available) of instances are written into the global lock table during the create operation. This is part of a uniqueness check, which is automatically and implicitly carried out by the RAP framework. In an unmanaged RAP BO, there is no automatic uniqueness check and no key values are written into the global lock table. For further details, see the development guide for the ABAP RESTful Application Programming Model, section Uniqueness Check.

Availability

• Managed RAP BO
• Unmanaged RAP BO
• Draft-enabled RAP business object
• If a BO is draft-enabled, locking must also be considered. As soon as a draft instance is created for an existing active instance, the active instance is given an exclusive lock and cannot be modified by another user. This exclusive lock remains for a determined time, even if the ABAP session terminates. The duration time of the exclusive lock can be configured. Once the exclusive lock expires after the duration time, the optimistic lock phase begins. During the optimistic lock phase, a draft can be resumed as long as the active instance does not change, but there is no longer an exclusive lock.
• Projection BDEF
• In a projection business object, the RAP locking mechanism that is defined and implemented for the base BO is automatically reused and does not need to be explicitly defined. For details, see topic RAP - EntityBehaviorCharacteristics, Projection BDEF.

Further Information

Development guide for the ABAP RESTful Application Programming Model, section Pessimistic Concurrency Control (Locking).