As a rule, an application program is processed by multiple
work processes in succession, and every change of the work process is linked to an implicit
database commit. This means that an application program is not automatically associated with a single
database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
To ensure the data consistency of application programs that are executed across multiple work processes, the change statements are not executed directly in an SAP
LUW. Instead, they are first registered and then executed by a single work process, that is in a single database LUW.
The statement PERFORM ... ON COMMIT is used to register a subroutine to be executed later in a different work process.
Note
A function module can be specified as either an update function module or as remote-enabled, but not both at the same time. The update is used to realize SAP LUWs within
AS ABAP, while transactional RFC creates LUWs in distributed systems.
Statements for SAP LUWs
Each opening of a new internal
session (except for the statement CALL DIALOG) starts a new SAP LUW which can be controlled by the Open SQL statements
Each closing of an internal session ends the current SAP LUW.
Notes
The statements COMMIT WORK and ROLLBACK WORK
determine the limits of a SAP LUW. An ABAP program can be divided into any number of SAP LUWs, where
the end of an ABAP program always ends the last SAP LUW as well. By calling ABAP programs using CALL TRANSACTION or SUBMIT ... AND RETURN, SAP LUWs can be nested.
If a program is ended or an internal session closed using
SUBMIT without AND RETURN or LEAVE TO TRANSACTION and procedures are still registered in the current
SAP LUW, the SAP LUW is ended without the procedures being called or rolled back. Registered update function modules remain on the database but can no longer be executed.
The system class CL_SYSTEM_TRANSACTION_STATE contains methods that return the status of the current SAP LUW.