Actually, it�s more complicated:
Thread 1:
VM detects that it needs bar, calls UCL A.loadClassInternal() and
hence synchronizes on A
Thread 2:
VM detects that it needs foo, calls UCL B.loadClassInternal() and
hence synchronizes on B
Thread 1:
UCL A delegates to Repository delegates to UCL B, LOCKED
Thread 2:
UCL B delegates to Repository delegates to UCL A, LOCKED
CGJ
-----Urspr�ngliche Nachricht-----
Von: lsanders [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 22. April 2002 20:29
An: Jboss-Development@Lists. Sourceforge. Net
Betreff: Re: [JBoss-dev] Workaround for CL stuff
Though I've never experienced this, I think this is the problem scenario:
The players:
UnifiedClassLoader A (can load directly class foo) UnifiedClassLoader B (can
load directly class bar)
Thread 1 (context loader is A):
Load new class bar:
- synchronize on UCL A
- Search UCL B
- Attempt to synchronize on UCL B
Thread 2 (contect loader is B):
Load new class foo:
- synchronize on UCL B
- Search UCL A
- Attempt to synchronize on UCL A
Can someone verify if this is accurate?
-Larry
> Ok,
>
> I am sure we can find something.
>
> I would appreciate a brief description of a CL deadlock scenario due
> to
the
> final loadClassInternal. Jung? Sacha?
>
> It's only software, software is dumb
>
> marcf
>
> xxxxxxxxxxxxxxxxx
> Marc Fleury, Ph.D
> President and CEO
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxx
>
>
>
> _______________________________________________
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
