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



Reply via email to