Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: domain of sandymac@gmail.com designates
 64.233.162.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=n1JD1UFGGhBKcwLvrRj2xkdxHAOi1ZxxBGBdXfCdPscUAxfvGwJ2/LGIX6ZJuvMDX0QlRY1E1LL/RTfKtn9sJqVt370OQzrWiHCK5Vppjd1UHeGIk+W1GCIbF++gNkbUHjIJ9W8gyus1Z1DLi7GH4whbdjuMqzLP10Z0BzSQUWQ=
Message-ID: <6bde122b0611090831q7040f8a4mc95500007fede8f6@mail.gmail.com>
Date: Thu, 9 Nov 2006 11:31:35 -0500
From: "Sandy McArthur" <sandymac@apache.org>
Sender: sandymac@gmail.com
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: svn commit: r471309 - in /tomcat/container/tc5.5.x:
 catalina/src/share/org/apache/catalina/session/StandardSession.java
 webapps/docs/changelog.xml
In-Reply-To: <45534655.8020306@hanik.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061105011112.954181A9846@eris.apache.org>
	 <6bde122b0611081121r6d00c6c2h1d6eab4f325071ba@mail.gmail.com>
	 <4552EB22.2090405@kippdata.de> <45534655.8020306@hanik.com>

After having slept on it and reading more of the servlet spec I no
longer think this is the best solution. I think it would make Tomcat
more divergent from the spec in the common case which is not good. I
think I was trying to be too clever. If someone wants the patch, I'll
send it to you.

On 11/9/06, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
> I tend to agree with Rainer, session expiration should be done with a
> predictable pattern
> the trick below is neat, the idea of it, but for practical session
> expiration I'm not so sure.
>
> Filip
>
> Rainer Jung wrote:
> > Hi,
> >
> > Sandy McArthur schrieb:
> >
> >> The way it works is the StandardSessionFacade is referenced like it
> >> was with the facade field in StandardSession and a WeakReference to
> >> the StandardSessionFacade is added the the field facadeReference.
> >> After the maxInactiveInterval the facade field is set to null. Next
> >> time the garbage collector it should break the WeakReference and the
> >> next time the StandardSession is checked to see if it is still valid,
> >> it will be expired.
> >>
> >
> > I think session expiration neeeds to be done with some quality of
> > service. Of course we don't aim at immediate expiration, but I think we
> > should prevent getting worse than the default of 1 minute granularity we
> > have at the moment (plus configurable).
> >
> > If we depend on GC for session expiration, the quality of this service
> > is out of our control. I can easily imagine the relvant objects getting
> > moved to the tenured space, which will be subject to GC very rarely
> > (like every hour or only once a day). And such behaviour is not wrong,
> > instead one should try to configure the new generation and the semi
> > spaces to keep GC on the tenured space very low.
> >
> >
> > ...
> >
> >> If a request for the session comes in after the maxInactiveInterval
> >> but before the WeakReference is broken the facade field will be
> >> updated with the value of the weak reference to prevent the session
> >> expiration.
> >>
> >
> > Is that good? It sounds like: great, if the session is not expired and
> > the user is coming back he will love to find his session is still there.
> >
> > But: if it's online banking and it's not really the user, they'll not
> > like the idea of "your session timeout expired long ago, but you can
> > still use the session".
> >
> > So in my opinion we should not make session expirration dependant on GC
> > runs. GC invocations are totally out of our control and major GC changes
> > are to be expected. Session expiration needs to be done with a defined
> > quality of service.
> >
> > Regards,
> >
> > Rainer
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


-- 
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org