Bogdan Calmac wrote:
The attached test is an attempt to simulate a typical data processing
application, it consists of:
- an insert thread that inserts records in batch
- a select thread that 'processes' the records inserted by the other
thread: 'select * from table where id > ?'
The test deadlocks, the trace can be found in 'derby.log' and the java
stacktraces just before the deadlock in
'stacktraces_during_deadlock.txt'.
After examining them, I think that:
- the select thread holds an S lock on the root of the PK index: (1,1)
- the select thread waits for an S lock on one of the uncommitted inserts
- the insert thread holds X locks on the inserted records
- the insert thread tries to split the btree root of the PK index:
(1,1) by acquiring an X lock, so it's a deadlock
Before jumping to conclusions, can somebody confirm if this looks like
an expected behaviour or is it a bug?
This sounds like the same index split deadlock problem I ran into a few
months ago:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200701.mbox/[EMAIL
PROTECTED]
Unfortunately I wasn't able to find a work around. Increasing the page
size didn't help. I think this may be an issue with non MVCC databases.
-Randy
