I execute 10 DELETE operations. Each DELETE is executed from its own thread and
deletes a different row from the same table. I get the same behavior with both
the embedded and network driver, on derby 10.3.14.
I am seeing deadlocks. Here is the deadlock dump:
A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : TABLE, GEOFF__BLOG__USER_MESSAGES, Tablelock
Waiting XID : {7250, IX} , BLOG, DELETE FROM GEOFF__BLOG__USER WHERE "PK"=822
Granted XID : {7249, IX}
Lock : TABLE, GEOFF__BLOG__USER, Tablelock
Waiting XID : {7249, X} , BLOG, DELETE FROM GEOFF__BLOG__USER WHERE "PK"=830
Granted XID : {7249, IX} , {7250, IX}
. The selected victim is XID : 7250.
My question is, why are TABLE locks being issued? Why are any locks at all
being issued? I have set the transaction isolation level to READ_UNCOMMITTED.
My JDBC transactions have autocommit false. I am not issuing a LOCK TABLE or
anything else that should cause the Tablelock.
Also, since I never execute any delete against "GEOFF__BLOG__USER_MESSAGES", I
am confused as to why this table appears in the dump. You can see that the
delete statements both delete a different row from GEOFF__BLOG__USER, *not*
from GEOFF__BLOG__USER_MESSAGES. Is it possible that there is some bug that
causes derby to get confused about the long table names, one of which starts
with the other?
Any suggestions?
