Mike Matrigali wrote:
Daniel John Debrunner wrote:
Knut Anders Hatlen wrote:
Mike Matrigali <[EMAIL PROTECTED]> writes:
< snip .?
I'm not so sure. If it's simpler to keep page latching at the page
level, then it would be better to remove the added complexity from the
lock manager. What's the current state of IDEs/debuggers tracking down
java synchronization deadlocks? Seems a better place to solve the
problem.
And also does it help track down a deadlock that is half java
synchonization and half derby lock wait?
I doubt IDES/Debuggers will helps if a user really hits a LATCH/LOCK
or a LATCH/LATCH deadlock. Most of the time I would think they are not
easily reproducible cases; All that user going to tell is DERBY is
acting weird/frozen.
Recent jvms (jdk142 onwards) do tell if there is dead-lock on the
monitor on a stack dump. I hope the stacks will give us some clues,
if the dead locks involves onlt latches or locks also.
If it is embedded , say in APP server I wonder how easy to get a
stack dump or how big it is going to be!
If some one is wondering , does these deadlocks really happen, I
found one : http://issues.apache.org/jira/browse/DERBY-1189
(but Mike seems to have got luckey with the repro)
Lock : LATCH, T1, Page(35,Container(0, 1728))
Waiting XID : {385920, BaseContainerHandle:(Container(0, 1728))} ,
APP, CALL S
YSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1)
Granted XID : {385920, BaseContainerHandle:(Container(0, 1728))}
. The selected victim is XID : 385920.
If we are removing Latching out of LockManager for perfromance
reasons, my preference also would be to handle at the page level,
instead of having yet another indirection.
As Mike mentioned , it would be nice to have a VTI that will show the
latches in the system.
Thanks
-suresh
