cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [IMP] synchronization on session object in Cocoon
Date Thu, 12 May 2005 09:15:50 GMT
Sylvain Wallez <sylvain <at>> writes:

> >>>>Or more simply we could store the wrapper in the session itself using
> >>>>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.

> >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?


View raw message