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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
