Stateful Session Beans (@Stateful) są bardzo podobne do ziaren bezstanowych. Różnią się w zasadzie cyklem życia. Kontener dba o to, aby ziarno stanowe nie zgubiło nigdzie stanu, który przechowuje oraz aby każde kolejne wywołanie metody biznesowej danego bean'a nie zostało wywołane przez klienta, który nie jest związany z tym ziarnem. Dlatego odwrotnie do Stateless session beans, ziarna stanowe są powiązane tylko i wyłącznie z jednym klientem.
Cykl życia jest trochę bogatszy od ziaren bezstanowych. Zawiera to co one oraz dwa dodatkowe stany:
- @PrePassivate - wywołane przed dezaktywacją bean'a,
- @PostActivate - wywołane po aktywacji.
W związku z tym zapisywaniem, należy pamiętać o poprawnym wykorzystywaniu tych adnotacji aby kontener zapisywał tymczasowo jak najmniejsze ilości danych. W zasadzie to się tyczy całych ziaren stanowych. Należy z nich korzystać tylko w razie konieczności starając się minimalizować ich obciążenie.
Ziarno kończy swój żywot, gdy już nie jest potrzebne poprzez wywołanie metody oznaczonej @Remove lub time out. Można w niej np. "znullować" (język polski jest super) zmienne stanowe.
5 komentarze:
każde kolejne wywołanie metody biznesowej danego bean'a nie zostało wywołane przez klienta, który nie jest związany z tym ziarnem dotyczy w zasadzie nie klienta, a referencji do ziarna, bo można wyobrazić sobie wielu klientów pracujących z tym samym ziarnem stanowym, byle nie wywoływały tej instancji równolegle.
do tymczasowej (zapisuje na dysku) - zapis może być gdziekolwiek - na dysk, do bazy danych, czy jeszcze innego "repozytorium" stanu (aczkolwiek trudno mi sobie wyobrazić, jakie są jeszcze inne możliwości).
deaktywacja - może prowadzić do nieporozumień, gdyż każde ziarno EJB może zostać zdeaktywowane przez kontener, który przekaże "wyczyszczoną" ze stanu instancję do obsługi kolejnego klienta. Sądzę, że pasywacja zdaje egzamin.
Można w niej np. "znullować" (język polski jest super) zmienne stanowe - nawet bardziej krytyczne zadanie - zamknięcie zasobów bazodanowych, czy połączeń zdalnych, które w przeciwnym przypadku mogłyby "wyciekać".
Dzięki za info. Co do deaktywacji.
Nie wiedziałem, że kontener może wyczyścić od stanu stanowe ziarno. Czy przekazywanie instancji do ponownego użycia nie tyczy się bezstanowych ziaren i poolingu?
Narazie wszystkie informacje mówiły mi - 1 klient 1 instancja stateful session bean. Jeśli nie używany to albo passivation albo destroy.
Stanowe również mogą być w puli. Dlaczego nie?
Tak jest, że 1 klient 1 egzemplarz SFSB, ale klient może się zmieniać w czasie. Kiedyś był "handle" do ziarna EJB, ale teraz nie wiem, jak miałoby być to zrealizowane. Mimo wszystko jest to w końcu referencja, więc jak to w Javie można ją przekazać dalej. Przedstawienie SFSB jako wyłącznie dla pojedynczego klienta to taki skrót myślowy służący do przedstawienia pojedynczego stanu klienta i nie ważny jest pojedynczy klient, ale stan, który przechowuje.
Jacku nie do końca rozumiem Twoją argumentację nt. referencji do ziaren.
Jak wielu klientów może używać jednego ziarna stanowego?
Rozumiem, że masz na myśli jednego klienta, który przechowuje referencję do swojego ziarna stanowego w różnych miejscach.
Co się stanie, jeśli przypadkiem spróbuje równolegle korzystać z różnych operacji oferowanych przez ziarno...
I jeszcze gwoli ścisłości - jeden klient może korzystać z wielu instancji stanowego ziarna, jeśli wielokrotnie poprosi kontener o nową instancję ziarna.
Tomasz Bartczak
Racjonalny Developer
Dlaczego wielu nie może korzystać ze stanowego ziarna skoro to tylko i wyłącznie decyzja kontenera EJB, kto i co dostaje? Nie mogą równolegle, ale szeregowo jak najbardziej. Zresztą pojedynczy klient, sprowadza się do sytuacji, w której mamy wielu klientów każdy wykonujący akcję na ziarnie po poprzedniku (byle szeregowo). Cały stan ziarna przechowywany jest na kontenerze, więc nie ma problemu.
Przypominam, że nie wiem/pamiętam, jak to jest z tym javax.ejb.Handle w EJB3. Ach, to może być tak (nie sprawdzałem jeszcze - piszę z głowy). Na kliencie dostajemy zawsze referencję do ziarna. To nie jest klasa, którą napisaliśmy a pewne opakowanie go. Domyślam się, że realizuje on interfejs EJBObject, w którym jest getHandle(). Resztę doczytamy w EJBObject.getHandle() ;-)
Prześlij komentarz