tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r471309 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/ webapps/docs/changelog.xml
Date Thu, 09 Nov 2006 15:16:37 GMT
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.


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message