Mailing-List: contact docs-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@cocoon.apache.org
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: docs@cocoon.apache.org
To: docs@cocoon.apache.org
Subject: 
 =?iso-8859-1?q?=5BCocoon_Wiki=5D_New=3A__FlowscriptAndSessionReplication?=
Date: Fri, 14 Jan 2005 08:23:50 -0000
Message-ID: <20050114082350.80130.25736@minotaur.apache.org>

   Date: 2005-01-14T00:23:50
   Editor: ReinhardPoetz
   Wiki: Cocoon Wiki
   Page: FlowscriptAndSessionReplication
   URL: http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication

   no comment

New Page:

=3D Goal =3D

 * make session replication work with Flowscript

=3D Background =3D
Cocoon uses Mozilla Rhino for its Flowscript implementation. Looking into a=
 Cocoon sitemap reveals that flowscripts are  registered in

{{{
<map:flow language=3D"javascript">
  <map:script src=3D"flow.js"/>
  <map:script src=3D"flow1.js"/>
</map:flow>
}}}

For every sitemap a scope (A scope is a set of JavaScript objects. Executio=
n of scripts requires a scope for top-level script variable storage as well=
 as a place to find standard objects like Function and Object - find more a=
t http://www.mozilla.org/rhino/scopes.html) that is put into the users sess=
ion.

Additionally to the scope, Cocoon has to manage all continuations that are =
created while executing the functions of the flowscript. Since Cocoon 2.1.6=
, these continuations can be stored in the Session too (its configurable in=
 cocoon.xconf).

{{{
 +-------------------------+
 |SESSION1                 |
 |+-----------------------+|
 ||scope (sitemap A)      ||
 |+-----------------------+|
 |+-----------------------+|
 ||scope (sitemap B)      ||
 |+-----------------------+|
 |+-----------------------+|
 ||scope (sitemap C)      ||
 |+-----------------------+|
 |+-----------------------+|
 ||ContinuationsHolder    ||
 ||(all continuations of  ||
 || this user)            ||
 ||                       ||
 ++-----------------------++
 |+-----------------------+|
 ||other session attr.    ||
 ||                       ||
 ||                       ||
 ||                       ||
 |+-----------------------+|
 +-------------------------+
}}}

=3D What's the problem? =3D

=3D=3D Serializable objects =3D=3D
=3D=3D=3D Description =3D=3D=3D
To enable session replication between two application servers (e.g. Tocmat,=
 see http://jakarta.apache.org/tomcat/tomcat-5.5-doc/cluster-howto.html) yo=
u have to make sure that all session attributes are serializable (implement=
 {{{java.io.Serializable}}}).

Unfortunatly this wouldn't work for Cocoon because of two problems:

 * As the  scope has references to many Cocoon internal objects (see the Co=
coon object) serialization wouldn't work because many of them are not seria=
lizable
 * Serializing all the large objects would be very expensive
 =

=3D=3D=3D Possible way to solve this problem? =3D=3D=3D
(outlined by Christopher Oliver)

I think the first thing you need to do is determine exactly what needs to b=
e serialized into the replicated session. A given Rhino global scope object=
 can contain a lot of references to Java objects that may not be serializab=
le or it may not be desirable to serialize them.

All such objects need to be identified and "replaced" with something else i=
n the serialization stream. You can override the replaceObject() and resolv=
eObject() methods of ObjectOutputStream and ObjectInputStream to implement =
this. When the stream is deserialized you can then substitute suitable repl=
acement objects from the target JVM. See the org.mozilla.javascript.seriali=
ze package in the Rhino distro for an example of this strategy.

Since the FOM objects refer to underlying Cocoon objects that should not be=
 serialized (the session itself, the source resolver, etc) the above strate=
gy would at least need to applied to them.  In addition, objects created by=
 the user that are referenced via the Rhino global scope or the local varia=
bles of a continuation may need this treatment. =


=3D=3D Plugging in the solution into existing containers =3D=3D
=3D=3D=3D Description =3D=3D=3D
The serialization/deserialization process of Java objects has to be overrid=
en (see explanations by Chris). This mechanism has to be plugged into the c=
ontainer without having to modify it.

=3D=3D=3D Possible soluation =3D=3D=3D
 * Override the methods {{{writeReplace}}} and {{{readResolve}}} of the {{{=
ContinuationsHolder}}} and of the Javascript scope. This will require a wra=
pper object for the scope.
 * Write own implementation of {{{ObjectInputStream}}} and {{{ObjectOutputS=
tream}}} that are used by the container as default.

=3D=3D Delta management =3D=3D
=3D=3D=3D Description =3D=3D=3D
Exchanging e.g. the {{{ContinuationsHolder}}} because only one Continuation=
 has been added, would be very expensive.

=3D=3D=3D Possible solution =3D=3D=3D
Add some kind of delta management into the serialization/deserialization pr=
ocess. But how ...?