commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [digester] Can rules be re-used?
Date Wed, 19 Jan 2005 01:39:51 GMT
On Wed, 2005-01-19 at 09:54 +0900, Bill Keese wrote:
> >...if separate Digester objects being used by separate threads
> >   share Rule objects, then all Rule objects would need to be thread-safe.
> >  
> >
> Since rules are read-only objects, aren't they naturally thread-safe? I
> know that theoretically read-only objects could be non-thread-safe, but
> in general they are thread-safe, right? For example, HashSet isn't
> thread-safe for modifications, but it is thread-safe for lookups.

But Rules aren't "read-only" objects. They are objects whose begin, body
and end methods perform real work.

Yes, if a constraint were to be adopted that Rule classes are required
to store all data externally, ie are not permitted to store any data
(temporary or otherwise) on member variables (other than initial config
data) then they *should* be thread-safe because that makes them
effectively read-only during a parse. And now that Robert Donkin has
added "named stacks" to the Digester class it shouldn't be too hard to
follow this convention. But this style of programming is alien to many
people, and failing to do this will lead to very
unpredictable/hard-to-debug errors in multi-threaded programs.

I had a quick peek at the existing rules, and found the following
violations of that principle already:
  BeanPropertySetterRule: modifies "bodyText" member.
  CallMethodRule: modifies "bodyText" member.
  CallParamRule: modifies "bodyTextStack" member.
  FactoryCreateRule: modifies "exceptionIgnoredStack"
  NodeCreateRule: modifies "documentBuilder"
I'm sure there are more.

Do people think it is worth the effort/risk to make Rule classes
thread-safe? I'm not sure how many people out there are using pools of
Digester objects....



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message