Return-Path: 
 <dev-return-74143-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 21165 invoked from network); 12 May 2005 09:26:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 12 May 2005 09:26:09 -0000
Received: (qmail 50245 invoked by uid 500); 12 May 2005 09:28:18 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 49840 invoked by uid 500); 12 May 2005 09:28:11 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 49820 invoked by uid 99); 12 May 2005 09:28:10 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 12 May 2005 02:28:10 -0700
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1DW9nU-0000cO-Kl
	for dev@cocoon.apache.org; Thu, 12 May 2005 11:16:00 +0200
Received: from srvgw12.rauser-ag.com ([217.146.133.165])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Thu, 12 May 2005 11:16:00 +0200
Received: from joerg.heinicke by srvgw12.rauser-ag.com with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Thu, 12 May 2005 11:16:00 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@cocoon.apache.org
From: Joerg Heinicke <joerg.heinicke@gmx.de>
Subject: Re: [IMP] synchronization on session object in Cocoon
Date: Thu, 12 May 2005 09:15:50 +0000 (UTC)
Lines: 45
Message-ID: <loom.20050512T110727-246@post.gmane.org>
References: 
 <FDD5D99066749040AF9098A720E9897765581B@CIWMEXZSA0E.ex.ordersx.org>
 <42830A96.3040309@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 217.146.133.165 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE;
 rv:1.7.7) Gecko/20050414 Firefox/1.0.3)
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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