tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
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 08:47:30 GMT

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.



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

View raw message