On 6/7/05, Matthew Langham <[EMAIL PROTECTED]> 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/)
