db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6011) Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded tests
Date Wed, 12 Dec 2012 23:25:21 GMT

    [ 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

Mime
View raw message