Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45534655.8020306@hanik.com>
Date: Thu, 09 Nov 2006 09:16:37 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
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
References: <20061105011112.954181A9846@eris.apache.org>
 <6bde122b0611081121r6d00c6c2h1d6eab4f325071ba@mail.gmail.com>
 <4552EB22.2090405@kippdata.de>
In-Reply-To: <4552EB22.2090405@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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