RE: Y Store /Closures

["Brent Fulgham" <address@hidden>]

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
data store.
 
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.

	-----Original Message----- 
	From: Russ Ross [mailto:ll@russross.com] 
	Sent: Sat 3/1/2003 8:04 AM 
	To: ll1-discuss@ai.mit.edu 
	Cc: 
	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
	sure.
	
	- Russ