Ansicht
Dokumentation

ABENBDL_LOCKING - BDL LOCKING

ROGBILLS - Synchronize billing plans   PERFORM Short Reference  
This documentation is copyright by SAP AG.

- Locking

Declaration on entity level

... lock master $[unmanaged$]
  $| lock dependent by _Assoc

Syntax addition that can be used for an action

... lock:none

Variants:

1. ... lock master [unmanaged]

2. ... lock dependent by _Assoc

3. ... lock:none

Effect

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

• 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's 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 can't 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 doesn't change, but there's 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 doesn't need to be explicitly defined. For details, see topic CDS BDL - entity behavior characteristics, projection BDEF.

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

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 (administration by transaction SM12)
  
  

Example - 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.

The program DEMO_SALES_RAP_LOCK accesses the business object using EML and creates two BO instances.

Code snippet:

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@@

Example - 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.

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.

The program 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.

Example - With Draft

The following example shows an unmanaged, draft-enabled BDEF based on the CDS root view entity DEMO_RAP_UNMANAGED_DRAFT_ROOT.

The program DEMO_RAP_UNMANAGED_DRAFT_LOCK 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@@

Variant 1

... lock master $[unmanaged$]

Effect

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.

Variant 2

... lock dependent by _Assoc

Effect

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 syntax_short_form.

Variant 3

... lock:none

Effect

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 CDS BDL - action.

ABAP Short Reference   General Material Data  
This documentation is copyright by SAP AG.

Length: 15161 Date: 20240426 Time: 052901     sap01-206 ( 221 ms )