From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> Nice! More below...
>
> --- James Strachan <[EMAIL PROTECTED]> wrote:
> > From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> > > Are compiled Script objects supposed to be
> > > thread-safe, or do I need to pool them? In either
> > > case, the answer should probably be documented in
> > the
> > > Javadocs.
> >
> > Scripts are *meant* to be thread safe. So each Tag
> > is thread local so that
> > the same Script can be run concurrently in several
> > threads.
>
> And new Tag are instantiated with every parse
> performed by a given thread?
Tags are created lazily as the Script is executed. There is an option to
cache each Tag in each Script per thread (using ThreadLocal stuff) though
this is off by default.
> There is no danger of a
> Tag carrying over state from parse to parse, or is
> there?
Not by default, only if caching is enabled. Plus most of the gotchas in JSP
are not possible, since caching can only be enabled for the same tag on the
same script. e.g. this script...
<my:foo x="${something}"/>
If the same tag were reused, the setX(...) would be called each invocation
of the script. So the same setter methods are called each time, so its
typically not possible to hit the same errors as JSP, where tags would be
reused in totally different circumstances.
> I hope not; clearing out state was always a
> big pain in taglibs, particularly since the spec has
> always worded the taglib lifecycle very poorly.
Agreed. Creating new tags each time is probably faster too thanks to
hotspot.
> > Note though that
> > the parsing of Scripts isn't thread safe; so only 1
> > thread should parse a
> > Script at once (so the XMLParser could be
> > synchronized or pooled).
>
> Or you could use a fresh XMLParser every time, if you
> have a limited number of scripts to parse, right? I'm
> assuming that two instances of XMLParser can parse
> concurrently with no trouble.
Sure.
Sometimes SAX parsers can take a little while to 'warm up' so often pooling
XMLParsers can sometimes help performance (of any XML tool, same with
digester, betwixt, dom4j etc).
> > However
> > once you have a Script you should be able to run it
> > in several threads.
>
> That's good to know. I wanted to prevent reading
> those
>
> > The JellyContext should be thread local; the aim is
> > to refactor the
> > JellyContext code a little so that it supports
> > pluggable variable Scopes,
> > then some synchronized shared Scopes can be used to
> > share state across
> > threads, while still having thread local Scopes too.
>
> That's what I assumed, cool.
>
> > The org.apache.commons.jelly.impl package contains
> > the Script implementation
> > classes, *Script.java, which should be thread safe.
>
> So, what's the plan here? That any implementation of
> Script should be thread-safe?
Yes. And any that are not thread safe is a bug that we should fix ASAP.
> If so, that should
> probably be noted in the Javadocs somewhere. If not,
> perhaps you should add a method like isThreadSafe() to
> the Script interface, so clients know whether or not
> they can hold onto compiled Scripts.
Agreed. Its on my todo list...
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
