cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@gmail.com>
Subject Re: Session replication
Date Tue, 07 Jun 2005 08:49:06 GMT
On 6/7/05, Matthew Langham <mlangham@s-und-n.de> wrote:
> > > ...Obviously Cocoon doesn't yet support this - through the
> > problems in
> > > Flow etc. (and maybe others)...
> >
> > FYI, in case you hadn't seen it, there's
> > http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-
> > serialization
> >
> > Of course this doesn't solve the problem *today* ;-)
> >
> 
> No, unfortunately not. The customer considers this requirement to be a
> make-or-break for using Cocoon :(.
> 

Doesn't Javaflow support serialization? In any case, when I stumble
across such kind of issues, my answer tends to be twofold: first of
all I question the real need for unconditional failover, since this is
an issue that tends to become gold plating in no time flat. I still
have to see a single application that fails over nicely, given that
devs tends to put in session objects any kind of stuff (most notably
database connections). Remember that a single non-serializable object
in your session will make failover support useless.  Technically wise
it's much better to plan for failures (don't use sessions unless you
really have to) instead than leaving it to the underlying framework:
high availability is much better achieved by redundancy than
clustering (I saw just too many clusters failing).

Having said that, it's definitely true that flowscript by itself isn't
serializable (yet). However, in a business continuity scenario, what
you should do is keep your sendPageAndWait() to a bare minimum:
ideally a continuation shouldn't spawn more than two or three screens,
whereas the business model should be kept elsewhere. Consider CForms,
as an example: most of the time, the continuation is used for two or
three screens: fill, [confirm], commit.  The real use of
continuations, here, is when form validation fails: this is where you
might have a continuation lasting for a dangerous number of screens
and, if a failure occurs, you might be stuck. However, it shouldn't be
much of an hassle to perform (partial) bindings upon every submit on a
clusterizable object, so that if something fails you can start a (new)
form on the fallback server, losing as little work as possible.

Bottom line: I consider this more as an "uneducated CIO" issue rather
than a real technical blocker. But you will always find clueless
people. :)

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)

Mime
View raw message