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 consider this and purge the session
properly at the next sessions scan. So you can have an actor where
you're sending messages via ActorPing such as:
ActorPing schedule(MyActor, Purge(S.session), 120 seconds)
When you receive the Purg message on the received LiftSession just
call session.terminateHint. (Note that S.session is a Box
[LiftSession])
The questions would be when am I going to do this scheduling? ... Well
probably right after you are setting a value on your SessionVar.
If someone has any objections about this please do let me know.
Otherwise I could probably commit this today.
Br's,
Marius
On Jul 1, 3:08 pm, Ewan <ehar...@gmail.com> wrote:
> My use case is that I want to "save" anonymous users' (users that have
> not logged on or registered) baskets in the session and don't care if
> they are removed after a period of inactivity. In fact I would like
> the session to be expired after a while to encourage the user to sign
> up which if they do they get the benefit that the basket is persisted.
>
> --Ewan
>
> On Jul 1, 12:59 pm, "marius d." <marius.dan...@gmail.com> wrote:
>
> > 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, 2:42 pm, Ewan <ehar...@gmail.com> wrote:
>
> > > 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, "marius d." <marius.dan...@gmail.com> wrote:
>
> > > > 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 onShutdown(session: CleanUpParam): Unit = {
> > > > ...
>
> > > > }
>
> > > > where in case of SessionVar the session parameter is really a
> > > > LiftSession.
>
> > > > The LiftSession timeout is given by
> > > > HttpSession.getMaxInactiveInterval ... if that period is exceeded the
> > > > LiftSession is unbound from the HttpSession. Does not necessary means
> > > > that the HttpSession is removed by container ust that LiftSession is
> > > > terminated.
>
> > > > But is the problem the fact that HttpSession expired but you still had
> > > > the context in the SessionVar?
>
> > > > Br's,
> > > > Marius
>
> > > > On Jul 1, 12:47 pm, Ewan <ehar...@gmail.com> wrote:
>
> > > > > I have recently started using a SessionVar and am quite happy to have
> > > > > the session wiped after some predefined interval. As an experiment I
> > > > > changed the session timeout in the web.xml a la Java Servlets but this
> > > > > had no effect running on jetty and since I have read that a SessionVar
> > > > > is not just a wrapper around javax.servlet.http.HttpSession. My
> > > > > question is then how can I configure the timeout interval?
>
> > > > > -- Ewan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
