[
https://issues.apache.org/jira/browse/DERBY-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530482#comment-13530482
]
Knut Anders Hatlen commented on DERBY-6011:
-------------------------------------------
I tried the test with derby.stream.error.logSeverityLevel=0 to get more data in
derby.log. Then I saw many deadlocks of this kind:
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks and
waiters is:
Lock : ROW, JOBQUEUE, (1,37)
Waiting XID : {726, U} , APP, SELECT id,status,checktime FROM jobqueue WHERE
dochash=? AND jobid=? FOR UPDATE
Granted XID : {721, X}
Lock : ROW, JOBQUEUE, (1,38)
Waiting XID : {721, U} , APP, SELECT id,status,checktime FROM jobqueue WHERE
dochash=? AND jobid=? FOR UPDATE
Granted XID : {720, X}
Lock : ROW, JOBQUEUE, (1,37)
Waiting XID : {720, U} , APP, SELECT id,status,checktime FROM jobqueue WHERE
dochash=? AND jobid=? FOR UPDATE
. The selected victim is XID : 726.
So... Three transactions locking the same rows, but in different order, and end
up in a deadlock.
It varies how many transactions that are part of the deadlock, but it looks
like it's always the same query that's involved.
I haven't dug any further to see how the query is used yet.
> Derby performs very badly (seems to deadlock and timeout) in very simple
> multi-threaded tests
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-6011
> URL: https://issues.apache.org/jira/browse/DERBY-6011
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0
> Environment: Lenovo laptop with SSD's, Windows 7, 64-bit, Sun JDK
> 1.6.xx
> Reporter: Karl Wright
> Attachments: derby.log, manifoldcf.log
>
>
> The Apache ManifoldCF project supports Derby as one of its underlying
> databases. Simple tests, however, demonstrate that Derby is apparently
> deadlocking and timing out repeatedly under multi-thread conditions. This
> problem is long-standing, and is not exhibited by any other database
> ManifoldCF supports, and makes a simple test take between 6x and 12x as long.
> There is a trivial test with demonstrates the problem vs. other databases.
> Please do the following (once you have java 1.6+, svn 1.7+, and ant 1.7+
> available):
> (1) Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
> (2) Run the following ant target to download the dependencies: "ant
> make-core-deps"
> (3) Run the Derby test: "ant run-rss-tests-derby" . Note the time required -
> at least 180 seconds, can be up to 360 seconds.
> (4) Run the equivalent HSQLDB test: "ant run-rss-tests-HSQLDB". This test
> takes about 31 seconds to run.
> The output of the Derby test can be found in the directory
> "tests/rss/test-derby-output". Have a look at manifoldcf.log, where all
> long-running queries are reported. Derby.log is also included, which shows
> only that during the test's cleanup phase the database is deleted before it
> is shutdown, which is not pertinent to the performance issue.
> I am available to assist with ManifoldCF, if that seems to be required.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
