[jdom-interest] Re: static data needs to be thread data for multithreaded applications

[Joseph Bowbeer]

The subject seems to suggest that the solution would be (1) to use
ThreadLocal data for namespaces and other data that is currently static.
ThreadLocal is a Java2 feature.  Using thread local has these
disadvantages: you can end up duplicating the cached data and the work
involved in creating it in each thread.

Other options appear to be: (2) synchronizing access to the static data
or (3) doing-away with the static data.

If (2) is the solution, my advice is to limit the critical section to
the smallest size possible, and then show that performance *is* a
problem before trying to do anything more clever.

As Bill Pugh says: "Using synchronization isn't that expensive, and it
serves as important and useful documentation to programmers about the
intended thread interactions in your code."

At a glance, I don't see how the critical section around namespaces can
be easily reduced...  As I pointed out before, most optimizations
designed to reduce synchronization in Java are just plain wrong,
including double-check locking:

 http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Option (3) has some nice properties, though - like compatibility with
garbage collection.  Can the data that is static now be moved into a
factory as instance data?

--
Joe Bowbeer