The Owner Concept 
At the start of an SAP transaction, two owners are always created and can request locks.
An owner is identified by his or her owner ID, as described in the section entitled The Lock Table.
A lock can have one or two owners. The ABAP programmer uses the _SCOPE parameter to define this (see below).
The diagram below shows an example of an SAP LUW from a lock perspective.
At the start of the dialog transaction, the system creates two lock owners: the dialog owner Owner_1 and the update owner Owner_2.
During the course of the transaction, Owner_1 requests a lock, as does Owner_2 slightly later. When the update task is called (see also Functions of the Update Task), the lock and Owner_2 are inherited by the update task. An update work process is started with two owners, in the same way as a dialog work process, and then has three owners until the update is completed. All of the locks are released with an implicit DEQUEUE_ALL at the end of the update, at the latest.
The _SCOPE Parameter
The application programmer uses this parameter to determine which of the two owners should actually own the lock. _SCOPEcan have the values 1, 2, or 3:
|
_SCOPE = 1 |
The lock belongs to owner_1 only and therefore only exists in the dialog transaction. The DEQUEUE call or the end of the transaction, not COMMIT WORK or ROLLBACK WORK, cancels the lock. |
|
_SCOPE = 2 |
The lock belongs to owner_2 only. Therefore, the update inherits the lock when CALL FUNCTION ‘…‘ IN UPDATE TASK and COMMIT WORK are called. The lock is released when the update transaction is complete. You can release the lock before it is transferred to the update using ROLLBACK WORK. COMMIT WORK has no effect, unless CALL FUNCTION ‘…‘ IN UPDATE TASK has been called. |
|
_SCOPE = 3 |
The lock belongs to owner_1 and owner_2. In other words, it combines the behavior of both. This lock is canceled when the last of the two owners has released it. |
For more information, see Function Modules for Lock Requests.
The following diagram shows the locks during the course of an SAP LUW in conjunction with the _SCOPE parameter. The diagram also shows how long the SAP locks are active (these are not the actual database locks, as described under Functions of the SAP Lock Concept).
The lock remains in place until either the relevant DEQUEUE function module is called or (as shown in the diagram) the transaction is completed with an implicit DEQUEUE_ALL.
During the course of the transaction in this example, the lock object A (which was created previously by the programmer in the ABAP Dictionary) is locked by the function call CALL FUNCTION 'ENQUEUE_A'. Since the _SCOPE parameter is set to 1, the lock A is not forwarded to the update task (it belongs to the dialog owner E_1 only) and, therefore, is released with the function call DEQUEUE_A or, at the latest, at the end of the dialog transaction.
Later, the lock B, which belongs to E_2 (the update owner) (_SCOPE=2), and the lock C, which has two owners (_SCOPE=3), are requested. The CALL FUNCTION '…' IN UPDATE TASK generates an update request. At COMMIT WORK, the update task is called and inherits the locks and the update owner of locks B and C. These locks are released when the update is completed. Lock C of the dialog owner, however, may exist longer (depending on how the transaction is programmed).
Dialog locks A and C remain in place until the end of the dialog transaction.
If a lock is set with _SCOPE=2, and the COMMIT WORK is called before the CALL FUNCTION ‘…‘ IN UPDATE TASK, the lock remains in place as a dialog lock until this point in time (displayed in black in the overview screen of transaction SM12). At this point in time, it is not yet possible to transfer the lock to an update work process.
Only CALL FUNCTION ‘…‘ IN UPDATE TASK and COMMIT WORK called at a later point in time, cause the lock to be transferred to the update process. It is then displayed in blue in the overview screen of SM12.
See also: