Stanowy bean sesji jest definiowany w następujący sposób:
Stanowe fasole sesji Stan obiektu składa się z wartości jego zmiennych instancji. W komponencie bean stanowym sesji zmienne instancji reprezentują stan unikalnej sesji komponentu bean klienta. Ponieważ klient oddziałuje („rozmawia”) ze swoim ziarnem, ten stan jest często nazywany stanem konwersacji.
Bezstanowy komponent bean sesji jest definiowany w następujący sposób:
Bezstanowe komponenty bean sesji Bezstanowe komponenty bean sesji nie utrzymują stanu konwersacji z klientem. Gdy klient wywołuje metody bezstanowego komponentu bean, zmienne instancji komponentu bean mogą zawierać stan specyficzny dla tego klienta, ale tylko na czas trwania wywołania. Po zakończeniu metody nie należy zachowywać stanu specyficznego dla klienta. Klienci mogą jednak zmieniać stan zmiennych instancji w puli bezstanowych komponentów bean i ten stan jest przenoszony do następnego wywołania puli bezstanowych komponentów bean. Z wyjątkiem wywołań metody wszystkie wystąpienia bezstanowego komponentu bean są równoważne, co umożliwia kontenerowi EJB przypisanie instancji do dowolnego klienta. Oznacza to, że stan bezstanowego komponentu bean sesji powinien dotyczyć wszystkich klientów.
Zalety używania bezstanowego komponentu bean sesji w porównaniu ze stanowym komponentem bean sesji są następujące:
Ponieważ bezstanowe komponenty bean sesji mogą obsługiwać wielu klientów, mogą oferować lepszą skalowalność dla aplikacji wymagających dużej liczby klientów. Zwykle aplikacja wymaga mniejszej liczby bezstanowych komponentów bean sesji niż stanowych komponentów bean sesji do obsługi tej samej liczby klientów.
Nasuwa się więc pytanie, kiedy należy używać stanowych beanów sesyjnych? Zgodnie z moim naiwnym rozumieniem tej sprawy, należy trzymać się bezpaństwowej fasoli sesyjnej, jak tylko może.
Jacy byliby kandydaci, w których należałoby używać fasoli stanowej sesji? Jakieś dobre przykłady?
Odpowiedzi:
Po pierwsze, musisz zrozumieć, w jaki sposób tworzone i obsługiwane są ziarna bean na serwerze.
W przypadku bezstanowych sesyjnych bean serwer może utrzymywać zmienną liczbę instancji w puli. Za każdym razem, gdy klient żąda takiego bezstanowego komponentu bean (np. Za pomocą metody), wybierana jest losowa instancja obsługująca to żądanie. Oznacza to, że jeśli klient wykona dwa kolejne żądania, możliwe jest, że dwa różne wystąpienia bezstanowego komponentu bean będą obsługiwać żądania. W rzeczywistości nie ma stanu konwersacji między dwoma żądaniami. Jeśli klient zniknie, bezstanowy komponent bean nie zostanie zniszczony i może obsłużyć następne żądanie innego klienta.
Z drugiej strony stanowy komponent bean sesji jest ściśle powiązany z klientem. Każda instancja jest tworzona i powiązana z jednym klientem i obsługuje tylko żądania od tego konkretnego klienta. Zdarza się więc, że jeśli wykonasz dwa kolejne żądania na fasoli stanowej, Twoje żądanie będzie obsługiwane zawsze z tej samej instancji fasoli. Oznacza to, że możesz utrzymywać stan konwersacji między żądaniami. Pod koniec cyklu życia klient wywołuje metodę usuwania i komponent bean jest niszczony / gotowy do czyszczenia pamięci.
Zależy to głównie od tego, czy chcesz utrzymać stan konwersacji . Na przykład, jeśli masz metodę, która dodaje dwie liczby i zwraca wynik, używasz bezstanowego komponentu bean, ponieważ jest to operacja jednorazowa. Jeśli wywołasz tę metodę po raz drugi z innymi liczbami, nie będziesz już zainteresowany wynikiem poprzedniego dodania.
Ale jeśli chcesz na przykład policzyć liczbę żądań wykonanych przez klienta, musisz użyć fasoli stanowej. W tym scenariuszu ważne jest, aby wiedzieć, jak często klient żądał wcześniej metody bean, więc musisz utrzymać stan konwersacji w fasoli (np. Ze zmienną). Jeśli użyjesz tutaj bezpaństwowej fasoli, żądanie klienta będzie obsługiwane za każdym razem z innej fasoli, co zepsuje wyniki.
źródło
@Remove(javax.ejb) nie zostanie wywołana jawnie (ta metoda nie musi nawet być kodowana. Można ją po prostu pozostawić pustą / pustą, biorąc pod uwagę, że jest oznaczona przez@Remove). Jeśli powiązany klient zapomniał zniszczyć stanowego komponentu bean sesji, ten komponent bean będzie wisiał na serwerze, dopóki sam kontener nie zdecyduje się go usunąć przy użyciu własnej polityki. Czy się mylę?Myślę, że najlepszym przykładem użycia fasoli sesyjnej Stateful jest koszyk , w którym przechowujesz wszystkie produkty, które użytkownik chce kupić.
źródło