Affects Version/s: 10.3.1.4
Fix Version/s: None
From the derby mailinglist
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. 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
I've got the same problem nearly every day in my application, therefore I simplified the example file from the mailinglist. I did also try it with MySQL without a deadlock.