we still have a last x pages stored on disk. it is just not a number of pages but it is how many pages fit in the default window size of the file on disk (1 file per pagemap)
by default it is 10MB per pagemap and 100MB per total session. so by default you can hold 10 pagemaps of 10MB after that least used pagemaps are cleared. johan On Tue, Nov 4, 2008 at 12:48 AM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > 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] > >
