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

[bob]

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,
right?

I guess I'm just missing the point.

	-bob

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.
> 
> --Jools
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>