Example: Infinite Transaction with Update 
Purpose
Some business transactions are implemented as infinite transactions to save time initializing at the start of the transaction. Optimistic Locks make this possible, since an optimistic lock is not converted into an exclusive lock until the change actually takes place. The update part of the lock is passed on to the update process, and released once the update has been completed. The dialog part of the optimistic lock remains as it is.
Programming
The objective is to request an optimistic lock, and then to retain the dialog part.
The graphic below illustrates the process.
Optimistic Lock with Update
First, the function module with the lock mode O and _SCOPE=1 is called (1). It then has an owner: the dialog owner is E_1.
In the course of the transaction the same lock with _SCOPE=2 is requested first, and another owner (E_2) is added to it (2). It now has two owners.
If data is to be changed, the update part of the lock is converted into an E lock. This is done by calling the function module with the lock mode 'R' and _SCOPE=2 (3). This operation results in two locks (see graphic below): The O lock with the dialog owner and the E lock with the update owner.
Then the update task is called (4) and the COMMIT WORK executed (5).
The COMMIT WORK calls the update task, which inherits the E lock and the update owner E_2. At the same time a new update owner is created for the dialog transaction (E_x).
At the end of the update, these locks are released. Now a lock with dialog owner E_1 and without an update owner exists again (see graphic below).
Caution
Only when the E lock in the update is released (6), can an O lock for the update owner E_x be created in the dialog (action (2)) You can use the _WAIT parameter to determine when this is done (see Function Modules for Lock Requests). Then the O lock can be converted into an E lock again (3).
The graphic below shows which locks are set by these operations in this example, which types the locks have, and which owners they have (with cumulation counter).
The lock actions are in time order from top to bottom.
Lock operations
(1) An optimistic lock with _SCOPE=1, that is, dialog owners only (E_1).
(2) An update owner is generated for the existing lock with _SCOPE=2 (E_2)2.
(3) The update part of the lock is converted into an exclusive lock (operation 'R', _SCOPE=2. This results in the O lock losing its update owner, and an additional E lock being created with the update owner E_2 (without dialog owners).
(4) Calling the update task cannot change this situation.
(5) With COMMIT WORK the update task is called, which inherits the E lock and the update owner E_2.
(6) Once the update is completed and the E lock released, only the O lock with the dialog owner exists again. The infinite transaction can now perform operation (2) again.