Wicket, page stack and memory usage

The Wicket application serializes and caches all pages to support state components, as well as to support the back button, among other possible reasons. I have an application that uses setResponsePage to go from screen to screen. In a fairly short period of time, the session becomes quite large because all previous pages are stored in the session. For the most part, I only need a session to contain the current page for obvious reasons, and possibly the last 2 or 3 pages, to make navigation easier with the browser button.

Can I make the page expire after I have sailed from it, and I know that I do not want to use the back button for this version of the page? More generally, what is the recommended way to handle a Wicket session?

+4
source share
2 answers

http://apache-wicket.1842946.n4.nabble.com/Wicket-Session-grows-too-big-real-fast-td1875816.html

If you use many domain objects on your page that are ultimately closely related to other domain objects, be sure to avoid serializing them!

Take a look at LoadableDetachableModel to wrap DataView objects and IDataProvider to display a list of domain objects

Do not put domain objects in component instance variables. You must not make references to domain objects final in order to use them in anonymous subclasses. You should not pass a simple list of domain objects to a ListView.

Perhaps by subclassing WbeRequestCycle in your Application class, you can get control over the page lifetime in pagemap ... you haven’t tried, though

+7
source

To avoid session delays due to continuous byte stream stacking due to serialization in session cancellation and memory usage, you can use removable models using hooks to organize your own storage and recovery at the beginning of each request. Thus, you have full control over the models. containing a byte stream of pages that is not required in the session or accessible through the "Back" button.

+1
source

All Articles