Java Reference
In-Depth Information
rufe vom EJB-Container verzögert und erst dann ausgeführt werden, wenn andere Auf-
rufe zu Ende gelaufen sind. Im Prinzip werden die Aufrufe aber parallel bearbeitet, und
zwar unabhängig davon, ob alle Threads denselben Stub oder jeder Thread seinen eige-
nen Stub nutzt.
! Singleton Bean: Wenn man keine zusätzlichen Annotationen angibt, dann werden alle
Aufrufe hintereinander ausgeführt; es gibt überhaupt keine Parallelität. Auch hier ist für
die beiden Fä lle „gemeinsamer Stub“ und „eigene Stubs“ kein Unterschied festzustellen,
denn auch wenn jeder Thread seinen eigenen Stub besitzt, wird der Aufruf doch an das
einzige Bean-Objekt, das es gibt, weitergeleitet. Die Aufrufe werden zwangsweise sequen-
zialisiert, weil Container-Managed Concurrency eingestellt ist und beim Aufruf der
Methode sleep eine Schreibsperre gesetzt wird. Wenn man die Methode sleep stattdessen
explizit mit @Lock(LockType.READ) annotiert, kann man sehen, dass dann die Aufrufe
parallel ausgeführt werden.
! Stateful Bean: Bei der Benutzung des Stateful Beans ergibt sich zum ersten und einzigen
Mal ein Unterschied zwischen der Benutzung eines einzigen Stubs und mehrerer Stubs,
denn bei Stateful Beans wird bekanntlich für jedes Lookup ein eigenes Objekt erzeugt. Im
Falle eines einzigen Lookups benutzen folglich alle Threads dasselbe Objekt. Da es keine
Parallelität bei Stateful-Bean-Objekten gibt, werden folglich alle Aufrufe hintereinander
ausgeführt. Wenn aber jeder Thread sein Lookup selbst durchführt, generiert der EJB-
Container für jeden Thread ein neues Objekt der Stateful-Bean-Klasse. Somit können the-
oretisch alle Aufrufe parallel laufen. Dies ist auch bei der Verwendung eines Glassfi sh-
Servers zu beobachten. Überraschenderweise werden bei JBoss 6 aber auch in diesem
Fall die Aufrufe hintereinander abgearbeitet, was nicht notwendig wäre, denn auch der
JBoss6-Server erzeugt korrekterweise unterschiedliche Objekte.
Die geschilderten Sacherhalte sind in Tabelle 13.1 in übersichtlicher Form noch einmal
zusammengefasst.
Tabelle 13.1 Sequenzielle und parallele Ausführung für unterschiedliche Bean-Arten und bei der Nutzung
eines gemeinsamen Stubs bzw. unterschiedlicher Stubs
gemeinsamer Stub
unterschiedliche Stubs
Stateless Bean
parallel
parallel
Singleton Bean
sequenziell bei Nutzung einer
Schreibsperre,
parallel bei Nutzung einer Lese-
sperre
sequenziell bei Nutzung einer
Schreibsperre,
parallel bei Nutzung einer Lese-
sperre
Stateful Bean
sequenziell
im Prinzip parallel (bei JBoss6
jedoch sequenziell)
 
Search WWH ::




Custom Search