[Jelly] Are Script objects supposed to be thread-safe?

[Morgan Delagrange <md...@yahoo.com>]

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.

- Morgan 

=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[Berin Loritsch <bl...@apache.org>]

Morgan Delagrange wrote:
> 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.


Without very complex script object generation, or very
simple script objects, it is difficult to ensure that
the script object is going to be thread-safe.  I would
assume that they are not thread-safe.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[Morgan Delagrange <md...@yahoo.com>]

Thanks James!  Having per-thread state management is
much better than maintaining a pool.  

- Morgan

--- James Strachan <ja...@yahoo.co.uk> wrote:

<snip/>

> 
> So AFAIK the Scripts are all thread safe; there's
> only a few of them left
> now which should help ensure that thread-safety is
> preserved.
> 
> James

<snip/>

=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[James Strachan <ja...@yahoo.co.uk>]

From: "James Strachan" <ja...@yahoo.co.uk>
> From: "Morgan Delagrange" <md...@yahoo.com>
> > 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. 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). However
> once you have a Script you should be able to run it in several threads.
>
> 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.
>
> The org.apache.commons.jelly.impl package contains the Script
implementation
> classes, *Script.java, which should be thread safe. Though I think
> BeanTagScript might not be threadsafe right now, it might need a couple of
> tweeks to ensure thread safety. FWIW I've been meaning to simplify the
code
> in this part so that BeanTagScript, TagScript and DynaTagScript merge
> together into a single class capable of invoking at runtime either a bean
> Tag or a DynaTag and being thread safe)

I've completed the work in this area now. The old TagScript, BeanTagScript
and DynaTagScript have now rolled together into a single TagScript
implementation. (This makes life much easier as a Tag at request time could
dynamically resolve to a Tag bean or a DyanTag). Also the old non-threadsafe
BeanTagScript is no more.

So AFAIK the Scripts are all thread safe; there's only a few of them left
now which should help ensure that thread-safety is preserved.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[James Strachan <ja...@yahoo.co.uk>]

From: "Morgan Delagrange" <md...@yahoo.com>
> Nice!  More below...
>
> --- James Strachan <ja...@yahoo.co.uk> wrote:
> > From: "Morgan Delagrange" <md...@yahoo.com>
> > > 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[Morgan Delagrange <md...@yahoo.com>]

Nice!  More below...

--- James Strachan <ja...@yahoo.co.uk> wrote:
> From: "Morgan Delagrange" <md...@yahoo.com>
> > 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?  There is no danger of a
Tag carrying over state from parse to parse, or is
there?  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.

> 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.

> 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?  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.

> Though I think
> BeanTagScript might not be threadsafe right now, it
> might need a couple of
> tweeks to ensure thread safety. FWIW I've been
> meaning to simplify the code
> in this part so that BeanTagScript, TagScript and
> DynaTagScript merge
> together into a single class capable of invoking at
> runtime either a bean
> Tag or a DynaTag and being thread safe)
> 
> 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:  
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 


=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Jelly] Are Script objects supposed to be thread-safe?

[James Strachan <ja...@yahoo.co.uk>]

From: "Morgan Delagrange" <md...@yahoo.com>
> 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. 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). However
once you have a Script you should be able to run it in several threads.

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.

The org.apache.commons.jelly.impl package contains the Script implementation
classes, *Script.java, which should be thread safe. Though I think
BeanTagScript might not be threadsafe right now, it might need a couple of
tweeks to ensure thread safety. FWIW I've been meaning to simplify the code
in this part so that BeanTagScript, TagScript and DynaTagScript merge
together into a single class capable of invoking at runtime either a bean
Tag or a DynaTag and being thread safe)

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>