Session time-out; serialization of continuations

12 views
Skip to first unread message

Joubert Nel

unread,
Jan 8, 2008, 6:19:06 PM1/8/08
to weblocks
Hi,

I understand that weblocks maintains session information on the web
server. How long are sessions kept alive and is this configurable? The
issue I have is that I nav to my application, and maybe after an
extended period of time try to interact with it, at which time I get
an error "The session has timed out".

I am new to (delimited) continuations and CPS, but have done some
reading on the subject. Do you think it is feasible to serialize
weblocks continuations to the HTML that is sent to the client so that
state is kept on the client and not maintained on the server? This
seems to me like a viable approach to getting around session time-
outs.

Joubert

Vyacheslav Akhmechet

unread,
Jan 8, 2008, 11:45:37 PM1/8/08
to webl...@googlegroups.com
This would be very difficult even without continuations. You'd have to
serialize all session-state - closures, CLOS objects, etc. At the
moment there is no cross-platform way that I know of to serialize
closures. Weblocks is designed with this in mind - no serialization
makes for easier, more natural programming.

Think of how other web applications usually behave. When you request a
resource with a timed out session you normally get redirected to a
login page or a home page. Ultimately this is how weblocks will behave
as well, I just didn't get the chance to implement this bit.

You may want to look at pkuong's work in this area:

http://www.pvk.ca/Blog/Lisp/CommonCold/serialisable_closures_in_sbcl.html

This does what you want but only on SBCL. If you can come up with an
SBCL-specific weblocks extension I'd consider integrating it (though I
am not completely convinced it's a good idea).

Slobodan Blazeski

unread,
Jan 9, 2008, 6:17:33 AM1/9/08
to weblocks
It is possible but opens a can of worms.Search cll for lisp success
story from hungary for a concrete example.
The question pending are hwo long do you plan to keep continuation
valid, how to protect from replying of continuation, what about
performance continuation could grow a lot and become a bottleneck.
Search c.l.l for discussion fo this issues. I think Weblocks does the
right way with session, they just expire. If you have something like
shopping basket that you want to keep items in after the timeout of
the session it's programmer job to keep the state. Beside he's the one
who knows best what state should be kept, instead of keeping
everything.

Slobodan
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/ccc371be797e4bf/6d123d47e314eccf?q=continuations+web+&lnk=ol&
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/5b074b1c56b53d05/6eb61ba76dac0535?lnk=gst&q=hungary+common+lisp+success#6eb61ba76dac0535

Joubert Nel

unread,
Jan 9, 2008, 11:00:47 AM1/9/08
to weblocks
On Jan 8, 11:45 pm, "Vyacheslav Akhmechet" <coffee...@gmail.com>
wrote:
> This would be very difficult even without continuations. You'd have to
> serialize all session-state - closures, CLOS objects, etc. At the
> moment there is no cross-platform way that I know of to serialize
> closures. Weblocks is designed with this in mind - no serialization
> makes for easier, more natural programming.
>
> Think of how other web applications usually behave. When you request a
> resource with a timed out session you normally get redirected to a
> login page or a home page. Ultimately this is how weblocks will behave

OK. Is there a way for an application to capture+process a request
from an expired session so that, from the end-user's point of view,
there's no interruption of their work if their session has
(technically) expired on the server (i.e. they didn't perform any work
for an period of time, but from their point of view they're simply
continuing their work).

Another Q: I presume the answer is yes, but just want to confirm: a
session expires after a set amount of time if inactivity, not a period
of time that the session was created?

> as well, I just didn't get the chance to implement this bit.
>
> You may want to look at pkuong's work in this area:
>
> http://www.pvk.ca/Blog/Lisp/CommonCold/serialisable_closures_in_sbcl....
>
> This does what you want but only on SBCL. If you can come up with an
> SBCL-specific weblocks extension I'd consider integrating it (though I
> am not completely convinced it's a good idea).

Great, I'll take a look at this - I'm using SBCL and don't need my app
to run on other lisps.

Joubert

Vyacheslav Akhmechet

unread,
Jan 9, 2008, 11:15:38 AM1/9/08
to webl...@googlegroups.com
On 1/9/08, Joubert Nel <joube...@gmail.com> wrote:
> OK. Is there a way for an application to capture+process a request
> from an expired session so that, from the end-user's point of view,
> there's no interruption of their work if their session has
> (technically) expired on the server (i.e. they didn't perform any work
> for an period of time, but from their point of view they're simply
> continuing their work).
Take a look at 'handle-client-request' in request-handler.lisp. At the
very beginning of the function it checks for a case when there is no
session but there is an action code in the request objects. Because
action is gone (they're stored in sessions, and session is expired at
this point), handle-client-request signals an error. Currently I
didn't specialize the condition, but if you hack in your own condition
that you handle, or some hook, you can do whatever you want at this
point (for example redirect to /). If you do something elegant here,
perhaps you could send a patch?

Regards,
Slava Akhmechet

> Another Q: I presume the answer is yes, but just want to confirm: a
> session expires after a set amount of time if inactivity, not a period
> of time that the session was created?

Session is configured to expire after some time of inactivity.
Weblocks simply uses hunchentoot sessions so if you look up
hunchentoot documentation you can see in more detail how they operate,
how to configure them, etc.

Reply all
Reply to author
Forward
0 new messages