[jdom-interest] static data needs to be thread safe for multithreaded application s

[Nick Reeves]

When I originally sent this message there was I typo in the subject line
which may have confused people. There have been no replies to this which
expressed an opinion as to whether this was a problem. Do I infer from this
that people don't think this is a problem, if so why.

To be more explicit about a particular example of the problem:

In jdom-b4 The Namespace class has a static field namespaces which is a
HashMap holding
all the Namespaces made so far. Namespace.getNamespace reads and writes this
HashMap. However HashMaps are not thread safe, and multiple use from
different threads will lead to unpredictable results including corrupting
the HashMap, or creating two equivalent Namespaces which won't be ==. This
will only happen in rare race conditions when two threads try and create a
Namespace at the same time.

Since Namespace.getNamespace can get called indirectly by so many other
entry points about the only way to avoid this is to single thread all use of
the JDOM packages which is clearly extremely restrictive.


> Nick Reeves wrote:
> > 
> > Let me make clear first of all I am not asking for 
> individual JDOM Objects
> > to be thread safe. I fully agree that the caller should be 
> responsible for
> > this, following the example of the Java Collections API.
> > 
> > However where the class has hidden static data (such as
> > Namespace.namespaces)the class must be responsible for 
> making access to this
> > thread safe otherwise multithreaded applications such as 
> your typical Web or
> > EJB case, have no choice but to single thread all use of 
> the JDOM packages
> > :(. This would lead to appalling performance in any realistic use.
> > 
> > At present multihreaded use of Namespace.getNamespace even 
> indirectly (eg by
> > importing files in different threads) will cause random 
> failures with
> > ConcurrentModificationException.
>