Re: Y Store /Closures

[Avi Bryant <address@hidden>]

On Sat, 1 Mar 2003, Daniel Weinreb wrote:

> >The real problem is that snapshotting is expensive
> >
> Indeed. What's needed here is something cheap enough to do on every request.

Ideally, yes.  In most cases I would consider forcing a user to
restart their current transaction in the (hopefully) unlikely case of a
server going down to be an acceptable level of inconvenience.  I just
checked, and snapshotting a session currently takes from 100-500ms or so on my machine,
so this is probably a tradeoff I'll have to live with for now.

I certainly don't think that manually saving the session state to a
database on every request is a better solution; the costs in programmer
time to do that are enormous.

> Indeed, checkpointing the entire state of VM is not appropriate if you
> might need to roll back the state of one session but not roll back the
> state of everything else (unless there's one VM per session and nothing
> else happens in the VM, I guess).

Which is actually something I've experimented with.  It's not a bad idea
if you can afford 4-6MB of memory overhead per concurrent session (which
is on the high side but is getting more feasible every day).  If you
really worked at it you could probably get this down to the 1-2MB range.
It's hard to get a functional Smalltalk image (or Squeak image anyway)
below that size.  As I remember, incidentally, ViaWeb took basically this
approach (one image per customer).

But I would still like to get a more robust way of snapshotting individual
sessions in an image, because it's much easier to manage a single VM
deployment.  This is something that can and will be added to Seaside, and
as Seaside deployments get larger it's working its way to the top of my
TODO list.  Basically it requires disconnecting all references from inside
the session to objects external to it, and being able to reconnect these
when loading it back in.

Avi