Stateless pages are available even in 1.2, but much more limited. Basically, when you have no callbacks, you're page will be stateless and not kept in memory. You'd have to do everything with bookmarkable pages, links and page parameters then.
In 1.3, you can use some callbacks while still keeping pages stateless, e.g. using StatelessLink and StatelessForm. There's a simple example showing this in wicket-examples: org.apache.wicket.examples.stateless In your case, if really most of your app is read-only, it's probably worth using that. And finally, a big improvement in 1.3 over 1.2 is that as long as users don't have a HttpSession assigned by the server, and they are only accessing stateless pages, no session will be created by Wicket either, giving you more options in clustering and further decreasing the memory footprint. It is possible to even further optimize bits by digging deeper in Wicket, but for now, this should help quite a lot. Eelco On 5/3/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > In 1.3 you can use stateless pages (with stateless links and stateless > forms). However, you'll have to sacrifice the programming model in > favor of statelessness a little. I'm not really sure it's worth it. > > -Matej > > On 5/3/07, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > > I know that I read somewhere that there is, or is going to be, a way to run > > your wicket application without creating a session (until absolutely > > necessary). We have a site that has mostly been converted to Wicket now, > > and almost all of it is state-less data.... The URLs are all bookmarkable > > (98% of them are), so there is not much state to track. We don't need a > > full object graph of all your pages and components, except for on very few > > pages once you have signed in. > > > > We're experiencing out of memory problems increasingly with an increase in > > traffic. I'm not holding much in the session, but objects are held in pages > > and components.... I now believe we should have used detachable models for > > many things rather than directly holding a reference to a DB-backed object. > > Should I start by going back and retrofitting many of those private > > references within components to use detachable models so that the objects > > are not held in memory? > > > > Any other suggestions? > > > > Thank you! > > Jeremy Thomerson > > texashuntfish.com > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
