Hello David,
-----Urspr�ngliche Nachricht-----
>Von: David Jencks [mailto:[EMAIL PROTECTED]]
>Gesendet: Mittwoch, 3. Oktober 2001 21:43
>An: [EMAIL PROTECTED]
>Betreff: Re: [JBoss-dev] java.lang.ClassLoader misery. Verify this
>patch!
>In my (unproven) opinion the problem comes from the loadClass(name,
>resolve) method being synchronized and calling to another object within the
>synchronization. The loadClassInternal being synchronized makes no
>difference here (although I might agree it shouldn't be) since it ends up
>calling the synchronized loadClass anyway.
see my previous mail, I think that its was this time the ServiceLibraries
synchronization behaviour where a (globally) unsynchronized dispatching back
to the caller classloader was introduced for optimisation purposes.
public Class loadClass(String name, boolean resolve, ClassLoader scl)
throws ClassNotFoundException
{
...
// If not start asking around to URL classloaders for it
// who will find it?
URLClassLoader cl = null;
if (scl instanceof URLClassLoader)
{
// First ask the asking classloader chances are the dependent class
is in there
try
{
************ Here, no sync is done and the scl will obtain a lock on itself
and come back to the ServiceLibrary while immediately linking files
***************
foundClass = ((URLClassLoader)scl).loadClassLocally(name,
resolve);
//If we get here we know the scl is the right one
cl = (URLClassLoader)scl;
}
catch (ClassNotFoundException ignored)
{
}
}
************ Another CL can at the same time enter here and not get the lock
on the scl above! ***********
synchronized (classLoaders)
{
Iterator allLoaders = classLoaders.iterator();
while (allLoaders.hasNext() && (foundClass == null))
...
CGJ
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
