On 04/02/2024 00:40, Rick Hillegas wrote:
The following information may be helpful:
o Developer Guide material on Derby locking:
https://db.apache.org/derby/docs/10.17/devguide/cdevconcepts30291.html
o Reference Guide material on the SYSCS_DIAG.LOCK_TABLE diagnostic
table:
https://db.apache.org/derby/docs/10.17/ref/rrefsyscsdiaglocktable.html
o A wiki page on debugging locking problems:
https://cwiki.apache.org/confluence/display/DERBY/LockDebugging
Thanks. I had already read the devguide chapter, the second reference
told me what IS and IX meant, and the third only told me what I would
see if a deadlock occurred (and I posted what I saw). The IRC chat
referenced in the wiki page also didn't help me see what was going on in
my case.
The bit that puzzles me is this:
Lock : TABLE, ACTION_LOG, Tablelock
Waiting XID : {255785263, X} , APP, DELETE FROM active_list...
Why is it waiting for ACTION_LOG (and an exclusive table lock at that)
when the trigger doesn't refer to it and neither does the delete on
REGISTRATIONS that triggered it?
I am using the default isolation level (read committed). Would changing
the delete on REGISTRATIONS to read uncommitted make any difference?
I haven't been able to reproduce the error on my test rig yet, so the
little gray cells seem to be the only debugging tool available...
--
John English
