cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: SoC between flow and sitemap
Date Mon, 19 May 2003 19:50:23 GMT

Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:

<big snip />

> An example where sessions aren't mandatory is the XMLForm integration : 
> the form data is kept in the form object, which is a local variable of 
> the script, and hence held by the continuation. This still allows to 
> keep the value input in a screen when you go back, since the form 
> _content_ changes, but not the form object itself.
> So yes, there's a real-life reason for continuations without sessions. 
> But clustering considerations (see above), make me think that the 
> infrastructure requires us to bind continuations to sessions.

ouch... looks like the wrong reason to change your mind to me :-(
it's maybe just being practical, but it's still the wrong reason.

should have a look into the servlet spec, but I would expect that 
the 'application' space was there to ensure the availability of 
the stored objects even if the server is running in a clustered 

> Things are also different with cocoon.createSession(), which binds 
> global variables of the JS script to the session. This actually makes 
> many flow scripts useless without a session.
>> I tend to see it very dangerous to change the behavior of the flow 
>> engine depending on the existance of the session. It's implicit, it's 
>> transparent, it's hidden. users will be hurt by this and will become 
>> best practice to instantiate a session right away every time but I see 
>> no reasons for this
>> note that sessions are very lightweight objects per-se and sessions 
>> provide transparent load-balancing capabilities that are not matched 
>> by clusters. For example, if you have a clustered cocoon environment 
>> and you use continuations without sessions, your request might be sent 
>> to a cocoon different from the one your previous response came from, 
>> generating an undefined state or, more likely, an "invalid 
>> continuation" error.
> That's exactly the concern I was expressing. Note however that bounding 
> continuations to sessions will allow us to use load-balancing, but may 
> still prevent the use of fail-over, which requires the session 
> attributes to be serializable.

this surprises me: why is this different?

>> to avoid this, either we make the different clustered cocoon exchange 
>> continuations over the wire (bottleneck!) or we patch the 
>> load-balancing software to take continuation into consideration! (but 
>> since there is no general rule, you have to patch it by yourself 
>> everytime and most of the time, in big webapp servers like weblogic or 
>> websphere you don't even have access to it!)
> Are you really talking seriously about patching the load-balancing 
> software, even of OSS servers ? This is way out of concern for Cocoon !
>> understand that horizontal scalability is *much* more important than 
>> raw cocoon speed  and we must make all possible efforts to allow this 
>> to happen or cocoon will never make it on really loaded sites.
> Definitely. And an additional lookup in the session attributes doesn't 
> cost that much.
>> So, what do you think if we dropped sessions-less continuations 
>> alltogether and have the flow engine transparently create a session 
>> for you in all cases?
> +1. This will also strengthen the expiration of continuations, as all 
> continuations bound to a session will automatically disappear when the 
> session terminates.

marginal benefit IMHO, it all depends on what you see as session, no?
this could be a competing view: the end of the flowscript to me 
is the end of my use-case, is the end of all continuations that 
were involved, so we get to have cleanup when the script returns 
(much more effiecient :-))

> Sylvain

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message