EJB kontajner spravuje životný cyklus entitných objektov prostredníctvom množiny callback metód vykonávaných nad príslušnými inštanciami. Tieto metódy sú jednak z tých definovaných v rozhraní EntityBean, jednak sú to metódy potrebné na zabezpečenie funkcionality definovanej v home rozhraní. Vy ste zodpovední za implementáciu týchto metód, takže je pre vás dôležité vedieť, kedy sú tieto metód volané a čo môžeme od nich očakávať.

V tomto článku sa zameriame prevažne na to, kedy sú tieto metódy volané EJB kontajnerom. Čo konkrétne sa v týchto metódach vykonáva, je závislé od toho či použijete BMP alebo CMP. Vo všeobecnosti sú callback metódy volané v závislosti od toho, v akom stave životného cyklu sa entity bean nachádza. Špecifikácia EJB definuje tri možné stavy – stav neexistencie, stav umiestnenia v zásobníku a stav pripravenosti. Prechod medzi týmito polohami je vo väčšine prípadov sprevádzaný volaním jednej, respektíve viacerých callback metód.

Existencia inštancie entity bean začína v okamihu, kedy kontajner vytvorí inštanciu implementačnej triedy použitím volania metódy Class.newInstance. Následne kontajner zavolá metódu setEntityContext, ktorou priradí runtime kontext k novo vytvorenej inštancii. V tomto okamihu je dôležité si uvedomiť, že zatiaľ nie je novo vytvorená inštancia žiadnym spôsobom prepojená s konkrétnym objektom entity bean. Inými slovami zatiaľ nemá priradenú ani identitu ani stav. Jej atribúty majú iba prednastavené hodnoty, pretože zatiaľ neboli z databázy vytiahnuté žiadne dáta a priradené inštancii.

Inštancia je iba prevedená do stavu umiestnenia v zásobníku, kde môže byť v prípade potreby asociovaná s konkrétnou entitou. Kontajner umiestni do zásobníka určité množstvo inštancií súčasne, aby boli k dispozícii pri požiadavkách od klientov, ktoré nie sú závislé od konkrétneho stavu entitného objektu. Jednotlivé inštancie umiestnené v zásobníku sú navzájom úplne identické a ktorákoľvek z nich môže byť použitá kontajnerom.

Všetky nové inštancie enterprise beanov sú vytvárané prostredníctvom metódy Class.newInstance, ktorá vyžaduje pre každú triedu EJB bezparametrický konštruktor. Keďže vy sami nikdy nebudete priamo využívať konštruktor triedy EJB, najjednoduchšou cestou, ako splniť uvedenú požiadavku, je nikdy nedeklarovať vlastný konštruktor pre triedu beanu. Týmto spôsobom zabezpečíte, že kontajner vždy bude mať k dispozícii defaultný konštruktor.

Inštancia entity bean je presunutá do stavu pripravenosti vtedy, keď je jej priradená identita konkrétneho entitného objektu. To sa udeje vtedy, keď je buď vytvorená nová entita, alebo je aktivovaná existujúca. Kontajner vytvorí entitu ako odpoveď na klientovo volanie create metódy. Vy však neimplementujete vlastnú create metódu v triede beanu, ale implementujete korešpondujúcu ejbCreate alebo ejbPostCreate metódu. Ako príklad bude metóda createWithData definovaná v EnglishAuctionHome rozhraní mať korešpondujúcu deklaráciu ejbCreateWithData:

public Integer ejbCreateWithData(String name, String description) throws CreateException {
 /**
 * urobí potrebnú prácu a v prípade BMP vráti primárny kľúč
 * alebo v prípade CMP vráti null
 **/

}

Potom, čo kontajner vytvorí entitný objekt, vyberie inštanciu zo zásobníka a zavolá jej ejbCreate metódu. Táto metóda musí mať rovnaké vstupné parametre ako create metóda definovaná v home rozhraní entitnej triedy a musí deklarovať výnimku CreateException. Namiesto vrátenia referencie na rozhranie beanu musí metóda ejbCreate vrátiť primárny kľúč. Po ukončení tejto metódy vlastní inštancia primárny kľúč, ktorý v podstate určuje jej identitu. Následne je volaná metóda ejbPostCreate, ktorá môže byť deklarovaná nasledovne:

public void ejbPostCreateWithData(String name, String description) {
 /**
 * vykoná inicializáciu potrebnú po vytvorení
 **/

}

Po ukončení tejto metódy je inštancia entity bean presunutá do stavu pripravenosti a kontajner vráti klientovi referenciu na local alebo remote rozhranie entitnej triedy, podľa typu klienta.

