cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: svn commit: r169150 - /cocoon/trunk/src/java/org/apache/cocoon/environment/TemplateObjectModelHe
Date Wed, 25 May 2005 21:19:44 GMT
Yes, you need a instance of "newScope" for each thread. These share the 
standard objects through their prototype link instead of the parent 
link. That way global variables (which are not shared) are created in 
"newScope" (it is considered the global scope because its parent link is 
null). But the (immutable) global variables and functions defined in the 
shared scope can still be read (but not written) through the prototype 
link. Note that compiled functions are immutable and can also be shared 
between threads (by storing them in a shared (through the prototype 
link) scope when they are first compiled). You can use two  levels of 
nesting to create isolation between different components whose functions 
should not be shared, ie.

[Var Scope (per thread)] *-->1 [Function Scope (per component)] *-->1 
[Scope with Rhino Standard Objects]

where *-->1 means "many to one relationship through the prototype link".

HTH,

Chris

Christopher Oliver wrote:
 > FYI it is not thread-safe to use a static rhino scope. Instead the
 > caller of the template should should pass this from his own session. I
 > think this same bug also exists in the CForms implemenation but I'm not
 > sure.
 LOL. I based my implementation on CForms :)
Should we go like this then:
Scriptable newScope = cx.newObject(sharedScope);
newScope.setPrototype(sharedScope);
newScope.setParentScope(null);
taken from: http://www.mozilla.org/rhino/scopes.html



Mime
View raw message