> I assume you're not referring to the bean code created deadlock you reported
> on the user list.
No, lol.
The deadlocks are related to failed code. Because one thread raises an
exception another stays unsatisfied. Or another case where failed code
causes a ReadWriteLock to have null values. That's why I figured it's
not that important. If the code is made to work all is well and it
shouldn't happen. So it's like saying incomplete code is broken? It's
not broken... it's incomplete. There's a difference. :>
The only deadlock that does seem serious is in
GeronimoThreadContextListener.contextEntered()
I tried to look for this notify but can't find it. I know it has to be
somewhere, but since isDestroyed() is false at @Startup, it always
enters and waits forever. I made a temporary quick fix until I can
research it a bit more. The fix was basically to add an "isStarting()"
to get it to fail that fix. I figure the correct fix would be to have
the EjbDeployment.class object added to the properties of
deploymentInfo, though that's left till I can at least get Singletons
to work and have development of our product continue. Then I can start
looking at cleaning up the implementation.
synchronized (deploymentInfo) {
if (deploymentInfo.get(EjbDeployment.class) == null) {
if (!deploymentInfo.isDestroyed()) {
try {
deploymentInfo.wait();
} catch (InterruptedException e) {
log.warn("Wait on deploymentInfo interrupted
unexpectedly");
}
}
}
}
}
Beyond this I'm learning a lot about OpenEJB/Geronimo.
