RE: Y Store /Closures

["Anton van Straaten" <address@hidden>]

> Scalability has not had enough attention on this thread.
> To get scalability you want stateless servers.

I would rephrase that as: "to get scalability with the tools we have today,
which weren't designed for the purpose" you want stateless servers.  I can't
think of anything fundamental that requires this, though.  The main
fundamental constraint boils down to how much memory you need per session.
With continuations done properly, that doesn't have to be particularly
high - real continuations of a few KB are perfectly achievable.  There's no
good reason you couldn't support tens of thousands of continuation-based
sessions on a box with 2GB RAM available to the application.  And that's
without using the solution Robby just pointed out, of migrating
continuations to and from the client.

Bottlenecks for scalability are much more likely to come from CPU and IO
performance having to do with a specific application, not from maintaining
state.  The only reason people tend to think otherwise is that there's so
much room for improvement in current tools - OSes that can only handle a
couple of thousand threads, for example.  We can improve on that by a factor
of 100 to 1000 with technology that's already available.

> Can you have your cake and eat it too?

You can have a lot more of it than currently standard tools provide.

> A critisism of web-based apps written in Java servlets is that they
> tend to use SessionContext (or whatever it's called - it's been awhile).
> There is less attention paid to building stateless servers than there
> is on mechanisms for distributing and synchronising state between servers.

The people using Java are getting their applications to work, even if they
have to throw a lot of RAM and CPU at them to do so.  They're not worrying
about statelessness unless they find they have to - due to platform/tool
limitations.  In theory, it really shouldn't be a primary concern.

Supporting multiple servers is likely to be a lot more important to
scalability than focusing on making it run as fast as possible on a single
box.  Behind your point is the old question of whether problems should be
fixed by throwing money at hardware.  In cases where that's viable, the
answer, in business, is almost always yes.

> mechanisms for distributing and synchronising state between servers.

Mmm, yummy, a perfect application for continuations.  Migrate them between
servers, and a continuation which paused on machine A while waiting for a
response from the user, suddenly springs to life on machine B and carries on
executing the next line of code.  The system Robby described exploits this
capability.  Think of the transparent scalability this provides, for
server-based applications in general - not just stateless web-style
applications.

Anton