[jdom-interest] static data needs to be thread data for multithreaded applications
bob at accurev.com
Fri Sep 22 10:16:09 PDT 2000
I may be completely off-base with regards to the Namespace improvements,
but if the Document/Element tree maintains the actual mappings, or
references to the mappings, I don't understand how threads can be a problem.
Even if we maintain the mappings statically, there still only needs to be
a single Namespace object mapping foo->http://foo.org/, across all threads,
I guess I'm just missing the point.
On Fri, 22 Sep 2000, Jools Enticknap wrote:
> > > The actual patch is trivial it's just a matter of add a
> > > synchronized block in getNamespace as marked with ++ below,
> > > and some suitable comments on synch policy.
> > That's the easy way. :-) But I was wondering if there could be an
> > optimization (it's important here, this code is called all the time).
> > Like for example you could put "if not contains then add" in the sync
> > block and handle the return and the corresponding hash lookup outside
> > the block. That'd shorten the crit section.
> Before we go down this path, I'd like to see some benchmarks, and some
> more reasoning.
> Also, is there an external way of resolving this problem without having
> to resort to putting synchronization into the code API ?
> One approach might be to have separate classloaders for each 'read'
> thread. That way there would be more than one static namespace hash,
> and no need to synchronize it internally.
> To control your jdom-interest membership:
More information about the jdom-interest