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

[Jason Hunter]

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

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

Wait a sec.  What I think Gene was saying (or at least what Gene made me
think about) is that in our FAQ we state that one common use of JDOM is
read-only access from multiple threads.  We use that to justify why JDOM
isn't synchronized internally (because you don't need sync to allow
read-only).

Gene points out that if we're doing caching internally and setting the
cache during the first invocation of a get call (as we are doing) then
read-only operations *can* change the internal state of the objects and
that opens the possibility for race conditions in the code handling the
cache.

For example getTextTrim() on its first execution saves a copy of the
trimmed text.  What if someone else calls getTextTrim() before the first
method finishes?  Well, looking at the code we're OK because the state
change is atomic and the second call will just recalculate the text
value and set the cache value a second time when it finishes.  

The point we need to take away is that we need to make sure that none of
our caching logic has race conditions for read-only access, and really
IMHO we *should* guarantee that read-only access of JDOM doesn't need
external synchronization once the doc has been built.  A quick code
review of the most likely problem areas makes me think we're OK and have
always been OK, but we need to make sure we stay OK in the future.

-jh-