Home > java, SCBCD > SCBCD: Matering EJB 3.0 rodziały 1-4

SCBCD: Matering EJB 3.0 rodziały 1-4

Styczeń 8th, 2009

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.

java, SCBCD

  1. No comments yet.
  1. No trackbacks yet.