Transakcje zarządzane przez Bean-a (Bean-Managed Transaction)

Dla niektórych bean-ów typu enterprise, deklaratywne usługi typu CMT (Container Managed Transaction) mogą nie dostarczać wymaganej granulacji. Przykładowo, klient może chcieć wywołać kilka metod na bean-ie sesyjnym bez commit-owania wykonanych przez nie działań po ich zakończeniu. W tym przypadku klient ma do wyboru dwie opcje: może albo utworzyć instancję własnej transakcji JTA (lub resource-local), albo może zwrócić się do bean-a sesyjnego w celu wyeksponowania metod do obsługi transakcji, które klient może sam wywołać by kontrolować zakres transakcji.

W celu obsługi postawionych wyżej wymagań, EJB oferuje bean-om sesyjnym wygodny sposób obsługi ich zdarzeń związanych z zakresem transakcji. By wyłączyć usługi CMT, w bean-ach sesyjnych należy użyć adnotacji @TransactionManagement(TransactionManagementType.BEAN) lub umieścić odpowiadające temu metadane dla bean-a sesyjnego w pliku ejb-jar.xml.
Dla transakcji typu BMT, kontener EJB w dalszym ciągu dostarcza wsparcia transakcyjnego dla bean-a. Główną różnicą jest to, że bean wykonuje konkretne wywołania w celu rozpoczęcia, commit-owania i rollback-owania transakcji w miejsce użycia atrybutów CMT do deklaratywnego przypisania zachowania transakcyjnego swoim metodom. Także, kontener nie propaguje transakcji rozpoczętych przez klienta do bean-ów, które wybrały własną kontrolę zakresu transakcji. Pomimo, że każdy bean enterprise musi mieć określony taki czy inny plan (CMT czy BMT) dla swoich metod, obydwa typy bean-ów mogą współdziałać ze sobą wewnątrz pojedynczego kontekstu transakcji.

Zarządzanie ryzykiem

STRATEGIE

Główne strategie zarządzania ryzykiem to:
1. Transfer ryzyka na innych
2. Zapobieganie ryzyku
3. Redukcja negatywnych skutków ryzyka
4. Akceptacja wybranych lub wszystkich konsekwencji szczególnego ryzyka

Każde prawdopodobne ryzyko powinno mieć sformułowany plan działania z jego możliwymi konsekwencjami.

PROCES

Określenie kontekstu:
w skład tego wchodzi zrozumienie aktualnych uwarunkowań, w których działa organizacja z punktu widzenia wewnętrznego, zewnętrznego oraz w kontekście zarządzania ryzykiem.

Identyfikacja ryzyk:
w skład tego wchodzi udokumentowanie z materialnego punktu widzenia osiągnięć organizacji, jej celów oraz reprezentacji obszarów, które organizacja może wykorzystać do uzyskania konkurencyjnej przewagi.

Analiza/Szacowanie ryzyk:
w skład tego wchodzi skalowanie oraz jeżeli to możliwe utworzenie prawdopodobieństwa dystrybucji przychodów ze względu na każde ryzyko materialne.

Integracja ryzyk:
w skład tego wchodzi agregacja wszystkich dystrybucji ryzyk, odzwierciedlenie korelacji oraz efektów związanych z portfelem, sformułowanie rezultatów w terminach mających wpływ na kluczowe metryki z punktu widzenia wydajności organizacji.

Pobranie/Priorytetyzacja ryzyk:
w skład tego wchodzi określenie wkładu każdego z ryzyk na zagregowany profil ryzyka oraz odpowiednia priorytetyzacja.

Testowanie/Eksploatacja ryzyk:
wypracowanie strategii kontroli i wykorzystania różnych ryzyk.

Monitorowanie i przegląd:
ciągłe pomiary oraz monitorowanie środowiska ryzyka oraz wydajności strategii zarządzania ryzykiem.

Transakcyjny i rozszerzony kontekst persystencji

JPA (Java Persistence Architecture), która jest częścią specyfikacji EJB 3.0, służy uproszczeniu tworzenia aplikacji EJB wykorzystujących persystencję danych. Podstawowym uproszczeniem wprowadzonym przez EJB 3.0 było wprowadzenie interfejsu EntityManager w celu dostępu do elementów bazy danych oraz tworzenia, usuwania lub aktualizacji encji w transakcji. Encje są obiektami, które reprezentują dane w bazie. Są one persystentne w takim sensie, że pozostają nawet po zakończeniu działania aplikacji, która je utworzyła. W celu wsparcia persystencji encji zarządca encji (entity manager) współdziała z kontekstem persystencji (persistence context), który definiowany jest przez Java Persistence Architecture jako:

Zestaw instancji encji zarządzanych (managed), w którym dla jakiegokolwiek identyfikatora encji występuje unikalna instancja encji. Wewnątrz kontekstu persystencji, instancje encji oraz ich cykl życia są zarządzane przez zarządce encji (entity manager).

Java Persistence Architecture określa również, że container-managed persistence context, który jest kontekstem persystencji, którego cykl życia jest zarządzany automatycznie przez kontener, może być zdefiniowany tak by miał albo cykl życia który jest ograniczony to pojedynczej transakcji albo rozszerzony cykl życia który rozpięty jest na wiele transakcji. Zakres cyklu życia zależy od typu określonego w klasie PersistenceContextType w trakcie tworzenia zarządcy encji (entity manager).

