What does it do? Specifies the RAP locking mechanism for a RAP BO entity. The RAP locking mechanism prevents simultaneous modification access to data on the database by more than one user ( pessimistic concurrency control ). Whenever a lock is requested for a specific entity instance, its lock master and all lock-dependent entity instances 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. In an unmanaged RAP BO, the RAP handler method FOR LOCK must be implemented for lock master entities. For lock dependent entities, any locking request is delegated to its lock master entity . Currently, only root entities can be defined as 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
ABAP_EXCEPTION 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 .
Managed RAP BO In a managed RAP BO, each entity must be defined either as lock master or as lock dependent . The lock mechanism is handled by the RAP framework .
Unmanaged RAP BO In an unmanaged RAP BO , it is recommended that each entity is defined either as lock master or as lock dependent, but this is enforced only in BDEF strict mode . The lock must be implemented by the application developer in the ABAP behavior pool in the RAP handler method FOR LOCK. This can be done, for example, using DDIC lock objects .
Draft-enabled RAP BO 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 BO 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 TITLE .
ABAP_FURTHER_INFO Development guide for the ABAP RESTful Application Programming Model, section Pessimistic Concurrency Control (Locking).
Latest notes:
If BDEF strict mode is enabled, it is mandatory, even in unmanaged RAP BOs, that each entity is marked either as lock master or as lock dependent.
The draft action Resume recreates a lock for an entity instance on the persistent database table when a draft instance is resumed after the lock has expired.
The EML statement SET LOCKS can be used to explicitly lock RAP BO instances.
Locks are managed in a global lock table. NON_V5_HINTS
The lock table is administered by the transaction SM12 ABAP_HINT_END
ABAP_EXAMPLE_VX5 - Managed The following example shows a managed BDEF based on the CDS root view entity DEMO_SALES_CDS_BUPA_2. The root entity is defined as lock master entity and the child entity is defined as lock dependent entity. The association association _Address { } is defined in the entity behavior body of the child entity, thereby ensuring that locking requests on the child entity are delegated to the lock master entity. ABAP_NOTE This example does not fully meet the requirements of the RAP BO contract. It is intentionally kept short and simple and serves demonstration purposes only. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model. BDEF DEMO_SALES_CDS_BUPA_2 The class CL_DEMO_SALES_RAP_LOCK accesses the business object using EML and creates two BO instances. Code snippet: ABEXA 01532 The following image shows the global lock table (transaction SM12) during the transaction, before the COMMIT ENTITIES statement is executed. The key values of both newly created entities are listed there as part of the uniqueness check. . After the COMMIT ENTITIES statement is executed, both entries are deleted automatically. IMAGE ABDOC_lock_table.png 1092 168 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 - Unmanaged The following example shows an unmanaged BDEF based on the CDS root view entity DEMO_RAP_UNMANAGED_LOCKING. The root entity is defined as lock master entity. BDEF DEMO_RAP_UNMANAGED_LOCKING The lock method is implemented in the ABAP behavior pool as shown below. The lock object ERAPLOCK is used to control access to the RAP BO's persistent database table. METH BP_DEMO_RAP_UNMANAGED_LOCKING(CCIMP)=>LOCK The class CL_DEMO_RAP_UNMANAGED_LOCK accesses the business object using EML and carries out the following steps:
it creates two entity instances
it updates one of the instances
it deletes both instances During the UPDATE ENTITIES and DELETE ENTITIES operations, the two entity instances are locked in the global lock table. During the CREATE ENTITIES operation, this is not the case, since no key values are available yet. ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 - With Draft The following example shows an unmanaged, draft-enabled BDEF based on the CDS root view entity DEMO_RAP_UNMANAGED_DRAFT_ROOT . BDEF DEMO_RAP_UNMANAGED_DRAFT_ROOT The class CL_DEMO_RAP_UNMANAGED_DRFT_LCK accesses the business object using EML and performs the following steps:
It creates two new draft instances of the parent entity.
It activates the draft entities using the draft action Activate. The following image shows the global lock table (transaction SM12) during the creation of the new draft instances, before the COMMIT ENTITIES statement is executed. The active instances are locked. This lock is removed after the draft action Activate has been completed. IMAGE ABDOC_lock_table_2.jpg 1238 276 ABAP_EXAMPLE_END
ABAP_VARIANT_1 ... lock master $[unmanaged$]
What does it do? Declares an entity as lock master entity. Currently, only root nodes are allowed as lock master entity. In a managed RAP BO, the implementation is per default provided by the managed BO framework. 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.
ABAP_VARIANT_2 ... lock dependent by _Assoc
What does it do? Defines an entity as lock dependent. This means that locking requests are delegated to the lock master entity. The association 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. The following syntax short form is available to summarize lock dependent, ETag dependent, and authorization dependent: ($[lock$]$[, authorization$]$[, etag$]) dependent by _assoc For details, see topic TITLE .
ABAP_VARIANT_3 ... lock:none
What does it do? Can be used as syntax addition for an action to prevent the locking mechanism for the entity instance for which an action is executed. See topic TITLE .
