Java Reference
In-Depth Information
Beans“ sprechen werde. Wenn ein Client sich über den Namensdienst mit lookup einen
Stub für ein Session Bean bescha , bekommt er eine Fernsteuerung für ein dazu neu
erzeugtes Objekt. Der Client kann von der Vorstellung ausgehen, dass alle Methodenauf-
rufe, die er über diesen Stub absetzt, immer auf dasselbe Objekt weitergeleitet werden, so
dass der Zustand des Bean-Objekts zu Beginn des nächsten Methodenaufrufs derselbe ist
wie zum Ende des vorhergehenden Aufrufs. Zwar kann der Client davon ausgehen, als han-
dele es sich immer um dasselbe Bean-Objekt. Tatsächlich kommt jetzt hier eine der Funk-
tionen eines EJB-Servers ins Spiel: Wie schon erwähnt wurde, ist EJB für den Einsatz von
sehr vielen Clients gedacht. Wenn sehr viele Clients vorhanden sind, dann bedeutet dies,
dass man sehr viele Bean-Objekte benötigt. Wenn manche Clients aber für längere Zeit-
räume inaktiv sind, weil zum Beispiel bei einer interaktiven Anwendung der Benutzer eine
Zeit lang keine Eingaben vornimmt, so kann der EJB-Container die gleichzeitig existieren-
den Bean-Objekte reduzieren, indem er Objekte, die längere Zeit nicht benutzt worden sind,
in einen passiven Zustand versetzt. Dies bedeutet, dass der Zustand des Bean-Objekts abge-
speichert und das Bean-Objekt gelöscht wird. Sobald wieder ein Zugriff auf das passive
Objekt erfolgt, wird ein neues Objekt erzeugt und dieses auf den abgespeicherten Zustand
gesetzt. Für den Client sieht es so aus, als würde er mit demselben Objekt arbeiten, obwohl
es tatsächlich ein anderes Objekt ist, was aber für den Client irrelevant ist. In der State-
ful-Bean-Klasse können Methoden mit speziellen Annotationen versehen werden, die
unmittelbar vor der Passivierung bzw. nach der Reaktivierung aufgerufen werden. Es ist
dadurch möglich, anwendungsspezifi sche Aktionen durchzuführen, die über die vom Con-
tainer durchgeführte Funktionalität des Abspeicherns und Ladens der Attributwerte des
Bean-Objekts hinausgehen.
Methodenaufrufe auf ein und demselben Stateful-Bean-Objekt werden übrigens immer
sequenziell durchgeführt. Der Eff ekt ist also so, als wären alle öff entlichen Methoden als
synchronized gekennzeichnet. Parallele Aufrufe von unterschiedlichen Clients können in
der Regel nicht vorkommen. Es ist aber möglich, dass innerhalb eines Clients mehrere
Threads erzeugt werden, die denselben Stub benutzen. Auf diese Art können tatsächlich
parallele Aufrufe auf einem Stateful-Session-Objekt zustande kommen, die aber vom EJB-
Container sequenzialisiert werden, wie man leicht ausprobieren kann (s. Abschnitt 13.7).
13.4.2 Stateless Session Beans
So wie der Begriff „Stateful Session Bean“ ein Pleonasmus ist, ist „Stateless Session Bean“
ein Oxymoron, also ein Widerspruch in sich (wie „schwarzer Schimmel“ oder „heißes Eis“),
denn mit einer Session ist immer ein Zustand verbunden. Ich spreche daher lieber von
einem „Stateless Bean“ (der Name „Service Bean“ wäre auch passend). Wie zuvor erwähnt
wurde, muss für jedes Lookup eines Stateful Bean ein neues Bean-Objekt erzeugt werden.
Wenn man ein Bean als Stateless kennzeichnet, eröff net man dem EJB-Container weitaus
größere Gestaltungsmöglichkeiten. Der EJB-Container kann nämlich entscheiden, wie viele
Bean-Objekte er wann erzeugt und an welches Bean-Objekt ein Methodenaufruf weiterge-
reicht wird. Das heißt, dass es möglich ist, dass zwei Methodenaufrufe, die von einem Client
über denselben Stub abgesetzt werden, von demselben Objekt oder aber von unterschied-
lichen Bean-Objekten ausgeführt werden.
