V1 and V2 Updates

V1 and V2 are two types of update modules. The V1 and V2 concepts allow database changes to be divided into high-priority and low-priority requests. This enables the database accesses to be better distributed over time. The type of update module determines its processing mode. In one SAP LUW (Logical Unit of Work), update modules of types V1 and V2 may be mixed. At the beginning of the update process, all V1 requests are executed as an independent DB (Database) LUW. V2 requests are processed as an independent DB LUW only if the system executes all V1 requests successfully.

 

V2 update modules are used for database changes that are linked to the V1 changes (main changes) but do not necessarily have to be executed in the same DB LUW (for example, updating of statistics).

 

 

Generate V1 and V2 Requests

V1 update modules create requests in the log table(s) for synchronous and asynchronous updates. However, they create requests in main memory if local update mode is used.

 

V2 requests are always stored in the log table(s), independent of the update mode.

 

 

Update Execution

The system processes V1 requests in a V1 update work process (type “UPD”) as an independent DB LUW. If the V1 update is successful, the system deletes the V1 requests and all the locks passed on to the update task, sets a DB Commit and triggers the V2 update.

 

The system executes V2 requests in a V2 update work process (type “UP2”). These form an independent DB LUW. If no V2 update work process is set up in the Application Server ABAP, the system executes V2 requests in a V1 update work process. If the system processes all the V2 requests successfully, they are removed from the log table(s) and the system also sets a DB Commit. V2 requests generally run without locks because these are deleted upon completion of the V1 update.

 

 

Set Locks in the Update

The locks created from within the dialog program using _scope = 2 (default) are transferred to the V1 update task at COMMIT WORK (AND WAIT). At the end of a successful V1 update, the locks are automatically deleted. If an error terminates the update with the issue of a termination message, the locks are deleted by default. In general, lock entries must not be explicitly removed either in the dialog program (too early) or in the update module (unnecessary).

 

The V2 update always runs without SAP locks.

 

 

Optimization of Database Changes

Each time a change is updated in the database, the record to be changed is physically locked by the database up to the end of the current database LUW (DB commit or DB rollback). The same applies if you read with SELECT ... FOR UPDATE. This process is applicable only for a parallel update or SELECT ... FOR UPDATE, but not for a read access.

 

However, it is a good idea for performance reasons to keep automatically-set database locks as short as possible. Read access works well, although there is a database lock and this depends on the isolation level that is maintained on a database system. But with SAP systems, the so called “dirty read” or “uncommitted read” is common (or even mandatory). For pure read, access locks are commonly not used. However, SAP locks are used and not the database locks.

 

You should adhere to the following rules when programming inline changes and update modules:

1. Create new table entries (INSERT). Their database locks pose the least “interference” for other users.
2. Perform table updates that are not critical to performance (UPDATE). As a rule, these are the tables that few users simultaneously access.
3. Perform changes to performance-critical tables (UPDATE). Tables that represent central resources in the system (tables accessed by several users simultaneously) should always be changed late, if possible, within an LUW so that the respective database locks hinder others only for a short time.

 

PERFORM ON COMMIT in the Update