it is cleaned up when the session expires. it used to be that we only kept X last pages in the store, but now that we use disc that seems to be redundant.
-igor On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <[EMAIL PROTECTED]> wrote: > > Hi. > > I wondered another thing - how and when are the serialized objects cleaned > up? Is there a mechanism for making sure large amounts of memory or disk are > not soaked up by long running sessions and lots of user interactions? > > Thanks again, Graeme. > > > Graeme Knight wrote: >> >> Timo! >> >> Thanks for your answers - so you think its better NOT to have the >> components as private member variables? I may misunderstand... >> >> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into >> the Wicket world... >> >> Wicket in Action - VERY readable and well written, but perhaps I didn't >> get far enough along to get to the serialization parts (I'm just beginning >> Part 2). >> >> Cheers, Graeme. >> >> Timo Rantalaiho wrote: >>> >>> On Mon, 03 Nov 2008, GK1971 wrote: >>>> through the forum but couldn't find the answer. Couldn't find the >>>> answers >>>> from Tapestry in Action (I'm sure they are there if anyone can point me >>>> at a >>>> page). >>> >>> You might want to have a look at Wicket in Action :--) >>> >>>> 1) Exactly WHAT is getting serialized and where and when? >>> >>> The page, which includes its whole Component tree. >>> >>>> 2) What are the main classes in the framework responsible for >>>> serialization >>>> that I can look at (I have the source)? I guess I am after understanding >>>> the >>>> flow of logic. >>> >>> I find it easiest to start from Session.requestDetached(). >>> There you have >>> >>> page.getPageMap().put(page); >>> >>> => >>> >>> SecondLevelCacheSessionStore.put(Page) >>> >>> => >>> >>> DiskPageStore.storePage(String sessionId, Page page) >>> >>> and there's already stuff about serialisation. >>> >>> I'm sure that someone can give you a more scientific answer :) >>> >>>> 3) What happens if I make userIdField and passwordField scoped to the >>>> constructor only? Is it common not to have them as member objects and >>>> why? >>>> (I've not tried this yet, just wondered). >>> >>> In here >>> >>>> add( userIdField ); >>>> add( passwordField ); >>> >>> you add them as children of the constructed component. >>> You can always access them for example with a visitor, if >>> needed, and holding references to them makes it harder to >>> replace them if needed (though it shouldn't be a problem if >>> they won't be replaced). >>> >>> Best wishes, >>> Timo >>> >>> -- >>> Timo Rantalaiho >>> Reaktor Innovations Oy <URL: http://www.ri.fi/ > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