Inštancia entity bean môže byť tiež presunutá do stavu pripravenosti v prípade zavolania jej metódy ejbActivate. Často ako výsledok manažovania dostupných zdrojov EJB kontajnerom (object pooling). Entitné objekty referencované klientom môžu byť pasivované a umiestnené späť do zásobníka v prípade, že zdroje, držané týmito objektmi, sú potrebné niekde inde. V takomto stave potom entitný objekt síce má pridelenú identitu, ale nie je aktuálne priradený ku konkrétnej inštancii.

Pre každú vyhľadávaciu metódu (finder method), ktorú deklarujete, musíte buď vy (BMP) alebo EJB kontajner (CMP) zabezpečiť odpovedajúcu ejbFind metódu. Napríklad:

public Collection ejbFindAllAuctions() throws FinderException {
 /**
 * metóda vráti kolekciu všetkých existujúcich aukcií
 **/

}

Metóda ejbFind musí akceptovať presne tie isté vstupné parametre ako korešpondujúca finder metóda a musí deklarovať výnimku FinderException. Metóda musí vracať hodnoty jednotlivých primárnych kľúčov hľadaných objektov, namiesto vrátenia referencií na tieto objekty.

Identita týchto objektov je síce známa, ale zatiaľ nemôžu byť nad nimi vykonané žiadne operácie, ktoré vyžadujú poznanie ich stavu uložené ho v databáze. Vo výsledku to znamená, že vyhľadané entitné objekty sú pasivované. Rovnako to platí aj pri volaní select metód pri použití CMP. O tejto technike si budeme hovoriť v neskorších článkoch.

Bez ohľadu na to, akým spôsobom bol entitný objekt pasivovaný, jeho aktivácia sa uskutoční až vtedy, keď mu kontajner priradí inštanciu EB a následne zavolá metódu ejbActivate danej inštancie. Inštancia EB už síce teraz má priradenú identitu objektu, ale to nutne nemusí znamenať, že sú známe aj hodnoty vlastností objektu. Ak je v tomto bode vykonaná nad objektom nejaká biznis metóda, potom musí nutne prísť k načítaniu hodnôt týchto vlastností z podkladovej databázy. V prípade BMP kontajner zavolá metódu ejbLoad, za implementáciu ktorej ste zodpovední vy a ktorej úlohou je získať spomínané hodnoty vlastností. Pri použití CMP najprv kontajner sám získa hodnoty vlastností objektu, až potom zavolá metódu ejbLoad, ktorá má za úlohu v tomto prípade vykonať čokoľvek, čo je potrebné po vykonaní synchronizácie.

Kým je entitný objekt v stave pripravenosti, všetky zmeny jeho vlastností sú prenášané do podkladovej databázy volaním metódy ejbStore alebo samotným kontajnerom. Obsluha volania biznis metód (realizovaných klientmi), sa vždy vykonáva až v stave pripravenosti (po aktivácii a synchronizácii) entitného objektu.

Inštancia EB je vrátená do zásobníka vtedy, keď je odstránená, alebo tiež pasivovaná. Ak sa kontajner rozhodne danú inštanciu pasivovať, najprv zavolá jej metódu ejbStore, ktorej úlohou je korektne synchronizovať stav objektu s databázou, a potom zavolá metódu ejbPassivate. Úlohou tejto metódy je poskytnúť vám priestor na vykonanie nutných operácií predtým, ako bude inštancia vrátená do zásobníka. Môže ísť napríklad o uvoľnenie určitých zdrojov držaných touto inštanciou.

Keď klient zavolá metódu remove, buď home alebo component rozhrania, kontajner zavolá metódu ejbRemove konkrétnej inštancie EB. Pri použití BMP je nutné implementovať do tejto metódy mechanizmus, ktorý vymaže objekt (respektíve jeho vlastnosti) z podkladovej databázy a uvoľní všetky obsadené zdroje. Pri CMP zavolá kontajner tiež spomínanú metódu, ale iba za účelom uvoľnenia asociovaných zdrojov. Po vykonaní metódy ejbRemove umiestni kontajner predmetnú inštanciu do zásobníka, pričom neskôr môže byť znova aktivovaná.

EJB kontajner môže umožniť, aby inštancia EB bola definitívne odstránená použitím garbage collectora. Ešte predtým však bude zavolaná metóda unsetEntityContext a inštancia EB bude odstránená zo zásobníka.

Nasledujúci obrázok sumarizuje výskyt jednotlivých callback metód a prechody medzi jednotlivými etapami tvoriacimi životný cyklus EB. Inštancia EB môže byť popísaná niektorým z troch rôznych stavov počas jej životného cyklu:

Životný cyklus inštancie entity bean
Životný cyklus inštancie entity bean

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.

Žádný příspěvek v diskuzi

Odpovědět