cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [IMP] synchronization on session object in Cocoon
Date Thu, 12 May 2005 10:11:01 GMT
Joerg Heinicke wrote:

>Sylvain Wallez <sylvain <at> apache.org> 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.
>>>      
>>>
>
>Besides the other mentioned points that's indeed a no-go for this trivial
>implementation IMO.
>
>  
>
>>Good point. A solution can be to for the wrapper to implement 
>>HttpSessionActivationListener and Serializable, and keep the session it 
>>wraps as a transient attribute (to avoid its serialization), and restore 
>>it on session activation (the HttpSessionEvent contains the session).
>>    
>>
>
>This solution looks really cool and elegant. Unfortunately
>HttpSessionActivationListener is Servlet Spec 2.3. In Cocoon 2.1. we are still
>on 2.2 and I guess (and suggest) we will stay with that. So only the WeakHashMap
>solution remains.
>  
>

2.2, really? It's at least 4 years old!

>>>I think now that a private WeakHashMap (to leave session timeout to the
>>>container) should be the preferred solution.
>>>      
>>>
>>That's a solution that avoids the parasitic attribute. Where should this 
>>Map be stored? As a static field of HttpSession?
>>    
>>
>
>Why not HttpRequest where it is needed because of getSession() methods? Of
>course we could forward getSession() to a factory method in HttpSession that
>decides whether to create a new wrapper or return the existing one.
>
>I have an implementation with map in HttpRequest and without "double-checked
>locking idiom". Shall I commit it?
>  
>

Sure!

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message