[
https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662370#action_12662370
]
Knut Anders Hatlen commented on DERBY-2991:
-------------------------------------------
There must be something wrong with the test results I posted on
27/Dec/08.
First of all, they don't really make any sense. Why should the
overhead of saving the position be greater for VARCHAR(1000) than for
VARCHAR(10)? Since the String object that we generate when we copy the
key is shared between the source DVD and the target DVD, and the
source DVD saves the same amount of work when it later needs to return
the String to the user, the overhead per row should be proportional to
the number of columns in the key, not to the size of the columns in
the key. And since reading longer values is more expensive than
reading shorter values, the relative overhead should be smaller rather
than greater for VARCHAR(1000).
Secondly, I see the exact same results when I compare a clean trunk
with another clean trunk. For some reason, the runs (1, 3, 5, ...)
consistently show significantly better performance than the runs (2,
4, 6, ...). But it turns out that if I remove the database directory
between each run, I get much more stable results. I've got no idea why
this happens. Perhaps something CleanDatabaseTestSetup or some other
part of the test framework does?
Anyway, no matter what's causing it, I'll need to rerun the tests and
let each test run create its own database. It's probably also a good
idea to randomize the order of the test to eliminate interference from
periodic/alternating factors. In the previous test runs, I ran clean,
patched, clean, patched, and so on, so that all the bad runs were with
patched jars and all the good runs were with clean jars. Perhaps I'll
also write a simple standalone test, so that we don't need to worry
about what happens in the test framework.
> 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.
