LiftSession is bound to HttpSession through HttpSessionBindingListener
and HttpSessionActivationListener
This means that when the HTTP session terminates LiftSession will also
terminate. To verify your SessionVar that the session was purged you
can implement
override protected def
Thanks Marius
I basically wound the session timeout down to 5 mins in the web.xml
and left it for about 30 mins but the sessionVar was still full. Even
after some hours of no use it was the same. There is this constant
ajax_request pinging going on - related?
-- Ewan
On Jul 1, 12:32 pm,
You answered your own question :) ... Yes that is Lift GC mechanism.
You can of course turn it off in Boot by calling
LiftRules.enableLiftGC=false but I would not recommend it.
Is there a real use case why you need this or just tying to figure out
how Lift works ?
Br's,
Marius
On Jul 1,
Well I think I can commit something very simple that could help you,
Currently session expiration mechanism considered only the time
threshold ... but the lift GC is keeping it alive. So we can have
LiftSession#terminateHint function that just marks a flag on this
LiftSession. SessionMaster can
Ewan,
It seems that you've done your tests with a browser open to a page in your
Lift app. It seems to me that you don't want to time out a session unless
the user's browser is no longer looking at a page in the app. Is this in
line with your expectations/use case?
Thanks,
David
On Wed, Jul
H I understand the issue/feature now... where by if the page
remains open then the session is kept alive by the ajax request which
is a feature and it could be argued that for almost all cases this
would be what is required. I believe there is a use case for wanting
the session to expire
On Wed, Jul 1, 2009 at 12:24 PM, Ewan ehar...@gmail.com wrote:
H I understand the issue/feature now... where by if the page
remains open then the session is kept alive by the ajax request which
is a feature and it could be argued that for almost all cases this
would be what is required.
