Transakcje zarządzane przez kontener (Container-Managed Transaction)

EJB3 dostarcza wbudowane usługi do zarządzania transakcjami, które są domyślnie dostępne w bean-ach sesyjnych oraz bean-ach typu MDB (Message Driven Bean). Kontener wytycza granice transakcji oraz automatycznie rozpoczyna i zatwierdza (commit) transakcje w oparciu o deklaratywne metadane dostarczone przez twórcę bean-a.

W przypadku, gdy jakiś EJB deklaruje w metadanych swoje zachowanie jako transakcyjne, kontener ingeruje w wywołania metod bean-a i wprowadza zachowanie transakcyjne w obrębie metod bean-a sesyjnego. Może zostać wyspecyfikowany dla każdej metody jeden stały zestaw opcji. Domyślnym zachowaniem dostarczanym przez kontener jest weryfikacja, bezpośrednio przed wywołaniem metody, czy kontekst transakcyjny jest skojarzony z bieżącym wątkiem. Jeżeli wyżej wymieniony kontekst nie jest dostępny, kontener rozpoczyna nową transakcję bezpośrednio przed wywołaniem metody. Jeżeli natomiast, kontekst transakcyjny jest dostępny, kontener propaguje bieżącą transakcję w wywołaniu metody a także dopuszcza jej dostępność w kodzie metody. Następnie, po powrocie z wywołania metody, kontener wykonuje następną weryfikację. W wyniku ponownej weryfikacji, jeżeli kontener był odpowiedzialny za utworzenie nowego kontekstu transakcyjnego, automatycznie zatwierdza transakcję po wyjściu z metody (lub gdy wyrzucony został wyjątek przez metodę, odwraca (rollbak) transakcję którą rozpoczął). W przypadku, gdy kontener nie był twórcą transakcji, pozwala na kontynuowanie transakcji bez jej naruszania. Poprzez ingerencję w wywołania metod bean-a, kontener EJB ma możliwość wprowadzenia zachowania transakcyjnego w runtime-mie, na bazie tego co zostało wyspecyfikowane deklaratywnie w trakcie tworzenia (developmentu).

Domyślne zachowanie opisane wyżej jest określane poprzez specyfikację atrybutu transakcji na REQUIRED. Developer ma możliwość określenia atrybutu transakcji oprócz wyżej wymienionego, na sześć różnych sposobów:

• MANDATORY – transakcja jest konieczna; błąd, gdy nie ma bieżącej transakcji podczas wywołania metody


• REQUIRED – transakcja jest wymagana; gdy nie ma bieżącej transakcji tworzona jest automatycznie nowa


• REQUIRES_NEW – wymagana nowa transakcja; nawet gdy podczas wywołania jest bieżąca transakcja jest ona usypiana i tworzona jest zupełnie nowa na rzecz wywołania metody


• SUPPORTS – transakcja może być ale nie musi


• NOT_SUPPORTED – transakcja nie jest wspierana; gdy istnieje bieżąca transakcja jest usypiana, a wywołanie odbywa się bez kontekstu transakcyjnego


• NEVER – transakcja jest niedopuszczalna; gdy istnieje bieżąca transakcja zostaje zwrócony błąd

Wszystkie sześć atrybutów jest typowo dostępne dla metod bean-a sesyjnego, tym niemniej pewne atrybuty nie są dostępne w metodzie będącej timeout callback-iem, lub gdy bean sesyjny implementuje interfejs javax.ejb.SessionSynchronization. W bean-ach typu MDB dostępne są jedynie atrybuty REQUIRED oraz NOT_SUPPORTED.