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]

Reply via email to