When you activate a lock object in the ABAP Dictionary, the system automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
The system automatically assigns the generated function modules to function groups. You must not change these function modules and their assignment to function groups since the function modules are generated again each time you activate the lock object.
Do not transport the function groups that contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. You must always transport the lock objects. When you activate a lock object in the target system, the function modules are generated again and correctly assigned to function groups.
Parameters of the Function Modules
Field Names of the Lock Object
The keys to be locked must be passed here.
A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned to the initial value and the X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
Parameters for Passing Locks to the Update Program
The system removes the lock at the end of the transaction or when the corresponding DEQUEUE function module is called.
This is not the case if the transaction has called update routines. In this case, a parameter must check that the lock has been removed.
Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks ). You have the following options:
Locks or lock releases are not passed to the update program. The system removes the lock when the transaction is ended.
The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence over the lock behavior. This is the standard setting for the ENQUEUE function module.
The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
Parameters for Lock Mode
A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. The values allowed for this parameter are S (read lock), E (write lock), X (extended write lock), and O (optimistic lock).
The lock mode specified when you create the lock object for the table is the default value for this parameter. You can override this default value as required when the function module is called.
If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
Controlling Lock Transmission
Parameter _COLLECT controls whether the lock request or lock release must be performed directly, or whether it must first be written to the local lock container . This parameter can have the following values:
The system sends the lock request or lock release directly to the lock server.
The system places the lock request or lock release in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
Whenever you have lock mode X (extended write lock), locks must not be written to the local lock container if many locks refer to the same lock table. In this case, there is a considerable loss in performance in comparison with direct transmission of locks.
Behavior for Lock Conflicts (ENQUEUE only)
The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict .
You have the following options:
If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
If a lock attempt fails because there is a competing lock, the system repeats the lock attempt after a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
Controlling Deletion of the Lock Entry (DEQUEUE only)
The DEQUEUE function module also has the parameter _SYNCHRON.
If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the remove of the lock, the entry in the lock table can still exist.
Exceptions of the ENQUEUE Function Module
A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
Reference Fields for RFC-Enabled Lock Objects
The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module have the following reference fields for RFC-enabled lock objects: