[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Y Store /Closures
I think this questions is like saying:
"... struggling to understand how <<objects>> interact with modern load balancers.
Having the state maintained in a file/db allows for the machine that serves..."
Continuations and closures can be replicated in any language (a-la Turing), just as
with Object-Oriented behavior. From my brief look, the Seaside framework handles
things in a similar fashion to J2EE or my company's in-house product, namely the
session state is handled by storage in the database with a unique session ID to
retrieve the values.
Just as we have to have fail-over or other logic to handle marshalling the data from
an object into the database when traversing pages to allow a user to return without
losing data, so would continuation information need to be marshalled back to the
The main difference we are describing is that a language that easily handles the
concepts of closure and continuations makes it much easier to code frameworks
to handle non-linear process flow, just as classes and modules make it easier to
organize and modularize code than can be done in assembly language.
From: Russ Ross [mailto:email@example.com]
Sent: Sat 3/1/2003 8:04 AM
Subject: Re: Y Store /Closures
> The other dimension that I've been struggling to understand is how
> these facilities interact with modern load-balancers. Having the state
> maintained in a file/db allows for the machine that serves the "next"
> page hit to be a different one than the first (as j2ee or .net
> environments do). Is passing cps/vm state between multiple cpu's a
> well understood problem in Smalltalk or Scheme these days -- maybe
> there's been progress on this problem that I am unware of.
I'm sure this varies with the implementation, but at least some J2EE
environments attempt to redirect all interactions within a single
session to the same server so that state can be maintained in
memory. If it has to go to another server, there is a more
expensive serialize-transfer-unserialize process that takes place.
The load balancer effectively works at the session level instead of
the request level. I assume that also means that a server restart
will lose the state for the sessions it was hosting but I'm not