You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/10/15 18:41:33 UTC
Why is FlowInterpreter SingleThreaded?
Just curious for the reason why o.a.c.c.flow.AbstractInterpreter
implements SingleThreaded (and therefore the flow interpreter as
well)?
SingleThreaded means that for each lookup a new instance is
created.
Carsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
>>> huh? do you mean there is exactly one interpreter for a specific
>>> state accessable through the factory? please explain :)
>>
>>
>>
>>
>> Let's explain it in (pseudo-)code:
>>
>> FlowNode.java:
>>
>> // the flow interpreter for this sitemap
>> private Interpreter interpreter;
>>
>> public void initialize() {
>> IntepreterFactory factory =
>> (InterpreterFactory)this.manager.lookup(InterpreterFactory.ROLE);
>> // flowconfig is the <map:flow> element whose content (<map:script>)
>> // is specific to the particular flow implementation
>> this.interpreter = factory.createIntepreter(flowconfig);
>> this.manager.release(factory);
>> }
>>
>>
>> The "interpreter" object contains the state (scripts + global scope)
>> that belong to this sitemap.
>
>
> alright ...that's what I also understood in the first place :)
>
> ...but we would bypass the component manager here. The interpreter
> would no longer need to be a component... or what do you have in mind?
Oh, don't give me any hidden plan about this, as I have none ;-)
This is just the way some of the components work, one of the most famous
examples being the SourceResolver that asks SourceFactories for Source
objects.
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
Re: Why is FlowInterpreter SingleThreaded?
Posted by Torsten Curdt <tc...@vafer.org>.
>> huh? do you mean there is exactly one interpreter for a specific state
>> accessable through the factory? please explain :)
>
>
>
> Let's explain it in (pseudo-)code:
>
> FlowNode.java:
>
> // the flow interpreter for this sitemap
> private Interpreter interpreter;
>
> public void initialize() {
> IntepreterFactory factory =
> (InterpreterFactory)this.manager.lookup(InterpreterFactory.ROLE);
> // flowconfig is the <map:flow> element whose content (<map:script>)
> // is specific to the particular flow implementation
> this.interpreter = factory.createIntepreter(flowconfig);
> this.manager.release(factory);
> }
>
>
> The "interpreter" object contains the state (scripts + global scope)
> that belong to this sitemap.
alright ...that's what I also understood in the first place :)
...but we would bypass the component manager here. The interpreter
would no longer need to be a component... or what do you have in mind?
--
Torsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
> <snip/>
>
>> This means that the interpreter must "externalize" its state
>> (compiled scripts and global scope) in an object stored in the
>> treeprocessor for a sitemap (in the FlowNode).
>
>
> yes
>
>> Or another solution is to change Interpreter into InterpreterFactory:
>> the state mentioned above would then be the interpreter itself.
>
>
> huh? do you mean there is exactly one interpreter for a specific state
> accessable through the factory? please explain :)
Let's explain it in (pseudo-)code:
FlowNode.java:
// the flow interpreter for this sitemap
private Interpreter interpreter;
public void initialize() {
IntepreterFactory factory =
(InterpreterFactory)this.manager.lookup(InterpreterFactory.ROLE);
// flowconfig is the <map:flow> element whose content (<map:script>)
// is specific to the particular flow implementation
this.interpreter = factory.createIntepreter(flowconfig);
this.manager.release(factory);
}
The "interpreter" object contains the state (scripts + global scope)
that belong to this sitemap.
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
Re: Why is FlowInterpreter SingleThreaded?
Posted by Torsten Curdt <tc...@vafer.org>.
<snip/>
> This means that the interpreter must "externalize" its state (compiled
> scripts and global scope) in an object stored in the treeprocessor for a
> sitemap (in the FlowNode).
yes
> Or another solution is to change Interpreter into InterpreterFactory:
> the state mentioned above would then be the interpreter itself.
huh? do you mean there is exactly one interpreter for a specific
state accessable through the factory? please explain :)
--
Torsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt 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...
>
>
> without looking at the code: couldn't we pass the script definition on
> each call?
This means that the interpreter must "externalize" its state (compiled
scripts and global scope) in an object stored in the treeprocessor for a
sitemap (in the FlowNode).
Or another solution is to change Interpreter into InterpreterFactory:
the state mentioned above would then be the interpreter itself.
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
Re: Why is FlowInterpreter SingleThreaded?
Posted by Torsten Curdt <tc...@vafer.org>.
> 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...
without looking at the code: couldn't we pass the script definition on
each call?
--
Torsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: Why is FlowInterpreter SingleThreaded?
Posted by Ugo Cei <u....@cbim.it>.
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).
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">
But I really don't know how hard this would be.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Again I know nothing about Avalon, but there seems to be some
> conceptual confusion between "Stateless" and "ThreadSafe". Stateless
> objects are of course thread-safe but stateful objects may be also. A
> container that automatically turns a "ThreadSafe" component into a
> singleton seems broken to me. Rather I would have thought that a
> container would provide synchronization to such components.
Your're right, and IIUC, Fortress now uses the "singleton" term for
"ThreadSafe", which seems more appropriate.
See bottom of
http://avalon.apache.org/excalibur/fortress/using-meta-info.html
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
Re: Why is FlowInterpreter SingleThreaded?
Posted by Berin Loritsch <bl...@apache.org>.
Christopher Oliver wrote:
> Again I know nothing about Avalon, but there seems to be some conceptual
> confusion between "Stateless" and "ThreadSafe". Stateless objects are of
> course thread-safe but stateful objects may be also. A container that
> automatically turns a "ThreadSafe" component into a singleton seems
> broken to me. Rather I would have thought that a container would provide
> synchronization to such components.
>
> My $0.02,
Hmm. The thing is what synchronization would be meaningful? The only real
way to ensure a singleton and threadsafety for stateful components is to use
a session object for the intermediate state at hand. That session object
would have to be ensured is the correct session object for the component at
hand. I have put together a system where I could force that to be done behind
the scenes, but the synchronization aspects of it make the solution unusable.
It was simply too slow and would cause a bottleneck.
Note that in Cocoon 2.2, we will have a new option available to us: Per Thread
components. They would be able to keep state within a single thread of
execution.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: Why is FlowInterpreter SingleThreaded?
Posted by Christopher Oliver <re...@verizon.net>.
Again I know nothing about Avalon, but there seems to be some conceptual
confusion between "Stateless" and "ThreadSafe". Stateless objects are of
course thread-safe but stateful objects may be also. A container that
automatically turns a "ThreadSafe" component into a singleton seems
broken to me. Rather I would have thought that a container would provide
synchronization to such components.
My $0.02,
Chris
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Christopher Oliver wrote:
>>
>>
>>> I think "SingleThreaded" is rather misleading in this case. I know
>>> nothing about Avalon but from my experience it appears one flow
>>> interpreter is created per sitemap. However, this instance is
>>> definitely accessed by many threads concurrently. I had to put my
>>> own synchronization code into FOM_JavaScriptInterpereter to handle
>>> this.
>>>
>>>
>>
>> Yes, each sitemap holds a reference to the interpreter. As the sitemaps
>> are ThreadSafe (one single instance per sitemap), this is true
>> for the actual use of the interpreter as well.
>>
>> Now, if I understand you correctly, the interpreter can handle multiple
>> requests at the same time? So, if this is true, it's ThreadSafe
>> and we should change it.
>>
>
> 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...
>
> Sylvain
>
RE: Why is FlowInterpreter SingleThreaded?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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...
>
Ok, I understand that; so we *could* make it Poolable then, right?
This is not a hugh issue anyway, but I fear that people might copy the
code and use SingleThreaded in other places where it does matter.
Carsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Christopher Oliver wrote:
>
>
>>I think "SingleThreaded" is rather misleading in this case. I know
>>nothing about Avalon but from my experience it appears one flow
>>interpreter is created per sitemap. However, this instance is definitely
>>accessed by many threads concurrently. I had to put my own
>>synchronization code into FOM_JavaScriptInterpereter to handle this.
>>
>>
>>
>Yes, each sitemap holds a reference to the interpreter. As the sitemaps
>are ThreadSafe (one single instance per sitemap), this is true
>for the actual use of the interpreter as well.
>
>Now, if I understand you correctly, the interpreter can handle multiple
>requests at the same time? So, if this is true, it's ThreadSafe
>and we should change it.
>
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...
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
RE: Why is FlowInterpreter SingleThreaded?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christopher Oliver wrote:
>
> I think "SingleThreaded" is rather misleading in this case. I know
> nothing about Avalon but from my experience it appears one flow
> interpreter is created per sitemap. However, this instance is definitely
> accessed by many threads concurrently. I had to put my own
> synchronization code into FOM_JavaScriptInterpereter to handle this.
>
Yes, each sitemap holds a reference to the interpreter. As the sitemaps
are ThreadSafe (one single instance per sitemap), this is true
for the actual use of the interpreter as well.
Now, if I understand you correctly, the interpreter can handle multiple
requests at the same time? So, if this is true, it's ThreadSafe
and we should change it.
Carsten
Re: Why is FlowInterpreter SingleThreaded?
Posted by Christopher Oliver <re...@verizon.net>.
I think "SingleThreaded" is rather misleading in this case. I know
nothing about Avalon but from my experience it appears one flow
interpreter is created per sitemap. However, this instance is definitely
accessed by many threads concurrently. I had to put my own
synchronization code into FOM_JavaScriptInterpereter to handle this.
Can someone who actually understands this stuff explain how it should it
work?
Thanks,
Chris
Carsten Ziegeler wrote:
>Just curious for the reason why o.a.c.c.flow.AbstractInterpreter
>implements SingleThreaded (and therefore the flow interpreter as
>well)?
>SingleThreaded means that for each lookup a new instance is
>created.
>
>Carsten
>
>
>
>