Show TOC

Ressourcenverwaltung im VM ContainerLocate this document in the navigation structure

Verwendung

Die beteiligten Komponenten und Ressourcen bei der Bearbeitung eines Java-Requests durch einen Benutzer sind die folgenden:

  • Die Workprozesse blenden eine freie Java VM aus dem VM Pool ein ( attach) und stellen diese am Ende der Requestbearbeitung wieder in den Pool zurück ( detach).

  • Die Benutzerkontexte liegen im Shared Memory.

  • Die Java VMs verwenden einen Benutzerkontext und bearbeiten den Request (wie bei ABAP-Anfragen auch).

Aus dem Blickwinkel der Isolation wäre es sinnvoll, eine Java-VM pro Benutzer zu starten. Aufgrund des hohen Speicherbedarfs und der Zeit, die eine Java-VM zum Starten benötigt, gibt es einen VM Pool, aus dem VMs nach Bedarf an Workprozesse gebunden werden. Dieser Pool muss mehr VMs enthalten als Workprozesse konfiguriert sind, da in bestimmten Fällen eine VM auch dann fest einem Benutzer zugeordnet bleibt, wenn sie den Workprozess nicht akut benötigt (Warten auf den Abschluss einer I/O Operation oder Debugging).

Im Shared Memory liegen Daten, die zwischen allen VMs geteilt werden. Dies beinhaltet

  • Shared Classes, d.h. geladene Java-Klassen, die von einer der VMs initial geladen wurden und dann allen VMs zur Verfügung stehen ("Engine Shared Data", ähnlich dem ABAP PXA). Die Shared Classes enthalten den Byte-Code der Klassen, ihren Konstanten-Pool und den vom Just-In-Time-Compiler generierten Native-Code.

  • Konfigurationsdaten, die von allen VMs benötigt werden.

Im Shared Memory liegen auch die Benutzerkontexte, die dann bei Bedarf in die VM des Workprozesses kopiert werden.

Hinweis

Anders als bei ABAP werden die Benutzerkontexte nicht eingeblendet, sondern tatsächlich in die VM kopiert und nach Bearbeitung des Requests zurückkopiert. Dies ist notwendig, da bei jeder Veränderung der Benutzerkontexte potentiell Referenzen auf lokale Objekte eingetragen werden könnten und diese lokalen Referenzen in einer anderen VM keine Gültigkeit mehr hätten. Daher muss der Objekt-Baum jedes Mal durchgearbeitet werden.

Überschreitet der Kontext eine gewisse Größe, wird die VM für den Benutzer reserviert. Sie ist dann nicht mehr rollbar, dafür muss der Kontext nicht mehr in die VM kopiert werden.

Die VM bleibt solange im Workprozess, wie sie etwas tun kann, d.h. einer ihrer Threads läuft. Wenn kein Thread "runnable" ist (z.B. weil der Request abgearbeitet wurde und man jetzt auf den nächsten Request wartet), wird die VM vom Workprozess getrennt (detach). Je nach Zustand der VM wird sie in den VM-Pool gestellt (damit sie für "beliebige" neue Requests verwendet werden kann) oder bleibt dem Benutzer zugeordnet (I/O-Fall, siehe oben).

Natürlich können mehrere Benutzerkontexte gleichzeitig in verschiedenen Workprozessen bearbeitet werden, wie dies auch im ABAP der Fall ist.