Show TOC

Background documentationTransaction Mode Locate this document in the navigation structure

 

Since the Transaction Service of the Object Services is connected to classic transaction processing or is itself part of the SAP LUWs, a program must be able to determine whether it is working with classic or object-oriented transactions. This is the reason for introducing the transaction mode, which can be defined once for each program.

Each program working with persistent objects has a transaction mode that is defined either explicitly or implicitly when the Object Services are initialized. Each program also has what is called a top level transaction (a transaction object whose reference can be obtained with method IF_OS_TRANSACTION_MANAGER~GET_TOP_TRANSACTION) while it is working with persistent objects. The top level transaction is responsible for updating the persistent objects. The program's transaction mode is also the transaction mode of the top level transaction and can be queried with method IF_OS_TRANSACTION~GET_MODES in parameter E_EXTERNAL_COMMIT.

There are two transaction modes:

  • Compatibility Mode

    Compatibility mode (E_EXTERNAL_COMMIT is OSCON_TRUE) lets you use persistent objects within classic SAP LUWs. The COMMIT WORK statement must be defined explicitly in the program in order to record changes. As described in Persistent Objects and COMMIT WORK, implicit methods of the Persistence Service are called during execution to record the changes to persistent objects.

    When using the Persistence Service in compatibility mode, the system always implicitly starts one update process, which also deletes any locks in the update task.

  • Object-Oriented Transaction Mode

    Object-oriented transaction mode (E_EXTERNAL_COMMIT is OSCON_FALSE) lets you write new fully object-oriented applications without you having to worry about the COMMIT WORK statement. In object-oriented transaction mode, COMMIT WORK is triggered when you call method END for a top level transaction. The COMMIT WORK statement is not allowed in an object-oriented transaction.

You can define the transaction mode and create the top level transaction as follows:

  • If in a program, method CL_OS_SYSTEM=>INIT_AND_SET_MODE was not yet executed prior to the first access to the Persistence Service, the Persistence Service starts it with the default values that set the transaction mode to compatibility mode and the update mode (see below) to asynchronous. A top level transaction is implicitly created and started at this time to handle the persistent objects of the program. All other transactions that are started in the program with IF_OS_TRANSACTION~START are subtransactions of the top level transaction running in compatibility mode. This permits you to work in classic ABAP programs with persistent objects without having to explicitly worry about the transaction mode. You can find an example under Creating a Persistent Object.

  • If method CL_OS_SYSTEM=>INIT_AND_SET_MODE is executed before you access the Persistence Service in a program for the first time, you can explicitly set the transaction mode to compatibility mode or object-oriented mode by passing the values OSCON_TRUE or OSCON_FALSE to parameter I_EXTERNAL_COMMIT. Since the static constructors of the Persistence Service are usually executed at the beginning of a processing block, you can use event LOAD-OF-PROGRAM or the constructor of an application class, for example, to call CL_OS_SYSTEM=>INIT_AND_SET_MODE. A program that was not started as OO transaction can thus be executed as an object-oriented transaction. In object-oriented transaction mode, the first transaction that is started in the program with IF_OS_TRANSACTION~START is a top level transaction, whereas in compatibility mode, the top level transaction is always created implicitly.

  • If the O-Transaction model field is selected when you create an object-oriented transaction in the ABAP Workbench, the transaction mode of the corresponding program is automatically set to object-oriented (CLASS_OS_SYSTEM=>IN_AND_SET_MODE is executed implicitly with the relevant parameters) when the transaction is called. The first transaction that is started in the program with IF_OS_TRANSACTION~START is a top level transaction.

Update Modes

At the end of a top level transaction (with COMMIT WORK in compatibility mode or method IF_OS_TRANSACTION~END in object-oriented mode), the Transaction Service updates the changes to persistent objects in the database. Internal update function modules are started implicitly at this time. You can define a mode for the update, as for classic updates.

You can set the mode either when you initialize the Object Services with method CL_OS_SYSTEM=>INIT_AND_SET_MODE or once after starting the top level transaction with method IF_OS_TRANSACTION~SET_MODE_UPDATE. Since CL_OS_SYSTEM=>INIT_AND_SET_MODE can only be called once for each program, IF_OS_TRANSACTION~SET_MODE_UPDATE permits you to change an update mode that was set implicitly.

Input parameter I_UPDATE_MODE with type OS_DMODE can be used for both methods to set the update mode. You can pass the following values:

  • OSCON_DMODE_DEFAULT or OSCON_DMODE_UPDATE_TASK for asynchronous updates

  • OSCON_DMODE_DIRECT for direct updates

  • OSCON_DMODE_LOCAL for local updates

  • 0OSCON_DMODE_UPDATE_TASK_SYNC for synchronous updates

OSCON_DMODE_LOCAL and OSCON_DMODE_UPDATE_TASK_SYNC are only allowed in object-oriented transaction mode since they can be set in compatibility mode using ABAP statements (COMMIT WORK AND WAIT and SET UPDATE TASK LOCAL).

When you create an object-oriented transaction in the ABAP Workbench, the initial update mode of the top level transaction is defined through selection of the relevant radio button.