tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@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
Date Thu, 09 Nov 2006 16:31:35 GMT
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


Mime
View raw message