On 3/19/07, Weaver, Scott <[EMAIL PROTECTED]> wrote: > Well, it is really not a pool per se (I never write pools anymore). I > just want one instance of an arbitrary page per user-session (not per > application). So, the first time the user asks for a page it is created > for then put onto the session. All subsequent requests for that page > would come from the cached copy in the session. This really isn't > "premature optimization" as I tend to be catching a small amount for > ridicule from our app server admin about the memory foot-print of my > application. I have checked most of my components and pages and they > really don't hold anything huge in the member fields so, I just figured > I was getting a build up of pages due to people clicking around in the > application. I could be wrong on that, though. > > Would it help if I limit the number of page version allowed?
What would help is to use the SecondLevelCacheSessionStore which is the default for Wicket 1.3. That only stores the current page in memory and saves history to a temp dir (which is cleaned up when the session expires). Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
