db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Huwig (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3015) Concurrent select and insert deadlock on index
Date Sat, 18 Aug 2007 14:52:31 GMT

     [ 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:
>            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.

View raw message