EJB-Container

Ein EJB-Container (Enterprise JavaBeans) stellt eine Laufzeitumgebung für Enterprise-Beans im Anwendungsserver bereit. Der Container ist für alle Aspekte der Ausführung einer Enterprise-Bean im Anwendungsserver zuständig und wirkt als Vermittler zwischen der benutzerdefinierten Geschäftslogik der Bean und dem Rest der Anwendungsserverumgebung.

In einem Container können ein oder mehrere EJB-Module installiert sein, von denen jedes eine oder mehrere Enterprise-Beans enthält.

Der EJB-Container stellt der Enterprise-Bean zahlreiche Services zur Verfügung. Einige davon sind im Folgenden aufgeführt:
  • Starten, Festschreiben und Rückgängigmachen von Transaktionen nach Bedarf.
  • Verwaltung von Pools von Enterprise-Bean-Instanzen für eingehende Anforderungen und Verschieben dieser Instanzen zwischen den inaktiven Pools und einem aktiven Status, wobei sichergestellt ist, dass die Bedingungen für Threading innerhalb der Bean erfüllt sind.
  • (Besonders wichtig) Automatische Synchronisation der Daten in den Variablen von Entity-Bean-Instanzen mit entsprechenden Datenelementen, die im persistenten Speicher abgelegt sind.

Durch die dynamische Verwaltung aktiver Bean-Instanzen und die Synchronisation des Bean-Status mit dem persistenten Speicher beim Verschieben der Beans in den und aus dem aktiven Status ermöglicht der Container einer Anwendung, mehr Bean-Instanzen zu verwalten, als sonst parallel im Speicher des Anwendungsservers gehalten werden könnten. Aus dieser Perspektive betrachtet stellt ein EJB-Container Services bereit, die mit denen eines virtuellen Speichers in einem Betriebssystem vergleichbar sind.

WebSphere Application Server bietet eine große Flexibilität bei der Verwaltung von Datenbankdaten mit Entity-Beans. Die Konfigurationseinstellungen "Aktivieren um" und "Laden um" für Entity-EJBs geben an, wie und wann Cachedaten aus den zugehörigen Datenbankzeilendaten einer Enterprise-Bean geladen werden sollen. Diese Konfigurationseinstellungen bieten die Möglichkeit, die Caching-Optionen A, B oder C für Enterprise-Beans gemäß der Spezifikation EJB 1.1 anzugeben. Diese Konfigurationseinstellungen können mit Assembliertools konfiguriert werden. Weitere Informationen zur Verwendung der Assembliertools finden Sie im Information Center zu den Assembliertools.

Zwischen Transaktionen kann der Status der Entity-Bean zwischengespeichert werden. Der EJB-Container unterstützt die Optionen A, B und C für das Zwischenspeichern.
  • Beim Zwischenspeichern nach Option A nimmt der Anwendungsserver an, dass die Entity-Bean in nur einem Container verwendet wird. Clients dieser Bean müssen ihre Anforderungen an die Bean-Instanz in diesem Container senden. Die Entity-Bean hat exklusiven Zugriff auf die zugrunde liegende Datenbank, d. h. die Bean kann beim Zwischenspeichern nach Option A weder geklont werden noch in das Workload-Management einbezogen werden.
    Wenn Sie schreibgeschützte Szenarien verwenden möchten, stellt das Produkt eine andere Variante der Entity-Beans von Option A mit einer höheren Leistung bereit. Diese Caching-Option wird als Multithread-Read-Only. Analog zum Standardverhalten von Option A aktiviert der EJB-Container die Bean weiterhin nur einmal und lässt sie aktiv, bis der EJB-Container Speicher im Cache seiner Instanz benötigt. Allerdings unterscheidet der EJB-Container sich in folgenden Punkten von der Standardoption A:
    • Der Container lädt den Status der Bean regelmäßig erneut aus dem persistenten Speicher und reagiert so darauf, dass der Benutzer eine Methode für die Bean aufgerufen hat. Dabei werden alle Änderungen, die möglicherweise seit dem letzten Laden der Bean am persistenten Speicher vorgenommen wurden, übernommen. Sie können diese Funktion über eine Einstellung Intervall für erneutes Laden im Implementierungsdeskriptor der Bean konfigurieren. Weitere Informationen finden Sie im Artikel "Schreibgeschützte Entity-Beans entwickeln".
    • Der Status der Bean wird am Ende der Transaktion weder vom EJB-Container in einen persistenten Speicher geschrieben noch wird die Methode "ejbStore()" der Bean aufgerufen.
    • Der EJB-Container lässt Methodenaufrufe von mehreren Clients (Threads) in derselben Bean-Instanz zu. Das unterscheidet sich von der EJB-Standardkomponente für die internen Elemente einer Bean. Sie müssen diesen Aspekt bei der Entwicklung der Bean berücksichtigen und sicherstellen, dass die gesamte Logik in den Geschäftsmethoden der Bean sicher für Threads ist.
  • Beim Zwischenspeichern nach Option B bleibt die Entity-Bean während der gesamten Transaktion im Cache aktiv, wird aber beim Start jedes Methodenaufrufs erneut geladen.
  • Beim Zwischenspeichern nach Option C (Standardeinstellung) wird die Entity-Bean am Anfang jeder Transaktion erneut aus der Datenbank geladen. Ein Client kann versuchen, auf die Bean zuzugreifen und eine neue Transaktion in einem beliebigen Container, der als Host dieser Bean konfiguriert wurde, zu starten. Dieser Vorgang gleicht dem Erstellen von Sitzungsclustern für HTTP-Sitzungen insofern, als der Status der Entity-Bean in einer gemeinsam genutzten Datenbank verwaltet wird, auf die alle Server bei Bedarf zugreifen können.

