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