SAP Transactions and the VM Container 

Since the VM container technology is integrated in the ABAP Application Server, the proven SAP ABAP transaction concept with roll-in, roll-out, and update can be used:

Roll-out in the VM Container

In SAP terminology roll-out refers to decoupling the user context from the Work Process. A roll-out takes place when a user context can no longer be processed. This might happen because:

●      An action from the user

●      The return of a remote function call.

After the user context has been rolled out, the work process can start to process another user context. This can be compared with an operating system that suspends a process waiting for an IO, and then starts to run another process. The work process plays the role of a CPU. As soon as the wait for a user context has resolved (for instance, the user action is completed), the user context can be reloaded by a roll-in into a work process (not necessarily the same one), and processed further there.

This concept enables the number of work processes to be much smaller than the number of active users. At the same time it enables maximum parallelism in the server and in particular on the database to be regularized.

So that a Java program can run in the VM container, a Java VM must be attached to a work process (VM attach). Only one Java VM can be active at any one time in a work process. Once the Java program has run through, the Java VM can be detached (VM detach). The assignment of Java VMs to work processes is integrated in the VM Container with the roll-in and roll-out of user contexts:

●      At the start of an action the user context is loaded into the work process that is running.

●      If a Java VM is required, a free VM is attached to the work process.

●      As long as at least one active Java thread exists, the Java VM remains attached to the work process.

●      Once no threads can run any longer, the VM is detached from the work process (VM detach), and the associated user context separated from the work process (roll-out).

The reasons why VMs may have to wait are:

●      JCo/RFC communication

●      TCP/IP-based communication

●      Java program has deactivated itself for a period of time (for instance, by calling the method Thread.sleep)

SAP Transaction Concept in the VM Container

The SAP transaction concept decouples SAP LUWs (logical units of work) and database LUWs: the database changes are collected and executed together at the end of the SAP LUW. For this reason SAP has implemented its own update and lock concept. The concepts are described in the sections below:

SAP Transaction Versus Database Transaction

Features of the Update

The Update Process

SAP Lock Concept

The SAP Lock Concept (BC-CST-EQ)

Relationship Between SAP Locks and Database Locks

Because of these concepts an implicit database commit is executed with each roll-out in the VM container too. If a user context is separated from the work process (roll-out), all database activities are executed by the implicit commit (DB commit, not SAP commit). This ensures that a later request does not affect an earlier request at database level.

Since each wait situation in the VM container can lead to a roll-out, the VMCs contain an implicit commit. This is valid for TCP/IP-based communication as well as for explicit wait situations triggered by a sleep call.

Communication Between ABAP and Java in the VM Container

In the VM container the following situations in the communication between ABAP and Java are differentiated:

●      Out-of-process calls: The called function is processed in a new server context and at least in a different processing step. (It is possible that the same work process processes the request following a roll-out.)

Out-of-process calls are necessary when the client and server are communicating across a network. The ABAP semantics for these calls ensure an implicit commit, even if no roll-out takes place during RFC processing (in some cases the response is waited for online). Out-of-process calls in the VM container behave accordingly.

●      In-process-calls: Here the called function is processed in the same work process. This type of RFC is only available in the VM container. A Java function can be called in an ABAP program in the following way:

CALL FUNCTION ‚XYZ’ DESTINATION SPACE..

The semantics of DESTINATION SPACE (in ABAP) ensures that no implicit (DB) commit takes place. It is irrelevant whether an ABAP or a Java function is called.