Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 37146 invoked from network); 12 May 2005 10:11:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 May 2005 10:11:18 -0000 Received: (qmail 54657 invoked by uid 500); 12 May 2005 10:15:07 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 54557 invoked by uid 500); 12 May 2005 10:15:07 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 54529 invoked by uid 99); 12 May 2005 10:15:07 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from 10.21.96-84.rev.gaoland.net (HELO mail.anyware-tech.com) (84.96.21.10) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 12 May 2005 03:15:05 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.anyware-tech.com (Postfix) with ESMTP id 4C5073481A for ; Thu, 12 May 2005 12:11:04 +0200 (CEST) Received: from mail.anyware-tech.com ([127.0.0.1]) by localhost (trinity [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13158-07 for ; Thu, 12 May 2005 12:11:02 +0200 (CEST) Received: from [10.0.0.27] (poukram.anyware [10.0.0.27]) by mail.anyware-tech.com (Postfix) with ESMTP id 11E4D34816 for ; Thu, 12 May 2005 12:11:01 +0200 (CEST) Message-ID: <42832BB5.5080603@apache.org> Date: Thu, 12 May 2005 12:11:01 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [IMP] synchronization on session object in Cocoon References: <42830A96.3040309@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at anyware-tech.com X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Joerg Heinicke wrote: >Sylvain Wallez 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