cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Why is FlowInterpreter SingleThreaded?
Date Tue, 21 Oct 2003 07:59:23 GMT
Ugo Cei wrote:

> Sylvain Wallez wrote:
>
>> After looking carefully, the interpreter must be SingleThreaded, even 
>> if thread safe...
>>
>> This is because although an intepreter can handle concurrent 
>> requests, each sitemap must have a different instance, since the 
>> interpreter holds the scripts defined in a <map:flow> statement.
>>
>> So if the interpreter is made ThreadSafe, a unique instance will 
>> exist for the whole system, and will mix all script definitions and 
>> script global variables. Making it SingleThreaded ensures each 
>> sitemap will have its own instance. It seems hacky, but I don't see 
>> what other means we have to achieve this...
>
>
> Well, it depends. Personally, I never used subsitemaps to host 
> different applications inside the same Cocoon instance. It's much more 
> trouble than it's worth, IMHO. You have one WEB-INF, one cocoon.xconf 
> and it's too easy for one application to step onto the toes of all the 
> others.
>
> OTOH, I do use subsitemaps to logically partition my applications in 
> several modules, as soon as the sitemap grows beyond a handful of 
> matchers. But in that case, it seems logical for subsitemaps to share 
> scripts and global variables (like, for instance, a handle to the 
> user's identity after authentication, otherwise you'd end up 
> authenticating once for each subsitemap).


I understand your concern, but you have to consider cases where a single 
Cocoon application is composed of several modules, each having its own 
sitemap and flow. Having scripts and global scope shared between these 
modules can lead to naming conflicts. And this will be even more a 
problem with blocks.

So my opinion is that if some independent modules in an application have 
to share some data, we have to use the "good old" session attributes. 
The attribute names then become the communication contract between the 
various modules.

But the authentication example above also shows that the problem is not 
only related to sharing data, but also common flows and their associated 
views (the whole login process).

> In the end, maybe it would be useful to be able to specify the kind of 
> interpreter you really want, using something like:
>
> <map:flow language="javascript" shared="yes|no"> 


Or should this shared flag be on a script, allowing to keep some 
functions and variables sitemap-private:
<map:flow>
  <map:script src="module-specific-script.js"/>
  <map:script src="context://authentication.js" shared="true"/>
</map:flow>

> But I really don't know how hard this would be.


Yep...

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message