[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Y Store /Closures

Daniel Weinreb <DLWeinreb@attbi.com> writes:

> Now, here's what I want to know. Suppose you want to write a web
> app that maintains state between clicks in the fashion I've been describing,
> but you don't want all that state to be lost in case there is a reboot or
> power failure or crash. In the event-driven style, the state can be stored
> persistently, in a file or database system, so that when the next HTTP
> request comes along, you can pick up where you left off, but in a
> conventional
> language-with-continuations scenario, the continuation state is all in
> virtual
> memory and lost when there's a crash.  What can anyone recommend?

When writing continuation-based web apps using the SISC Scheme
interpreter (http://sisc.sourceforge.net) continuations get stored in
the user session of the J2EE app server. SISC continuations are
java-serializable. Many app servers deal with session migration by
serializing the sessions and restoring them on the migration
target. Persistence is accomplished by simply storing the serialized
continuations in a DB. I have run experiments with Tomcat involving the
restarting of the app server in the middle of a workflow - it all works

As has been pointed out elsewhere, one needs to be careful about
ensuring that cntinuations do not hang on to unnecessary state,
particularly state that is not serializable. Some J2EE objects, such as
http requests are not serializable and are quite prone to ending up in
the continuation, thus breaking serialization. In my SISC web apps I
get around this through some scaffolding that involves storing these
transient objects in what amounts to thread-locals. This happens
transparently to application code.

Continuations in a user session tend to share a lot of state. So the
storage requirement and (de)serialization runtime cost is actually quite
low for all continuations except the first. Also, serialization of
continuations in SISC never serializes the top-level, i.e. "global"
state, since that would entail serializing pretty much the entire heap
and hence be way too expensive. This, of course, means that application
state should not be stored in the top-level if it is to be
persistent. That's ok though since in most apps the application state is
kept in the DB / some remote EJBs anyway.