Option A bietet eine maximale Enterprise-Bean-Leistung durch Zwischenspeicherung der Datenbankdaten außerhalb des Transaktionskontextes. Im Allgemeinen ist Option A nur für EJB-Container anwendbar, die exklusiven Zugriff auf die entsprechende Datenbank haben. Andernfalls wird die Datenintegrität beeinträchtigt. Option B ermöglicht eine aggressivere Zwischenspeicherung von Instanzen des Entity-EJB-Objekts, die gegenüber Option C eine bessere Leistung, aber auch eine höhere Speicherbelegung zur Folge haben kann. Option C ist die häufigste Konfiguration, die tatsächlich für Entity-EJBs verwendet wird. Dies ist die Standardeinstellung.

Die Einstellung Aktivieren um gibt den Zeitpunkt an, zu dem die Enterprise-Bean aktiviert und zwischengespeichert wird. Diese Einstellung legt außerdem fest, wann die Bean aus dem Cache entfernt und inaktiviert wird. Die gültigen Werte sind Einmal und Transaktion. Die Einstellung Einmal legt fest, dass die Bean aktiviert wird, wenn sie im Serverprozess zum ersten Mal aufgerufen wird, und dass nach Entscheidung des Containers inaktiviert (und aus dem Cache entfernt) wird, beispielsweise, wenn der Cache voll ist. Die Einstellung Transaktion legt fest, dass die Bean am Anfang einer Transaktion aktiviert und am Ende einer Transaktion inaktiviert (und aus dem Cache entfernt) wird. Der Standardwert ist Transaktion.

Die Einstellung Laden um gibt an, wann die Bean ihren Status aus der Datenbank lädt. Der Wert dieser Eigenschaft bestimmt, ob der Container exklusiven Zugriff oder gemeinsamen Zugriff auf die Datenbank hat. Die gültigen Werte sind Aktivierung und Transaktion. "Aktivierung" bedeutet, dass die Bean dann geladen wird, wenn sie aktiviert wird. Außerdem impliziert dieser Wert, dass der Container exklusiven Zugriff auf die Datenbank hat. "Transaktion" bedeutet, dass die Bean am Anfang einer Transaktion geladen wird. Außerdem impliziert dieser Wert, dass der Container gemeinsamen Zugriff auf die Datenbank hat. Der Standardwert ist Transaktion. Die Einstellungen der Eigenschaften Aktivieren um und Laden um bestimmen, welche Festschreibungsoptionen verwendet werden. Für Option A (exklusiver Datenbankzugriff) sollte Aktivieren um = Einmal und Laden um = Aktivierung verwendet werden. Diese Option reduziert die Anzahl der Datenbankein-/-ausgaben, indem Aufrufe der Funktion "ejbLoad" vermieden werden, serialisiert aber alle Transaktionen, die auf die Bean-Instanz zugreifen. Option A kann eine höhere Speicherbelegung zur Folge haben, weil eine größere Anzahl Objekte im Cache zwischengespeichert wird, aber sie kann eine bessere Antwortzeit ermöglichen, wenn Bean-Instanzen in der Regel nicht gleichzeitig von mehreren Transaktionen aufgerufen werden.
Wichtig: Bei Verwendung von WebSphere WebSphere Application Server Network Deployment mit Workload-Management kann Option A nicht verwendet werden.

