Gary:
I was using the OptimizeIt ThreadDebugger to analyze the performance of a web
application running in Tomcat 3.2.3. The application uses XML for data interchange
and renders the HTML using a set of DOM manipulations.
I was finding that by just running two threads concurrently, both threads where
blocking on the same monitor which was owned by the system class loader. Each thread
was making several different calls to XPathAPI.selectSingleNode() or XPathAPI.selectNodes().
This in turn calls the constructor of a class which loads in the Extensions class at runtime.
I guess I'm assuming that if two threads are both trying to load the same class at the same
time that there will be synchronization, such that thread A will wait for thread B to finish
loading the class. Is this not the case?
Thanks,
Glenn
-----Original Message-----
From: Gary L Peskin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 10:47 AM
To: [EMAIL PROTECTED]
Subject: Re: Contention on Class Loader for Extensions class
Glenn --
I'm confused about what you're saying here. I don't understand why the
loading of the Extensions class would cause any serialization. What
ClassLoader is being used in your web application? Is this inside a web
application server? Just because you're using one ClassLoader doesn't
mean there should be contention causing synchronization among the
threads.
Please enlighten me.
Thanks,
Gary
> "Boysko, Glenn" wrote:
>
> Hello:
>
> We are using selectSingleNode and selectNodes in a web application and
> finding a serialization of requests through the Xalan package. In
> particular, when using these functions, the
> org.apache.xalan.lib.Extensions is loaded in each thread for one of
> the constructors. This causes a natural contention among threads a
> single class loader is used regardless of the thread.
>
> My question is how one would work around this limitation in the
> current implementation. I would guess that we need to decompose these
> function calls into smaller APIs and piece them back together. Does
> anyone have any suggestions that might remove this contention on the
> Extensions class?
>
> Thanks,
> Glenn Boysko
> [EMAIL PROTECTED]
>
> P.S.: This is the subject of bug #3266.
