db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2991) Index split deadlock
Date Tue, 06 Jan 2009 17:44:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-2991:

sorry for late reply, was out and away from computer end of the year.
> I think I understand what you're suggesting, but a couple of questions
> just to make sure that I'm not missing the point:
> - the purpose of this test is to check that we don't perform any
> repositioning by key just because there has been an update on the
> page?
yes.  I must be misunderstanding the current patch, I thought it would
research on an update of the page.  probably worth measuring but not a lot
of different cases if the design does not expect a research.  I was trying
to force a measurement of worst case where a search would happen after every
> - by making sure that the client doesn't cache the values, you
> basically mean that bulk fetch should be disabled? So setting
> derby.language.bulkFetchDefault or perhaps using an updatable
> cursor and positioned updates should do the trick?
My comment was about making the tree bigger.  Not necessarily to not cache
the tree, but by making there be more levels in the tree then it will cost
more to research the tree from the top.  Again was just wanting to know the
worst case penalty.  Maybe you could add a short comment about in which
cases we will research the tree with the new scheme vs. the old scheme.

The test I was suggesting I think could be done with updatable cursor and
positioned updates, as long as the properties of the cursor are such that
each next goes to the database.   There are some cursor settings where
caching will happen in the client and nothing you do to the database after
each row fetch will get you into the btree research code that we are trying
to exercise.

> Index split deadlock
> --------------------
>                 Key: DERBY-2991
>                 URL: https://issues.apache.org/jira/browse/DERBY-2991
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,
>         Environment: Windows XP, Java 6
>            Reporter: Bogdan Calmac
>            Assignee: Knut Anders Hatlen
>         Attachments: d2991-preview-1a.diff, d2991-preview-1a.stat, d2991-preview-1b.diff,
d2991-preview-1b.stat, d2991-preview-1c.diff, d2991-preview-1c.stat, d2991-preview-1d.diff,
d2991-preview-1d.stat, derby.log, InsertSelectDeadlock.java, perftest.diff, Repro2991.java,
> After doing dome research on the mailing list, it appears that the index split deadlock
is a known behaviour, so I will start by describing the theoretical problem first and then
follow with the details of my test case.
> If you have concurrent select and insert transactions on the same table, the observed
locking behaviour is as follows:
>  - the select transaction acquires an S lock on the root block of the index and then
waits for an S lock on some uncommitted row of the insert transaction
>  - the insert transaction acquires X locks on the inserted records and if it needs to
do an index split creates a sub-transaction that tries to acquire an X lock on the root block
of the index
> In summary: INDEX LOCK followed by ROW LOCK + ROW LOCK followed by INDEX LOCK = deadlock
> In the case of my project this is an important issue (lack of concurrency after being
forced to use table level locking) and I would like to contribute to the project and fix this
issue (if possible). I was wondering if someone that knows the code can give me a few pointers
on the implications of this issue:
>  - Is this a limitation of the top-down algorithm used?
>  - Would fixing it require to use a bottom up algorithm for better concurrency (which
is certainly non trivial)?
>  - Trying to break the circular locking above, I would first question why does the select
transaction need to acquire (and hold) a lock on the root block of the index. Would it be
possible to ensure the consistency of the select without locking the index?
> -----
> The attached test (InsertSelectDeadlock.java) tries to simulate a typical data collection
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 derby log provides detail about the deadlock trace and stacktraces_during_deadlock.txt
shows that the inser thread is doing an index split.
> The test was run on and with identical behaviour.
> Thanks,
> Bogdan Calmac.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message