Sie müssen Einstellungen verwenden, die die Verwendung der Option B oder C zur Folge haben. Für Option B (gemeinsamer Datenbankzugriff) muss Aktivieren um = Einmal und Laden um = Transaktion verwendet werden. Option B kann die Speicherbelegung erhöhen, indem eine größere Anzahl Objekte im Cache zwischengespeichert wird. Weil aber jede Transaktion eine eigene Kopie eines Objekts erstellt, können gleichzeitig mehrere Kopien einer Instanz gespeichert werden (eine pro Transaktion), sodass bei jeder Transaktion ein Datenbankzugriff erforderlich ist. Wenn eine Enterprise-Bean eine große Anzahl Aufrufe der Funktion "ejbActivate" enthält, kann die Verwendung der Option B hilfreich sein, weil das erforderliche Objekt bereits im Cache zwischengespeichert ist. Andernfalls bietet diese Option keinen erkennbaren Vorteil gegenüber Option A. Verwenden Sie für Option C (gemeinsamer Datenbankzugriff) Aktivieren um = Transaktion und Laden um = Transaktion. Diese Option kann die Speicherbelegung verringern, indem weniger Objekte im Cache zwischengespeichert werden. Allerdings können gleichzeitig mehrere Kopien einer Instanz gespeichert werden (eine pro Transaktion). Diese Option kann die Wahrscheinlichkeit von Transaktionskonflikten für Enterprise-Beans verringern, die gleichzeitig aufgerufen, aber nicht aktualisiert werden.

Das Produkt unterstützt das Klonen von Home-Objekten von Stateful-Session-Beans in mehreren Anwendungsservern. Das Klonen einer speziellen Instanz einer Stateful-Session-Bean wird jedoch nicht unterstützt. Jede Instanz einer Stateful-Session-Bean darf in nur einem Anwendungsserver vorhanden sein. Der Zugriff auf die Instanz ist nur durch Senden von Anforderungen an diesen Anwendungsserver möglich. Die Statusinformationen einer Stateful-Session-Bean können nicht von mehreren Membern eines Server-Cluster verwaltet werden. Wenn Sie jedoch das Failover für Stateful-Session-Beans aktivieren und den EJB-Container für die Replikation zwischen Speichern konfigurieren, kann das Failover für Stateful-Session-Beans auf andere Server im Cluster repliziert werden, damit das Failover auf den Backup-Server durchgeführt werden kann, falls der Primärserver für eine Stateful-Session-Bean aus irgendeinem Grund gestoppt wird. Weitere Informationen zum Failover von Stateful Session-Beans finden Sie im Abschnitt zum Failover von Stateful-Session-Beans für den EJB-Container.

Standardmäßig wird ein EJB-Container im Schnellstartmodus ausgeführt. Die Startlogik des EJB-Containers verzögert das Laden und Verarbeiten aller EJB-Typen außer nachrichtengesteuerte Beans (Message Driven Beans), da diese Beans vorhanden sein müssen, bevor Nachrichten für sie übergeben werden, Startup-Beans, die beim Serverstart verarbeitet werden müssen und jener EJB-Typen, die beim Serverstart initialisiert werden. .

Die gesamte übrige EJB-Initialisierung wird bis zur ersten Verwendung des EJB-Typs verzögert. Für lokale Schnittstellen gilt als erste Verwendung die Ausführung der Methode "InitialContext.lookup" für den Typ. Für ferne Schnittstellen gilt als erste Verwendung das Aufrufen der ersten Methode für eine EJB oder deren Home.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_ecnt
Dateiname:cejb_ecnt.html