Java Reference
In-Depth Information
Wie für Stateful Beans gilt, dass Aufrufe auf demselben Bean-Objekt niemals parallel durch-
geführt werden. Wenn ein Methodenaufruf für ein Stateless-Bean-Objekt eintri , hat der
EJB-Container mehrere Möglichkeiten:
!
Der Container hält in der Regel eine Menge von Bean-Objekten zu jeder Stateless-Bean-
Klasse in einem Pool. Falls aktuell nicht auf allen Objekten Methodenaufrufe durchge-
führt werden, kann er irgendein im Moment nicht benutztes Objekt auswählen und den
Methodenaufruf an dieses Objekt durchstellen.
!
Falls alle Bean-Objekte im Gebrauch sind, kann er ein neues Objekt erzeugen, das nach
seiner Benutzung in den Pool wandert und zur Abarbeitung von Methodenaufrufen des-
selben oder eines anderen Clients zur Verfügung steht.
!
Wenn es kein im Moment unbenutztes Bean-Objekt gibt, der EJB-Container aber der Mei-
nung ist, dass schon genügend Objekte dieser Bean-Klasse vorhanden sind, dann muss er
den Aufruf so lange verzögern, bis wieder ein Bean-Objekt zur Verfügung steht.
Der EJB-Container löscht Objekte wieder, wenn er feststellt, dass er nur einen kleinen Teil
davon tatsächlich braucht. Die Anzahl der Objekte wird so vom EJB-Container an die aktu-
elle Belastung angepasst. Wenn die Anzahl der gleichzeitig durchgeführten Aufrufe nicht zu
hoch ist, dann ist die optimale Anzahl von Bean-Objekten die Anzahl der parallel auf dieser
Bean-Klasse durchgeführten Aufrufe. Wenn also im Extremfall alle Aufrufe immer hinter-
einander ausgeführt würden, würde ein einziges Objekt reichen.
Ein Stateless Bean muss übrigens nicht tatsächlich zustandslos sein; es kann durchaus
Attribute besitzen, die für unterschiedliche Objekte unterschiedliche Werte haben. Es kann
aber eben passieren, dass ein Wert, den ein Client durch einen Methodenaufruf in einem
solchen Objekt setzt, beim nächsten Aufruf ganz anders ist, weil er beim nächsten Mal mit
einem anderen Objekt arbeitet oder weil er zwar mit demselben Objekt arbeitet, der Wert
aber durch Methodenaufrufe anderer Clients inzwischen verändert wurde.
Um den EJB-Container die geschilderten Optimierungsmöglichkeiten einzuräumen, sollte
man eine Bean-Klasse nach Möglichkeit immer Stateless machen, sofern man die Eigenscha
einer Stateful Bean nicht unbedingt braucht und man damit zurechtkommt, dass sich der Zu-
stand eines Bean-Objekts zwischen zwei Methodenaufrufen desselben Clients ändern kann.
13.4.3 Singleton Session Beans
Diese Bean-Art ist die neueste. Wie der Name ausdrückt, gibt es zu einer Singleton-Bean-
Klasse nur genau ein Objekt. Auch dieser Name ist ein Widerspruch in sich, da mit Session
die Idee verbunden ist, dass es im Laufe der Zeit mehrere Sessions gibt, häufi g auch meh-
rere Sessions gleichzeitig zu einem Zeitpunkt. Der Name „Singleton Bean“ scheint deshalb
eher angebracht. Bei dieser Bean-Sorte wird von dem Prinzip der Stateful und Stateless
Beans abgewichen, nämlich von dem, dass auf einem Objekt keine parallelen Methodenauf-
rufe möglich sind. Auf ein Singleton-Bean-Objekt kann durchaus parallel zugegriff en wer-
den, falls die Anwendungsentwicklerin es erlaubt.
Es gibt zwei Möglichkeiten, um den Grad der Parallelität für ein Singleton Bean festzulegen:
!
Container-Managed Concurrency: Diese erste Möglichkeit ist eine deklarative Form, bei
der die Synchronisation nicht programmiert, sondern durch Annotationen festgelegt
