Re: Y Store /Closures

[Avi Bryant <address@hidden>]

On Sat, 1 Mar 2003, Daniel Weinreb wrote:

> 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?

As someone pointed out, what you're effectively asking is how you marshal
continuations.  I work in Smalltalk, where there is no real distinction
between objects that can be marshalled and objects that can't - a
Continuation is just a set of stack frame objects, which have references
to CompiledMethod objects, etc, and can be written out to disk just like
anything else.  Taking a snapshot of the entire virtual memory state is
trivial and commonplace in Smalltalk and at least some Smalltalks can use
GC tricks to snapshot (as raw memory chunks, not in any special
marshalling format) any self-contained subset of the virtual image (which
could include continuations, closures, etc).

The real problem is that snapshotting is expensive enough that you likely
don't want to be doing it on every request.  What you need then is some
kind of a checkpointing system, with indications of which points in the
session are important enough to take the hit of saving everything to disk.
If a server goes down you have to resume from the last checkpoint, which
isn't transparent to the user but hopefully isn't too inconvenient
either.

I don't claim to have this entirely worked out - disentangling the
important bits of a session from the rest of the image such that you have
something reasonably small and yet self contained is a bit tricky, and for
now when I checkpoint I use the way too heavyweight approach of just
saving the entire image - but in Smalltalk at any rate this isn't anywhere
near as much of a showstopper as folks make it out to be.

As for the load balancing question, people always bring it up, and
I've never really understood it - every application server I know of with
significant server side state ensures session affinity, so that all
requests for the same session come back to the same instance of the
application.  As long as that instance stays alive, this isn't a problem
(distributing the load session by session will, on average, work out to
the same thing as distributing it request by request).  If a server
instance goes down, you're back to the same problem as above - when is the
last persistent checkpoint you have of the session that some other server
can take over from?

Avi