You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Matthew Langham <ml...@s-und-n.de> on 2005/06/07 10:16:02 UTC

Session replication

We have a customer who wants to use Cocoon for a high-profile project.
However this customer has the requirement that the user-session must be
replicated (using Tomcat etc.) so that the end-user can continue without
problems in the event of a failover.

Obviously Cocoon doesn't yet support this - through the problems in Flow
etc. (and maybe others). So my question is basically: How are others
handling this sort of requirement? Doesn't anyone else need this - or are
there other ways of solving the problem?

Any pointers/examples welcome!

Thanks 

Matthew Langham


Re: Session replication

Posted by Torsten Curdt <tc...@apache.org>.
> Doesn't Javaflow support serialization?

Javaflow itself does ...but I don't think
our WebContinuation machinery does.

Although this should not be too hard to add.

cheers
--
Torsten

RE: Session replication

Posted by Matthew Langham <ml...@s-und-n.de>.
> 
> Bottom line: I consider this more as an "uneducated CIO" 
> issue rather than a real technical blocker. But you will 
> always find clueless people. :)
> 

Thanks for all the comments Gianugo, I will try and use my convincing powers
to clue the people up :-). Not sure if it will work in this case though.

Matthew


Re: Session replication

Posted by Gianugo Rabellino <gi...@gmail.com>.
On 6/7/05, Matthew Langham <ml...@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/)

RE: Session replication

Posted by Matthew Langham <ml...@s-und-n.de>.
> 
> > ...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 :(.

Matthew


Re: Session replication

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 juin 05, à 10:16, Matthew Langham a écrit :

> ...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* ;-)

-Bertrand

Re: Session replication

Posted by Reinhard Poetz <re...@apache.org>.
Matthew Langham wrote:
> We have a customer who wants to use Cocoon for a high-profile project.
> However this customer has the requirement that the user-session must be
> replicated (using Tomcat etc.) so that the end-user can continue without
> problems in the event of a failover.
> 
> Obviously Cocoon doesn't yet support this - through the problems in Flow
> etc. (and maybe others). So my question is basically: How are others
> handling this sort of requirement? Doesn't anyone else need this - or are
> there other ways of solving the problem?
> 
> Any pointers/examples welcome!

AFAIU there is no workaround. I've already done some research work to make 
Flowscript replication happend and I contacted a (Hungarian) developer who 
solved the problem of Rhino scope and coninuation serialization in a different 
context. Unfortunatly he and I are both swamped ATM but I think he is willing to 
guide us with his experiences and also some "demo code".

Also see http://issues.apache.org/bugzilla/show_bug.cgi?id=33324

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------