SAP-Transaktionen und VM Container

Roll-out im VM Container

Roll-out bedeutet in der SAP-Terminologie das Entkoppeln des Benutzerkontextes vom Workprozess. Ein Roll-out findet statt, wenn ein Benutzerkontext nicht weiter bearbeitet werden kann. Dies kann folgende Gründe haben:

• Das Programm wartet auf eine Aktion des Benutzers

• Das Programm wartet auf die Rückkehr eines RFC-Aufrufes (Remote Function Call)

Nach dem Roll-out des Benutzerkontextes kann der Workprozess einen anderen Benutzerkontext bearbeiten. Dies kann man mit einem Betriebssystem vergleichen, welches einen auf IO wartenden Prozess suspendiert und anschließend einen anderen Prozess bearbeitet. Der Workprozess spielt hierbei die Rolle einer CPU. Sobald sich die Wartesituation für einen Benutzerkontext aufgelöst hat (z.B. die Aktion des Benutzers erfolgt ist), kann er per Roll-in wieder in einen Workprozess geladen werden (nicht notwendigerweise der gleiche) und dort weiter bearbeitet werden.

Dieses Konzept ermöglicht es, dass die Anzahl von Workprozessen weitaus geringer als die Anzahl der aktiven Benutzer sein kann. Gleichzeitig ermöglicht es, die maximale Parallelität in einem Server und insbesondere auf der Datenbank zu reglementieren.

Damit im VM Container ein Java-Programm ablaufen kann, muss eine Java-VM mit einem Workprozess verknüpft werden (VM attach). In einem Workprozess kann zu einer Zeit nur eine Java VM aktiv sein. Nach Ablauf des Java-Programmes kann diese Verknüfpung wieder gelöst werden (VM detach). Dieses Zuordnen von Java-VMs zu Workprozessen wird im VM Container mit dem Roll-in und Roll-out von Benutzerkontexten kombiniert:

• Zu Beginn einer Aktion wird zunächst der Benutzerkontext in den ausführenden Workprozess geladen (Roll-in)

• Falls eine Java VM benötigt wird, wird eine freie VM mit dem Workprozess verknüpft (VM Attach).

• Solange mindestens ein ablauffähiger Java-Thread vorhanden ist, bleibt die Java VM mit dem Workprozess verknüpft

• Wenn kein Thread weiterlaufen kann, wird die VM vom Workprozess gelöst (VM detach) und der zugehörige Benutzer-Kontext vom Workprozess getrennt (Roll-out)

Wartegründe für VMs können sein:

• JCo/RFC-Kommunikation

• TCP/IP basierte Kommunikation

• Java Programm hat sich für eine Zeitspanne deaktiviert (z.B. durch Aufruf der Methode Thread.sleep)

SAP-Transaktionskonzept im VM Container

Das SAP-Transaktionskonzept entkoppelt SAP-LUWs (Logical Units of Work) und Datenbank-LUWs: die Datenbankänderungen werden gesammelt und gemeinsam am Ende der SAP-LUW durchgeführt. Aus diesem Grund hat SAP ein eigenes Verbuchungs- und Sperrkonzept implementiert. Die Konzepte sind in folgenden Abschnitten beschrieben.

SAP-Transaktion vs. Datenbank-Transaktion

Funktionsweise der Verbuchung

Der Verbuchungsprozess

SAP Sperrkonzept

Das SAP Sperrkonzept (BC-CST-EQ)

Zusammenhang zwischen SAP-Sperren und Datenbanksperren

Aufgrund dieser Konzepte wird auch im VM Container bei jedem Roll-out ein impliziter (Datenbank-)Commit durchgeführt. Wenn ein Benutzerkontext vom Workprozess getrennt wird (Roll-out), werden durch den impliziten Commit alle DB-Aktivitäten kommitiert (DB-Commit, nicht SAP-Commit). Dies gewährleistet, dass ein späterer Request einen vorigen auf DB-Ebene nicht beeinträchtigen kann.

Da jede Wartesituation im VM-Container ebenfalls zum Roll-out führen kann, beinhalten sie einen impliziten Commit. Dies gilt z.B. für TCP/IP basierte Kommunikation als auch das explizite Warten per sleep-Aufruf.

Kommunikation zwischen ABAP und Java im VM Container

Bei der Kommunikation zwischen ABAP und Java werden im VM Container folgende Fälle unterschieden:

• Out-of-Process-Aufrufe: Hier wird die gerufene Funktion in einem neuen Server-Kontext und zumindest in einem anderen Verarbeitungsschritt bearbeitet. (Es ist möglich, dass der selbe Workprozess nach einem Roll-out den Request bearbeitet.)

  Out-of-Process-Aufrufe werden benötigt, wenn Client und Server über ein Netzwerk kommunizieren. Die ABAP-Semantik für solche Aufrufe garantiert einen impliziten Commit, auch wenn bei der RFC-Bearbeitung kein Roll-out stattfindet (in manchen Fällen wird inline auf die Antwort gewartet). Entsprechend verhalten sich Out-of-Process-Aufrufe im VM Container.

• In-Process-Aufrufe: Hier wird die gerufene Funktion im selben Workprozess abgearbeitet. Diese Art von RFC steht nur im VM Container zur Verfügung. In einem ABAP-Programm kann eine Java-Funktion wie folgt aufgerufen werden:

  CALL FUNCTION 'XYZ' DESTINATION SPACE..

  Die Semantik von DESTINATION SPACE (in ABAP) gewährleistet, dass kein impliziter (DB-)Commit stattfindet. Dabei spielt es keine Rolle, ob eine ABAP- oder eine Java-Funktion gerufen wird.