Date: 2005-01-15T01:20:38
Editor: ReinhardPoetz
Wiki: Cocoon Wiki
Page: FlowscriptAndSessionReplication
URL: http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication
no comment
Change Log:
------------------------------------------------------------------------------
@@ -8,7 +8,7 @@
* store the continuations at the server's (filesystem, database) so that they
survive server shutdowns
= Background =
-Cocoon uses Mozilla Rhino for its Flowscript implementation. Looking into a
Cocoon sitemap reveals that flowscripts are registered in
+Cocoon uses Mozilla Rhino for its Flowscript implementation. Looking into a
Cocoon sitemap reveals that flowscripts are registered in
{{{
<map:flow language="javascript">
@@ -59,7 +59,8 @@
* As the scope has references to many Cocoon internal objects (see the
Cocoon object) serialization wouldn't work because many of them are not
serializable
* Serializing all the large objects would be very expensive
-How do session replicators work? What triggers the replication? I remember to
have read somewhere that it's triggered by the session.setAttribute() method,
in which case changing the state of a session attribute but not the attribute
itself causes problems.--[SylvainWallez]
+''How do session replicators work? What triggers the replication? I remember
to have read somewhere that it's triggered by the session.setAttribute()
method, in which case changing the state of a session attribute but not the
attribute itself causes problems.''--[SylvainWallez]
+''See e.g. the Tomcat documentation.'' ReinhardPoetz
=== Possible way to solve this problem? ===
(outlined by Christopher Oliver)
@@ -91,7 +92,7 @@
=== Description ===
Exchanging e.g. the {{{ContinuationsHolder}}} because only one Continuation
has been added, would be very expensive.
-Rather than having a single ContinuationHolder in the session that keeps all
continuations, it may be better to have each continuation stored as a separate
session attribute. That may both trigger the replication system and reduce the
replication load. --[SylvainWallez]
+''Rather than having a single ContinuationHolder in the session that keeps all
continuations, it may be better to have each continuation stored as a separate
session attribute. That may both trigger the replication system and reduce the
replication load.'' --[SylvainWallez]
=== Possible solution ===
Add some kind of delta management into the serialization/deserialization
process. But how ...?
@@ -107,11 +108,12 @@
}
}}}
-cocoon.getComponent() can return a serializable proxy, but
cocoon.createObject() must return a serializable object. There's also a problem
with CForms: a form contains its own data model, which can be serialized, but
also pointers to its definition, which is shared between form instances and can
contain arbitrary references to non-serializable objects and
components.--[SylvainWallez]
+''cocoon.getComponent() can return a serializable proxy, but
cocoon.createObject() must return a serializable object. There's also a problem
with CForms: a form contains its own data model, which can be serialized, but
also pointers to its definition, which is shared between form instances and can
contain arbitrary references to non-serializable objects and
components.''--[SylvainWallez]
+''In this case the Form object has to provide its own
serialization/deserialization mechanism that make sure that its state is
exchanged correctly.'' ReinhardPoetz
=== Possible solution ===
* Forbid the usage of components
- * ''... how to manage references to service manager or service selector? May
be through serializable proxies... Or may be by documenting that no flow method
should have non-serializable objects on stack...'' by Vadim
+ * ''... how to manage references to service manager or service selector? May
be through serializable proxies... Or may be by documenting that no flow method
should have non-serializable objects on stack...'' --Vadim
= More to read ... =
