[ Forwarding to the list. D*mn missing reply-to. ]
"Jung , Dr. Christoph" wrote:
> >- org.jboss.system.URLClassLoader.loadClass(String, boolean)
> > delegates directly to the ServiceLibraries _without_ obtaining
> > an instance lock.
>
> that is true, but remember that URLClassLoader.loadClass(String,boolean) may
> be called
> in any thread by the VM itself. The VM does that through the
> f**cked up private synchronized
> java.lang.ClassLoader.loadClassInternally(String). Hence the
> respective URLClassLoader instance is locked and ServiceLibraries can run
> into a race when
> delegating back URLCLassLoader.loadClassLocally() to that respective
> instance in another thread.
Ahhh, now I see.
Yes a deadlock could still possible, like:
T1: URLCL1 enters ServiceLibraries from loadClassInternal,
looking for C1, with instance lock.
T2: URLCL2 enters ServiceLibraries from loadClassInternal,
looking for C2, with instance lock.
T1: ServiceLibraries looks for C1 in URLCL2, has to wait for lock.
T2: ServiceLibraries looks for C2 in URLCL2, deadlocks with T1
Probably the best solution to that would be if we could
organize the URLClassLoaders into a dependency graph
without circularity, like Simon suggested.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
