[jdom-interest] Re: JDOM thread safety (yes, I read the FAQ - still unclear)

[Brett McLaughlin]

Gene Florintsev wrote:
> 
> Dear JDOM managers,
> 
> I have a question about JDOM thread safety. In the FAQ section, you are
> stating:
> 
>     1) there are no synchronized blocks within org.jdom
>     2) we expect the primary JDOM use cases to be: ... Single thread reads
> an XML stream into JDOM and makes it available to a run time system for read
> only access
> 
> I would like to know if you are going to **guarantee** that multiple threads
> can at least traverse the DOM tree concurrently (read-only).

There is no DOM tree in JDOM, so this is an irrelevant question. If you
mean the JDOM structure, no, we don't guarantee that. That is, by
definition, what the synchronized keyword does, so as stated in the FAQ,
it isn't guaranteed. If you need that behavior, you would need to
synchronize your code - but most people don't, so adding the overhead to
the general case is not a good idea for us.

> 
> In Xerces, for example, the attempt to do that will lead to a disaster,
> because the DOM implementation is trying to cache answers to most
> "questions", and there are no synchronized blocks, just like in JDOM. For
> instance, if you taks a Xerces Document and concurrently ask it from
> multiple threads to getFirstChild (), you will get null in all threads but
> one.
> 
> My point is: if seemingly read-only operations, such as getFirstChild (),
> are internally modifying the object, you are going to need synchronization.

Our accessor methods do not internally modify the object. That's a DOM
problem, not a JDOM one.

> And even if today you are not caching things, you might start tomorrow (at
> least, the Apache folks discovered that they needed it for some reason). And

We are caching things, and do not ever see updating a value in, for
example, a String, because the underlying object had it's value
modified. This is a by-value vs. by-reference thing. When you get
objects by reference, they change when the reference is modified. When
you don't, you don't ;-) This is built just like JDBC, for example.

> your classes may become thread-unsafe under the circumstances in question,
> **unless you are willing to guarantee their safety**.

We don't guarantee this - again, it is a worst case performance where
synchronicity is needed, so we don't do it for all cases - if you need
this behavior, either add it to your code, or subclass JDOM and simply
do:

public TSElement extends Element

public synchronized getChild(String name) {
  super(name);
}

// etc.

}

-Brett


> 
> What is the plan for this?
> 
> Thanks in advance for answering.
> 
> Gene Florintsev
> CTO
> EJBility, Inc
> gene at ejbility.com
> http://www.ejbility.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org