W przypadku, gdy container-managed persistence context jest ograniczony do pojedynczej transakcji, kontekst persystencji kończy się wraz z zatwierdzeniem lub wycofywaniem (commit & rollback) skojarzonej transakcji przez Java Transaction API. Dla porównania container-managed persistence context, który ma rozszerzony cykl życia zaczyna się, gdy jest tworzony stanowy bean sesyjny i kończy się wyłącznie, gdy w/w bean jest usuwany z kontenera. Przyjmuje się, że rozszerzony kontekst persystencji (extended persistence context) skojarzony jest ze stanowym beanem sesyjnym. Należy zwrócić uwagę, że jedynie stanowe beany sesyjne mogą posiadać rozszerzonego zarządcę persystencji zarządzanego przez kontener (container-managed, extended entity manager).

Jedną z istotnych różnic pomiędzy kontekstem persystencji ograniczonym do transakcji (transaction-scoped) i rozszerzonym kontekstem persystencji jest stan encji po zakończeniu transakcji. W przypadku transakcyjnego kontekstu persystencji encje zostają odłączone (detached), to jest, nie są dłużej zarządzane, natomiast w przypadku rozszerzonego kontekstu persystencji encje pozostają zarządzane (mamaged). Innymi słowy część operacji związanych z modyfikacją (persist(), merge(), remove()) może być wykonanych poza transakcją i są one kolejkowane i zatwierdzane (komitowane) gdy kontekst persystencji jest kojarzony (attached) z transakcją (i kiedy są zatwierdzane przez commit). Część operacji nie może być wykonana poza transakcją i są to operacje flush(), lock() oraz zapytania typu update/delete.

Wyżej wymienione zagadnienia powodują, że rozszerzony kontekst persystencji jest idealnym rozwiązaniem dla modelowania konwersacji z użytkownikiem, który rozciąga się na wiele interakcji. Podobne zachowanie można osiągnąć używając transakcji zarządzanej przez bean-a (bean-managed transaction), która rozciąga się na całą konwersację użytkownika. W tym przypadku transakcja rozpoczynana jest poprzez użycie metody UserTransaction.begin(). Jednakże to alternatywne podejście jest bardziej skomplikowane niż wykorzystanie rozszerzonego kontekstu persystencji.

Domyślnym typem kontekstu persystencji jest kontekst transakcyjny. W celu wstrzyknięcia EntityManager'a z wyspecyfikowanym rozszerzonym kontekstem persystencji, należy wyspecyfikować dyrektywę wstrzyknięcia w następujący sposób (lub zdefiniować element persistence-context-ref w deskryptorze XML):

@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EnterpriseManager emgr;

SCJP - prawda i mity

W ostatnim czasie wykonałem podejście zakończone sukcesem do egzaminu "Sun Certified Java Programmer" dla wersji Java 6.0. Wiele wcześniej czytałem na różnych blogach na temat samego egzaminu i sposobów na jego zdanie. Z wszystkimi, którzy przymierzają się do podejścia do tego egzaminu chciałbym podzielić się moimi wrażeniami i doświadczeniami.

Wielu pisze na blogach, że do podejścia do egzaminu trzeba się długo przygotowywać conajmniej 1,5 miesiąca. To moim zdaniem jest mit. Ja przygotowywałem się do niego stricte 3 dni i to wystarczyło na 84% :) Zapytacie jak to jest możliwe ? Otóż pomimo tego, że egzamin jest trudny to doświadczenie w pisaniu aplikacji w języku Java jest nieocenione i jest podstawą do podejścia w tak krótkim czasie. Jednak samo doświadczenie niestety nie wystarczy choć, gdy ktoś będzie zadowolony z uzyskania wyniku w okolicach 65% to może się udać. Co warto zrobić oprócz doświadczenia, to zapoznać się z moim zdaniem bardzo dobrą książką "SCJP Sun Certified Programmer for Java 6 Study Guide (CX-310-065): Exam 310-065" oraz wykonać serię testów na symulatorze. Ja korzystałem z symulatora JQ+.

Do podejścia należy zapoznać się dokładnie z zawartością książki o której pisałem wcześniej, następnie wykonać testy zawarte w tej książce, wykonać jak największą ilość testów z JQ+, a na samym końcu w dniu egzaminu lub w przeddzień wykonać final test z symulatora JQ+.

Na co zwrócić szczególną uwagę:
1. wątki i co będzie się pojawiać na ekranie przy działaniu wielu wątków. W tym zwrócić należy uwagę na to co jest pewne w takim zrzucie na konsolę np. poprawna kolejność elementów wyrzuconych na konsolę.
2. garbage collector i co jest a co nie jest dostępne do czyszczenia po serii wykonanych linii kodu
3. Kolekcje a w szczególności Generics i obsługa Enum-ów
4. Sprawdzanie kodu składniowo przed zabraniem się za analizę czyli ręczny debugging :)
5. Zapoznanie się się z API w szczególności metody i klasy umożliwiające dostęp do plików, Regular Expression i API dla klasy Console.

Warto podejść do egzaminu jeżeli ma się doświadczenie w pisaniu kodu Java, a to dlatego, że pozwala to na zapoznanie się z elementami języka o których nawet programując ponad 5 lat można nie wiedzieć a także pozwala na systematyzację wiedzy na temat składni języka.