Session bean

A HupWiki-ből...

Az Enterprise Bean-ek háromfélék lehetnek:

• session bean
• entity bean
• message-driven bean

Egy Session Bean arról kapta a nevét, hogy olyan, mint egy párbeszédes elérés: nem megosztható (egy Session Bean egyszerre egyetlen egy klienshez tartozhat csak).

Két fajtája van: - stateless session bean: ez nem perzisztens (állapota ugyan lehet, de miután a hívott metódus végrehajtódott rajta, az állapot többet nem determinisztikus, és nem is releváns).

- stateful session bean: ez perzisztens állapottal rendelkezik, de az állapotának perzisztálása nem mindig garantált, hogy túlél egy szerver leállást, valamint létezik (stateful) session bean timeout is, ami azt mondja meg, legalább meddig él egy (stateful) session bean példány (az utolsó rajta végzett művelet után). Ezen idő után nem garantált, hogy a session bean még elérhető.

Egy session bean példány megszüntethető, ha meghívjuk a Remote vagy Local interfészén a remove() metódust (és még a Home interfésze(i)n keresztül is).

Amíg viszont ez nem történt meg, addig megpróbálhatunk hozzáférni akkor is, ha a Remote interfészre a referenciát már eldobtuk. Mindössze annyi kell ehhez, hogy rendelkezzünk a session bean Handle-jével (a Remote interfésztől kaphatjuk meg), amely implementálja a Serializable interfészt, így bárhova bárkinek átadhatjuk, vagy akár az adatbázisba is beírhatjuk. Ezen a Handle-n keresztül, annak getEJBObject() metódusával újra elkérhetjük a session bean példány Remote interfészét. Persze amennyiben a Session bean példány közben törlésre került, vagy más hiba miatt, előfordul hogy nem tudunk majd ténylegesen hozzáférni a Session bean-hez.

Ezáltal lehetővé válik, hogy több kliens is hozzáférhessen ugyanazon Session bean példányhoz. Értelemszerűen ennek csak Stateful Session bean-nél van értelme, mivel Stateless Session bean-ek állapotáról nem feltételezhetünk semmit a művelet végrehajtása után.

Viszont mivel a bean futásához fontos az, hogy ketten ne futtassanak rajta egyszerre műveletet, ezért az EJB konténer gondoskodik róla, hogy egy Session bean példányon egyszerre egy szál futhat. Ha egy Session bean példányon épp fut egy szál, akkor egy másik szálon érkező kérés meg fogja várni míg az épp aktuális művelet véget ér.

Ez sok dolgot lehetővé tesz számunkra. Pl. egy több klienses alkalmazáson egy olyan központi objektumot tudunk létrehozni vele, amibe az összes kliens elhelyezheti a fontos kliens-függő adatait, méghozzá az elemi műveleteket kritikus szakasznént kezelve (egyszerre garantáltan maximum egy művelet fut). Persze ezzel csínján kell bánni, mivel a session bean állapotát perzisztálni kell ezek után, ami időbe és erőforrásba kerül.

A Session Bean-ek tekinthetők egy alkalmazás tulajdonképpeni kliens-részének, hiszen a felhasználónál csak egy terminál-szerű működést produkáló programrészlet található, ami igazából a Session Bean-eket működteti.

- Ezt az utolsó bekezdést szerintem gondold át, mert a Session bean-eket tipikusan szerver oldali komponensnek tekinti a szakma, ahova az ember üzleti logikát pakol. Lásd az entity-bean-ekhez írt megjegyzésemet. --Finrod

Használható,

• ha egy Bean-hez egyidőben csak egy kliens fér hozzá
• ha egy Bean állapota (ha egyáltalán értelmezhető ilyen) nem fontos, hogy server újraindítást túlélő és hibatűrő legyen.