wake-up-neo.com

Warum speichert JSF den Status von UI-Komponenten auf dem Server?

  1. Bis zu welchem ​​Zeitpunkt speichert JSF den Status der UI-Komponenten auf der Serverseite und wann genau werden die Statusinformationen der UI-Komponente aus dem Serverspeicher entfernt ? Wenn ein angemeldeter Benutzer in der Anwendung durch die Seiten navigiert, sammelt sich der Status der Komponenten weiterhin auf dem Server an?

  2. Ich verstehe nicht , welchen Vorteil es hat, den Status von UI-Komponenten auf dem Server zu halten! Die validierten/konvertierten Daten werden nicht direkt genug an verwaltete Beans übergeben ? Kann oder sollte ich versuchen, es zu vermeiden?

  3. Verbraucht das nicht zu viel Speicher auf der Serverseite, wenn es Tausende von gleichzeitigen Benutzersitzungen gibt? Ich habe eine Anwendung, mit der Benutzer Blogs zu bestimmten Themen veröffentlichen können. Diese Blogs sind ziemlich groß. Wenn es einen Beitrag zurück oder eine Aufforderung zum Anzeigen der Blogs gibt, werden diese großen Seitendaten als Teil des Zustands der Komponenten gespeichert? Dies würde fressen zu viel Speicher. Ist das nicht ein Problem?


Update 1:

Jetzt ist es nicht mehr erforderlich, den Status bei Verwendung von JSF zu speichern. Es steht eine leistungsstarke zustandslose JSF-Implementierung zur Verfügung. Siehe hierzu Blog & diese Frage für relevante Details und Diskussionen. Außerdem gibt es ein offenes Problem , das in JSF-Spezifikationen aufgenommen werden kann, eine Option zum Bereitstellen des zustandslosen Modus für JSF. (S. Überlegen Sie, für die Themen abzustimmen this & this , wenn dies eine nützliche Funktion für Sie ist.)


Update 2 (24-02-2013):

Eine großartige Nachricht, dass Mojarra 2.1.19 mit zustandslosem Modus aus ist!

Siehe hier:

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

103
Rajat Gupta

Warum muss JSF den Status von UI-Komponenten auf der Serverseite speichern?

Weil HTTP statusfrei und JSF statusbehaftet ist. Der JSF-Komponentenbaum unterliegt dynamischen (programmatischen) Änderungen. JSF muss lediglich den genauen Status kennen, in dem das Formular dem Endbenutzer angezeigt wurde, damit der gesamte JSF-Lebenszyklus erfolgreich verarbeitet werden kann, basierend auf den Informationen, die der ursprüngliche JSF-Komponentenbaum beim Zurücksenden des Formulars bereitgestellt hat der Server. Der Komponentenbaum enthält Informationen zu den Namen der Anforderungsparameter, den erforderlichen Konvertern/Validatoren, den Eigenschaften der gebundenen verwalteten Beans und den Aktionsmethoden.


Bis zu welchem ​​Zeitpunkt speichert JSF den Status von UI-Komponenten auf der Serverseite und wann genau werden die Statusinformationen der UI-Komponente aus dem Serverspeicher entfernt?

Diese beiden Fragen scheinen sich auf dasselbe zu beschränken. Dies ist jedoch implementierungsspezifisch und hängt auch davon ab, ob der Status auf dem Server oder dem Client gespeichert ist. Eine etwas anständige Implementierung wird es entfernen, wenn es abgelaufen ist oder wenn die Warteschlange voll ist. Mojarra hat zum Beispiel ein Standardlimit von 15 logischen Ansichten, wenn die Statusspeicherung auf Sitzung gesetzt ist. Dies kann mit dem folgenden Kontextparameter in web.xml Konfiguriert werden:

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

Siehe auch Mojarra FAQ für andere Mojarra-spezifische Parameter und diese zugehörige Antwort com.Sun.faces.numberOfViewsInSession vs com.Sun.faces.numberOfLogicalViews


Wenn ein angemeldeter Benutzer in der Anwendung durch die Seiten navigiert, sammelt sich der Status der Komponenten weiterhin auf dem Server an?

