You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2006/11/09 09:47:30 UTC
Re: svn commit: r471309 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/StandardSession.java
webapps/docs/changelog.xml
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
Re: svn commit: r471309 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/StandardSession.java webapps/docs/changelog.xml
Posted by Sandy McArthur <sa...@apache.org>.
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 <de...@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
Re: svn commit: r471309 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/StandardSession.java
webapps/docs/changelog.xml
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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