cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathaniel Alfred" <>
Subject RE: [IMP] synchronization on session object in Cocoon
Date Wed, 11 May 2005 19:40:53 GMT
>-----Original Message-----
>From: Sylvain Wallez []
>Sent: Mittwoch, 11. Mai 2005 18:04
>Subject: Re: [IMP] synchronization on session object in Cocoon
>Joerg Heinicke wrote:
>>Sylvain Wallez <sylvain <at>> writes:
>>>Or more simply we could store the wrapper in the session 
>itself using an 
>>>attribute. That way it would be guaranteed to be created only once.
>>Yes, that's another possibility I also had in mind. But on 
>the one hand this
>>smells a bit (storing a wrapper in the object that the 
>wrapper wraps), on the
>>other hand you can not restrict access to it, so it can be 
>manipulated from
>>somewhere else. But the Map solution can indeed be very 
>resource consuming and a
>>bottle neck.

I am having second thoughts about the proposed solution.  If the Cocoon session is stored
as parasitic session attribute, the container can no longer serialize it for persistance or
cluster replication.  Not that one really needs to save/restore this particular attribute
but it will cause nasty log messages at the very least.

I think now that a private WeakHashMap (to leave session timeout to the container) should
be the preferred solution.

Cheers, Alfred.
This message is for the named person's use only. It may contain confidential, proprietary
or legally privileged information. No confidentiality or privilege is waived or lost by any
mistransmission. If you receive this message in error, please notify the sender urgently and
then immediately delete the message and any copies of it from your system. Please also immediately
destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail communications through their
networks. Any views expressed in this message are those of the individual sender, except where
the message states otherwise and the sender is authorised to state them to be the views of
the sender's company.

View raw message