cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: SoC between flow and sitemap
Date Mon, 19 May 2003 21:28:56 GMT
Marc Portier wrote:

> 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 environment? 

Yes, but you have to consider how this is actually implemented. If you 
put a farm of Tomcats behind an httpd with mod_jk, you will be 
guaranteed that requests for a given session will always be handled by 
the same Tomcat instance. This is called session affinity. But Tomcats 
don't communicate with each others to exchange session or application data.

This means that if a continuation ContA is created on Tomcat TC1, all 
subsequent requests referencing this continuation must be handled by the 
same TC1, and not TC2, since ContA doesn't exist on TC2. And the only 
means you have to achieve this if servlet engines don't communicate is 
through session affinity.

So continuations must be bound to sessions.

You may not wonder that much about this problem if you always deploy a 
single servlet engine instance (don't take any offense, it's the case 
for me most of the time), but if we want Cocoon to be used on very big 
servers like its features and potential allow it, we must take care of 
not forbidding its use in clusters.


>> 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? 

This is different because fail-over requires application and session 
data to be stored on a persistent storage. This means they have to be 
serializable (in the meaning). The same is true for 
load-balancers that allow sessions to migrate from one server to another 


>>> 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 :-)) 

You're right. But if the user leave the use case in the middle, there 
are still some pending continuations that continue to exist until they 
have expired.

Also, some apps provide a "logout" button that does nothing but 
"session.invalidate()". In that case, all pending continuations are 
immediately trashed without having to wait for them to expire.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message