Dlaczego JSF zapisuje stan komponentów UI na serwerze?

Question

Dlaczego JSF zapisuje stan komponentów UI na serwerze?

Do jakiego momentu JSF zapisuje stan komponentów UI po stronie serwera i kiedy dokładnie informacje o stanie komponentu UI są usuwane z pamięci serwera? Czy jako zalogowany użytkownik w aplikacji będzie poruszał się po stronach, czy stan komponentów będzie się nadal gromadził na serwerze?
Nie rozumiem Jakie są korzyści z utrzymywania stanu komponentów UI na serwerze !? nie przekazuje bezpośrednio zweryfikowanych/przekonwertowanych danych do wystarczająco dużo fasoli? Czy Mogę lub powinienem spróbować tego uniknąć?
Czy to nie zużywa zbyt dużo pamięci Po stronie serwera, jeśli istnieją tysiące jednoczesnych sesji użytkownika? Mam aplikację, w której użytkownicy mogą publikować blogi na określone tematy. Te blogi są dość duże. Kiedy pojawi się post lub Prośba o przeglądanie blogów, czy te dane dużych stron zostaną zapisane jako część stanu komponentów?To pochłonie za dużo pamięci. Czy to nie jest troska ?

Update 1:

Teraz nie jest już konieczne zapisywanie stanu podczas używania JSF. Dostępna jest wysokowydajna, Bezpaństwowa implementacja JSF. Zobacz ten blog & to pytanie do istotnych szczegółów i dyskusji. W JSF specs istnieje również otwarty problem, który pozwala na włączenie do specyfikacji JSF opcji trybu bezstanowego dla JSF. (P. S. rozważ głosowanie nad kwestiami to & this if this is a useful feature dla Ciebie.)

Aktualizacja 2 (24-02-2013):

Świetna wiadomość, że Mojarra 2.1.19 wychodzi z tryb bezstanowy !

Zobacz tutaj:

Http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255

Http://java.net/jira/browse/JAVASERVERFACES-2731

Http://balusc.blogspot.de/2013/02/stateless-jsf.html

97

java jsf java-ee state-saving

Author: Community, 2011-03-29

Source

1 answers

score 191 · Accepted Answer

dlaczego JSF musi zapisywać stan komponentów UI po stronie serwera ?

Ponieważ HTTP jest bezstanowe, a JSF jest stateful. Drzewo komponentów JSF podlega dynamicznym (programowym) zmianom. JSF musi po prostu znać dokładny stan, jaki był, gdy formularz został wyświetlony użytkownikowi końcowemu, aby mógł z powodzeniem przetworzyć cały cykl życia JSF w oparciu o informacje dostarczone przez oryginalne drzewo komponentów JSF, gdy formularz został przesłane z powrotem na serwer. Drzewo komponentów dostarcza informacji o nazwach parametrów żądania, niezbędnych konwerterach/walidatorach, właściwościach Bound managed bean oraz metodach działania.

do jakiego momentu JSF zapisuje stan komponentów UI po stronie serwera i kiedy dokładnie informacje o stanie komponentu UI są usuwane z pamięci serwera?

Te dwa pytania wydają się sprowadzać do tego samego. W każdym razie, to jest implementacja specyficzna, a także zależna od tego, czy stan jest zapisywany na serwerze czy kliencie. Nieco przyzwoita implementacja usunie go po wygaśnięciu lub po zapełnieniu kolejki. Na przykład Mojarra ma domyślny limit 15 widoków logicznych, gdy zapis stanu jest ustawiony na session. Jest to konfigurowalne za pomocą następującego param kontekstowego w web.xml:

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>15</param-value>
</context-param>

Zobacz także Mojarra FAQ dla innych Paramów specyficznych dla Mojarry i tej związanej odpowiedzi com.słońce.twarze.numerofviewsinsession vs com.słońce.twarze.numeroflogicalviews

czy jako zalogowany użytkownik w aplikacji będzie poruszał się po stronach, czy stan komponentów będzie się nadal gromadził na serwerze?

Technicznie, to zależy od implementacji. Jeśli mówisz o nawigacji między stronami (po prostu otrzymuj żądania), Mojarra nie zapisze niczego w sesji. Jeśli są to jednak wnioski POST (formularze z commandlinks/buttons), wtedy Mojarra zapisze stan każdego formularza w sesji do maksymalnego limitu. Umożliwia to użytkownikowi końcowemu otwieranie wielu formularzy w różnych kartach przeglądarki w tej samej sesji.

Lub, gdy zapis stanu jest ustawiony na client, to JSF nie zapisze niczego w sesji. Możesz to zrobić za pomocą następującego param kontekstowego w web.xml:

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

Zostanie następnie serializowana do zaszyfrowanego ciągu w ukrytym polu wejściowym o nazwie javax.faces.ViewState formularza.

nie rozumiem, jakie są korzyści z utrzymania stanu komponentu UI po stronie serwera. Czy bezpośrednie przekazywanie zweryfikowanych / przekonwertowanych danych do managed beans nie jest wystarczające? Czy Mogę / powinienem starać się tego unikać?

To nie wystarczy, aby zapewnić integralność i solidność JSF. JSF to dynamiczny framework z jednym punktem kontrolnym. Bez zarządzania stanem można by w określony sposób fałszować/hakować żądania HTTP (np. manipulować disabled, readonly oraz rendered atrybuty), aby pozwolić JSF robić różne - i potencjalnie niebezpieczne-rzeczy. Byłby nawet podatny na ataki CSRF i phishing.

i czy to nie pochłonie zbyt dużo pamięci po stronie serwera, jeśli istnieją tysiące jednoczesnych sesji użytkownika? Mam aplikację, w której użytkownicy mogą publikować blogi na określone tematy. Te blogi są dość duże. Kiedy pojawi się post lub Prośba o przeglądanie blogów, Duże blogi zostaną zapisane jako część stanu części składowych. To pochłania zbyt dużo pamięci. Czy to nie problem?

Pamięć jest szczególnie tania. Wystarczy dać appserverowi wystarczającą ilość pamięci. Lub jeśli przepustowość sieci jest dla Ciebie tańsza, po prostu przełącz zapisywanie stanu na stronę klienta. Aby znaleźć najlepsze dopasowanie, po prostu stresstest i profil webapp z oczekiwaną maksymalną ilość jednoczesnych użytkowników, a następnie dać appserver 125% ~ 150% maksymalnej zmierzonej pamięci.

Zauważ, że JSF 2.0 znacznie się poprawił w stanie zarządzanie. Możliwe jest zapisanie stanu częściowego (np. tylko <h:form> zostanie zapisany zamiast całości od <html> aż do końca). Na przykład Mojarra tak robi. Przeciętny formularz z 10 polami wejściowymi (każdy z etykietą i Komunikatem) i 2 przyciskami zajmuje nie więcej niż 1KB. Przy 15 odsłonach w sesji, nie powinno to być więcej niż 15KB na sesję. Z ~ 1000 jednoczesnych sesji użytkownika, to nie powinno być więcej niż 15MB.

Twoja troska powinna być bardziej skoncentrowana na rzeczywiste obiekty (managed beans i / lub nawet encje DB) w zakresie sesji lub aplikacji. Widziałem wiele kodów i projektów, które niepotrzebnie duplikują całą tabelę bazy danych do pamięci Javy w ramach sesji, gdzie zamiast SQL używa się Javy do filtrowania/grupowania / porządkowania rekordów. Z ~1000 rekordów, które z łatwością przekroczyłyby 10MB na sesję użytkownika.