[
https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662951#action_12662951
]
Knut Anders Hatlen commented on DERBY-2991:
-------------------------------------------
Had the tests with bulk-fetch disabled running over the weekend (200
times with a clean trunk, 200 times patched). Now I used a standalone
test which did the same as the JUnit test (except from some adjusting
of the number of iterations to get the time more evenly distributed
between the test cases, and the size of the test table was increased
from 1000 rows to 10000 rows), and I randomized the order of the
tests. Now the test results look much more reasonable.
The test case with a key consisting of ten DECIMAL columns shows the
worst performance, with a 1.9% increase in the time spent. The test
cases with VARCHAR(10) and VARCHAR(100) showed 1.6% and 0.9% increase
in time spent, respectively. The other test cases basically showed the
same performance for clean jars and patched jars. The table below
shows the average numbers (times in milliseconds) for the test runs.
NAME |TRUNK_TIME |PATCHED_TI&|INCREASE |INC_PERCENT
--------------------------------------------------------------------------
Decimal10Columns |81495 |83025 |1530 |1.8774158
DecimalSingleColumn |63722 |63769 |47 |0.07375789
Varchar0010 |54268 |55145 |877 |1.6160537
Varchar0100 |70907 |71576 |669 |0.9434894
Varchar1000 |87431 |87457 |26 |0.029737735
VarcharAll |97197 |96845 |-352 |-0.3621511
Now that I've got test results that I understand, I'll go on and add
the test cases Mike suggested. If we don't find any common code path
that's slowed down more than what the latest test run showed, I would
be inclined to say the overhead is acceptable, given that it fixes a
serious issue and that other common code paths are actually getting
better performance, and investigation on how to reduce the overhead
further could be postponed until later. But let me first see how the
other suggested test cases are affected.
> 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.