Technisch hängt das von der Implementierung ab. Wenn Sie von einer Seiten-zu-Seiten-Navigation sprechen (nur GET-Anfragen), speichert Mojarra in der Sitzung nichts. Handelt es sich jedoch um POST) - Anfragen (Formulare mit Befehlslinks/Schaltflächen), speichert Mojarra den Status der einzelnen Formulare in der Sitzung bis zum Höchstwert. Auf diese Weise kann der Endbenutzer mehrere Formulare in verschiedenen Browser-Registerkarten öffnen in der gleichen Sitzung.

Wenn die Statusspeicherung auf Client festgelegt ist, speichert JSF in der Sitzung keine Daten. Sie können dies mit dem folgenden Kontextparameter in web.xml Tun:

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

Es wird dann zu einer verschlüsselten Zeichenkette in einem versteckten Eingabefeld mit dem Namen javax.faces.ViewState Des Formulars serialisiert.


Ich verstehe nicht, welchen Vorteil es hat, den Status der UI-Komponente auf der Serverseite beizubehalten. Reicht es nicht aus, die validierten/konvertierten Daten direkt an verwaltete Beans zu übergeben? Kann/sollte ich versuchen, es zu vermeiden?

Dies reicht nicht aus, um die Integrität und Robustheit von JSF zu gewährleisten. JSF ist ein dynamisches Framework mit einem einzigen Kontrollpunkt. Ohne eine Zustandsverwaltung wäre man in der Lage, HTTP-Anfragen auf eine bestimmte Weise zu fälschen/zu hacken (z. B. die Attribute disabled, readonly und rendered zu manipulieren), um JSF anders machen zu lassen - und potenziell gefährliche Dinge. Es wäre sogar anfällig für CSRF-Angriffe und Phishing.


Und wird das nicht zu viel Speicher auf der Serverseite verbrauchen, wenn es Tausende von gleichzeitigen Benutzersitzungen gibt? Ich habe eine Anwendung, mit der Benutzer Blogs zu bestimmten Themen veröffentlichen können. Diese Blogs sind ziemlich groß. Wenn ein Beitrag zurückgeschickt oder das Anzeigen der Blogs angefordert wird, werden die großen Blogs als Teil des Status der Komponenten gespeichert. Dies würde zu viel Speicher verbrauchen. Ist das nicht ein Problem?

Speicher ist besonders günstig. Geben Sie dem Anwendungsserver einfach genügend Speicherplatz. Oder wenn die Netzwerkbandbreite für Sie günstiger ist, wechseln Sie einfach zur Clientseite, um den Status zu speichern. Um die beste Übereinstimmung zu finden, testen und profilieren Sie Ihre Webanwendung einfach mit der erwarteten maximalen Anzahl gleichzeitiger Benutzer und geben Sie dem Anwendungsserver 125% ~ 150% des maximal gemessenen Speichers.

Beachten Sie, dass JSF 2.0 die Statusverwaltung erheblich verbessert hat. Es ist möglich, einen Teilstatus zu speichern (zB , nur , der <h:form> Wird anstelle des gesamten Materials aus <html> Gespeichert der Weg zum Ende). Mojarra zum Beispiel macht das. Ein durchschnittliches Formular mit 10 Eingabefeldern (jeweils mit einer Beschriftung und einer Nachricht) und 2 Schaltflächen würde nicht mehr als 1 KB benötigen. Bei 15 Ansichten in einer Sitzung sollte dies nicht mehr als 15 KB pro Sitzung sein. Bei ca. 1000 gleichzeitigen Benutzersitzungen sollte dies nicht mehr als 15 MB betragen.

Ihr Anliegen sollte sich mehr auf die realen Objekte (verwaltete Beans und/oder sogar DB-Entitäten) im Sitzungs- oder Anwendungsbereich konzentrieren. Ich habe eine Menge Codes und Projekte gesehen, die unnötigerweise die gesamte Datenbanktabelle in Javas Speicher duplizieren, im Stil einer Session Scoped Bean, in der Java anstelle von SQL zum Filtern/Gruppieren/Anordnen der Datensätze: Bei ~ 1000 Datensätzen würde dies leicht 10 MB pro Benutzersitzung überschreiten.

196
BalusC