Wir haben die Clientstatusspeicherung aktiviert und verwenden ViewScoped-Hintergrundbeans. Wenn das Speichern des Clientstatus aktiviert ist und wir eine ViewScoped-Bean verwenden, wird die ViewScoped-Bean auf die Seite serialisiert oder in der Sitzung mit einem Token / Schlüssel gespeichert, der auf der Seite serialisiert ist (so dass die Seite die Seite aufrufen kann) Bean aus der Sitzung, wenn die Seite an sich selbst zurückgesandt wird.
Ein Problem könnte hier sein, dass wir uns, falls es serialisiert ist, dann darum sorgen sollten, keine großen Instanzvariablen auf der ViewScoped-Bean zu speichern, wenn diese auf der Seite serialisiert wird und über die Leitung hin- und hergeht.
Wenn das Speichern des Client-Status aktiviert ist und wir eine ViewScoped-Bean verwenden, wird die ViewScoped-Bean serialisiert auf die Seite oder wird sie in der Sitzung mit einem Token / Schlüssel, der auf die Seite serialisiert ist, gespeichert? / em>
Mojarra 2.x speichert Ansichtsbereichsbeans in der HTTP-Sitzung. Es gibt eine undokumentierte Einstellung, bei der standardmäßig maximal 25 View-Scoped-Beans in der Sitzung vorhanden sind. Siehe auch Problem 4015 . Mit anderen Worten, die Instanzen für die bereichsübergrei- fende Bean-Sicht werden niemals im JSF-Ansichtszustand gespeichert. Sie werden nur von einer UUID referenziert, die wiederum im JSF-Ansichtszustand gespeichert ist. Daher werden sie im JSF-Ansichtszustand nicht serialisiert, unabhängig von der Speichermethode für den Client / Server-Status.
Ein Problem könnte hier sein, dass wir, wenn es serialisiert ist, uns dann Sorgen machen müssen, keine großen Instanzvariablen auf der ViewScoped-Bean zu speichern, wenn sie auf der Seite serialisiert wird und über die Leitung hin- und hergeht .
Dies ist eine berechtigte Sorge. Auch wenn es stimmt, wir sprechen jedoch über eher extreme Fälle. Eine Sammlung von 100 durchschnittlichen Entitäten mit jeweils 10 durchschnittlichen Eigenschaften sollte nicht mehr als zusätzliche ~ 5 KB auf der Ansichtszustandsgröße sein. Beachten Sie, dass Sie eine große Bandbreite zurückbekommen können, indem Sie die gzip-Komprimierung auf dem Webserver aktivieren, sogar bis zu 70% pro textbasierter Ressource.
Wenn Sie jedoch mit großen Datenmengen zu tun haben, kann die Größe der HTTP-Sitzungsspeicher wiederum ein Problem darstellen. Siehe auch JSF 2.2 Speicherverbrauch: Warum behält Mojarra die ViewScoped Beans der letzten 25 Ansichten im Speicher? Idealerweise sollte die View-Scoped-Bean einfach zerstört werden, sobald die von ihr referenzierte Seite von einer GET-Navigation oder einem Browser gelöscht wird Tab schließen Das standardmäßige JSF-Sichtbereichs-Bean führt dies nicht aus. Es wird nur während eines Postbacks in eine andere Ansicht oder nach Ablauf der Sitzung zerstört.
Falls Sie die JSF-Bibliothek OmniFaces verwenden, ist seit Version 2.2 die @org.omnifaces.cdi.ViewScoped unterstützt die Zerstörung während eines Entladevorgangs. Dies sollte sich positiv auf die Größe des HTTP-Sitzungsspeichers auswirken.
Bitte beachten Sie, dass die Antwort von BalusC für neuere Versionen von JSF nicht gilt: Bei neueren Versionen werden die Daten der javax.faces.view.ViewScoped -Bohnen auf dem Server gespeichert. Siehe JAVASERVERFACES-3090
Tags und Links serialization jsf-2 view-scope