You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2005/05/25 23:19:44 UTC
Re: svn commit: r169150 -
/cocoon/trunk/src/java/org/apache/cocoon/environment/TemplateObjectModelHe
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