[Jscheme-user] Fwd: Re: Y Store /Closures

[Ken A. <kan...@bb...>]

This is from light weight languages.
We should check out how SISC does continuations.

>To: Daniel Weinreb <DLW...@at...>
>Cc: Christopher Barber <cb...@cu...>,
>   Sundar Narasimhan <su...@as...>, mv...@cs...,
>   eli...@ve..., ll1...@ai...
>Subject: Re: Y Store /Closures
>From: Matthias Radestock <mat...@so...>
>Date: 08 Mar 2003 13:47:34 +0000
>Lines: 44
>User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code)
>Sender: own...@ai...
>Old-X-Spam-Status: NO
>Old-X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>Old-X-Scanned-By: MIMEDefang 2.17 (www . roaringpenguin . com / mimedefang)
>X-Scanned-By: Spam Assassin
>X-Spam-Status: No, hits=-3.4 required=5.0
>        tests=IN_REP_TO
>        version=2.31
>X-Spam-Level: 
>
>Daniel Weinreb <DLW...@at...> writes:
>
>> 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?
>
>When writing continuation-based web apps using the SISC Scheme
>interpreter (http://sisc.sourceforge.net) continuations get stored in
>the user session of the J2EE app server. SISC continuations are
>java-serializable. Many app servers deal with session migration by
>serializing the sessions and restoring them on the migration
>target. Persistence is accomplished by simply storing the serialized
>continuations in a DB. I have run experiments with Tomcat involving the
>restarting of the app server in the middle of a workflow - it all works
>beautifully.
>
>As has been pointed out elsewhere, one needs to be careful about
>ensuring that cntinuations do not hang on to unnecessary state,
>particularly state that is not serializable. Some J2EE objects, such as
>http requests are not serializable and are quite prone to ending up in
>the continuation, thus breaking serialization. In my SISC web apps I
>get around this through some scaffolding that involves storing these
>transient objects in what amounts to thread-locals. This happens
>transparently to application code.
>
>Continuations in a user session tend to share a lot of state. So the
>storage requirement and (de)serialization runtime cost is actually quite
>low for all continuations except the first. Also, serialization of
>continuations in SISC never serializes the top-level, i.e. "global"
>state, since that would entail serializing pretty much the entire heap
>and hence be way too expensive. This, of course, means that application
>state should not be stored in the top-level if it is to be
>persistent. That's ok though since in most apps the application state is
>kept in the DB / some remote EJBs anyway.
>
>
>Matthias.