[
https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659315#action_12659315
]
Knut Anders Hatlen commented on DERBY-2991:
-------------------------------------------
In BTreeForwardScan.fetchRows() we have already fetched the key (or
parts of the key) before we save the position. So I experimented with
copying the key instead of re-reading the entire record. The copying
was performed by iterating over fetch_row and calling setValue() on
each element of scan_position.current_positionKey. This eliminated
much of the overhead. A rerun of the JUnit test with
derby.language.bulkFetchDefault=1 gave these results (average of 20
runs for each configuration):
TEST |TRUNK_TIME |PATCHED_TI&|INCREASE |INC_PERCENT
----------------------------------------------------------------------
decimal10columns |28427 |29727 |1300 |4.5731173
decimal1column |16572 |16890 |318 |1.9188993
varchar10 |14715 |15673 |958 |6.5103636
varchar100 |18378 |19472 |1094 |5.9527693
varchar1000 |47092 |51618 |4526 |9.610974
varcharAll |52457 |57628 |5171 |9.857598
This will of course only work if the entire key is fetched by the
scan. A proper solution would have to read the missing parts of the
key if only parts of it are used by the scan.
> Index split deadlock
> --------------------
>
> Key: DERBY-2991
> URL: https://issues.apache.org/jira/browse/DERBY-2991
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0, 10.3.1.4
> 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,
> stacktraces_during_deadlock.txt
>
>
> 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 10.2.2.0 and 10.3.1.4 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.
