The Owner Concept 

At the start of an R/3 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. This is determined by the ABAP programmer using the _SCOPE parameter (see Function Modules for Lock Requests).

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 following diagram shows the locks during the course of an SAP LUW in conjunction with the _SCOPE parameter. The application programmer uses this parameter to determine which of the two owners should actually own the lock. The diagram also shows how long the R/3 locks are active (these are not the actual database locks, as described under Functions of the R/3 Lock Concept).

_SCOPE can have the values 1 , 2 , or 3 :

_SCOPE = 1

The lock belongs to Owner_1 only and, therefore, only exists in the dialog transaction.

_SCOPE = 2

The lock belongs to Owner_2 only and, therefore, is transferred to the update process

_SCOPE = 3

The lock belongs to Owner_1 and Owner_2.

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.

See also:

The Lock Table

Lock Collisions

Cumulation of Locks