SCBCD: Matering EJB 3.0 rodziały 1-4
Rozpocząłem lekturę książki z tytułu posta. Doszedłem właśnie do końca 4 rozdziału. Jakie wrażenia?
Rodział 1-3 znajdują w części pierwszej książki zatytułowanej "Overview". Faktycznie, jest to nawet bardzo "overview". Pierwszy rozdział próbuje przedstawić nam, dlaczego w ogóle EJB powstało i co to jest. Rodział drugi opowiada jak to było przed 3.0, a trzeci opowiada jak to fajnie jest w 3.0.
Jeśli ktoś miał już doczynienia z EJB i ogólnie rozumie o co w tym chodzi i jaka jest idea, sugeruje te rozdziały przeskoczyć (pamiętajcie jednak, że pierwszy cel SCBCD to właśnie "Overview" i taka wiedza jest potrzeba, więc te rodziały przeskoczcie jeżeli na prawdę wiecie skąd się EJB wzięło, po jest i co nam daje).
W rodziale 4 zaczynają się konkrety - Session Beans. Omówione są różnice pomiędzy Stateless i Stateful, cykl życia oraz metody zwrotne. Rozdział dość łagodnie wprowadza w te tematy, wydaje mi się, że tłumaczenia są jasne i klarowne.
Co z tego rodziału należy zapamiętać.
(to tylko notatki, nie kompletne źródło
)
Mamy dwa rodzaje Session Beans:
- Stateless Session Bean jest bezstanowy, tj. nie gwarantuje nam zachowania stanu pomiędzy poszczególnymi wywołaniami metod biznesowych. Wszystkie instancje są w związku z tym równe i dowolna instancja może obsługiwać dowolnego klienta. Instancja może jak najbardziej w obrębie wywołania metody biznesowej przechowywać wartości w polach instancji. Warto też pamiętać, że ze względów optymalizacyjnych kontener może posiadać pulę instancji o określonym rozmiaże i zamiast za każdym razem tworzyć nową instancję, może operować na takiej puli. Efekt uboczny może być taki, że jeśli coś zostanie zachowane w instancji, to może zostać odczytane przy wywołaniu innej metody biznesowej (być może przez innego klienta). Nie narusza to specyfikacji, ale należy pamiętać, że nie jest to gwarantowane i zdecydowanie nie należy na tym polegać. Kontener decyduje kiedy utworzyć/zniszczyć daną instancję.
- Statefull Session Bean zachowuje stan pomiędzy poszczególnymi wywołaniami metod biznesowych klienta. Kontener przy tym gwarantuje, że dany klient zawsze otrzyma instancję o takim samym stanie (nie musi to być dokładnie taka sama instancja, może być nowa, ale przywrócona do takiego samego stanu). Kontener stosuje mechanizm pasywacji/aktywacji do przywrócenia stanu instancji, jeśli z jakiś powodów musiał taką instancję z pamięci usunąć.
Metody cyklu życia:
- @PostConstruct wywołana po utworzeniu instancji, po wykonaniu wstrzyknięcia zależności, przed wywołaniem metody biznesowej.
- @PreDestroy wywołana tuż przed usunięciem instancji. Uwaga: nie należy polegać na wywołaniu tej metody. Może one nie zostać wywołana.
- @PrePassivate wywołana jest przed zapisaniem stanu instancji Statefull Session Bean'a.
- @PostActivate wywołana jest po odtworzeniu stanu instancji Statefull Session Bean'a.
- metody te mogą być deklarowane bezpośrednio w klasie bean'a lub w oddzielnej klasie
- nie mogą rzucać wyjątków aplikacyjnych, ale mogą rzucać wyjątki Runtime. Jeśli stanie się to wewnątrz transakcji, zostanie ona wycofana.