cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [vote results] FOM
Date Thu, 19 Jun 2003 08:40:27 GMT
Pier Fumagalli wrote:

>On 17/6/03 22:51, "Stefano Mazzocchi" <> wrote:
>>> - Should the flow _always_ be associated with a Session?
>>I haven't written a flowscript that didn't require, in some way or
>>another, the availability of some statefulness on data and it seems to
>>me as overkill to use full execution state preserving (and the
>>URI-encoding of the continuation every time!) just for the data
>>(besides, even today, if you want to keep global flow variables around,
>>you have to enable sessions anyway)
>>In general, it is true that continuations and sessions are different
>>beasts, but in real life, continuations *extend* sessions since they
>>provide the ability to save *even more* state than sessions.
>>But in those situations where procedular flow is weak and navigation
>>decisions are driven by user action and not by flow execution,
>>continuations are overkill and sessions are still the preferred way to go.
>>is there a real need for continuations without sessions? i really can't
>>provide a meaningful example of this.
>>so, I would say +1 to this.
>>if you are against this, please speak up now.
>Pinching in at the last minute, as I'm completely overswamped by work at
>this time (writing a template engine, u know, can be hard)...
>We've got some _serious_ problems with sessions lately at VNU. The problem
>we faced is that in 99.9% of the containers out there sessions, by
>containers, are identified uniquely with a cookie stored on the client side.
>What does that mean? That no matter how many browser windows you have open,
>your client will uniquely be identified by the server as "one".
>Our problem lies in the multitasking ability of one client, so to say, to be
>able to continue two instances of the same flow at once.
>We have a "registration centre", where people can mail (snail mail) and
>phone in to subscribe for VNU's different magazine offering.
>Let's take this example: one of our kids at the registration centre is
>entering the details for one subscriber, whose information he got through
>the post, she has a card in front of her, and goes through several web pages
>(a some sort of "flow") to enter (or rather copy) the user registration
>At the same point in time, the same person gets a call on the phone, he/she
>needs to follow the SAME EXACT FLOW, but in a different "instance" (pausing
>the "card-based" registration, and doing the same thing but asking the
>details from the guy on the phone).
>Now, if my "flow" is somehow stored in the session, which is stored in a
>cookie, the "card" registration details, and the "phone" registration
>details get messed up, as the server has no way to figure out that the same
>client (identified by a cookie) is doing two "instances" of the same thing
>at the same time.
>We solved this by switching our servlet container to Jetty, which has a nice
>feature "forcing" itself to completely ignore cookies and by URL-rewriting
>every link and form action. By forcing this, we now have the opportunity to
>have uniquely identified "per-task" based sessions (based on URL-rewrites),
>rather than a global "per-client" session.
>Given the current implementation of sessions on servlet containers, it's so
>easy to F-word-UP is the client opens a new window and tries to do something
>different (the client will either completely ZERO whatever task he/she is
>doing, or mix up the session data), unless you don't force
>URL-rewriting-with-cookie-ignoring (which AFAIK can be done only w/ Jetty).
>Think about a continuation like an instance of a "task" stored on the
>server, while unfortunately you have to realize that a session is the
>instance of a "client" (with all its tasks) on the server.
>Kinda like multiplexing, multiple tasks on the client, multiple tasks on the
>server, only ONE and only ONE (in most cases) session between the client and
>the server...
>Just my 0.02 GBP/Euro/USD (depending on whatever country you're in)

Pier, unless I'm mistaken, it seems your problem can be solved with the 
flow without hacking sessions.

A continuation tree is actually the "flow instance" you're talking 
about. So you can have different flow instances running concurrently 
smoothly, provided that their state is only stored in local variables.

Global variables should be used to represent state that is 
user-dependent but not flow-dependent.

What do you think ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message