Points of Contact Between CSL and SAP Locking Concept
Lock Objects
In both locking concepts, locks are obtained using additional objects:
-
The SAP locking concept protects database objects using a lock object in the ABAP Dictionary. Competing programs try to access the same lock object before they make changes to the database object. The programs must actually use the lock object so that they can request locks.
-
The CSL protects objects using a unique token. For the CSL it does not matter what is protected by the token mechanism. It is also important that all the programs that want to make changes to an object request a lock from the CSL.
Where locks are referred to in this documentation, these are CSL locks. (To make this clearer, the term CSL lock is used). Locks of the SAP locking concept are referred to as a standard lock.
The CSL Locks Dedicated Objects Only
The key of a CSL token contains the name and the (concatenated) lock arguments of an ABAP Dictionary lock object, as well as the logical system. This suggests at a first glance that the CSL uses this standard lock object for a CSL lock, too. However, this is not the case. The CSL uses the name of the standard lock object including lock arguments for the sole purpose of identifying a token. Therefore, if an application requests a CSL lock, the standard lock is not used.
The CSL still uses standard lock objects since parallel processes of a logical system compete for one token. Access to the token table (CSL_MTLK) is therefore protected by a standard lock so that a maximum of one (sub)process can access a token at once.
Releasing Locks
Locks can be explicitly released using the function modules of the CSL. Since the assignment of a token in the token manager is protected by a standard lock, CSL locks are released at the end of an update at the latest (implicit DEQUEUE_ALL). The CSL provides a procedure to retain locks for multiple LUWs (see: Duration of a CSL Lock).