Thanks Igor! A great help! 

Where on disk are these serialized pages? I remember reading you only cache
the current page in memory. Is that correct? This serializing on disk - what
is the strategy for keeping these files in sync in a clustered environment?

Appreciate the help very much! Graeme.


igor.vaynberg 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]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/How-does-serialization-work--tp20311180p20313794.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]

Reply via email to