[
https://issues.apache.org/jira/browse/DERBY-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt Huwig updated DERBY-3015:
------------------------------
Attachment: Repro3015.java
Reproducing example; removing the comment slashed in line 30+31 runs it without
a lock on MySQL. As I did not write the original, I cannot give ASF license.
> Concurrent select and insert deadlock on index
> ----------------------------------------------
>
> Key: DERBY-3015
> URL: https://issues.apache.org/jira/browse/DERBY-3015
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.1.4
> Reporter: Kurt Huwig
> Attachments: Repro3015.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
