Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 14 Mar 2011 14:06:30 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <51793769.688.1300111590069.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (DERBY-3980) Conflicting select then update with
 REPEATABLE_READ gives lock timeout instead of deadlock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-3980:
--------------------------------------

    Attachment: derby-3980-1a.diff

Attaching a patch for this issue. It's essentially the same patch as the 1b patch attached to DERBY-5073, only that the code has been re-indented to account for the extra nesting level added in that patch.

The patch also adds a regression test with a test case both for this issue and for DERBY-5073. The test cases fail with a lock timeout without the fix and pass (get the expected deadlock exception) with the fix.

I'm running the regression test suites on the patch now and intend to commit it to trunk if the tests pass.

> Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
> ------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3980
>                 URL: https://issues.apache.org/jira/browse/DERBY-3980
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1
>            Reporter: Kathey Marsden
>            Assignee: Knut Anders Hatlen
>              Labels: derby_triage10_5_2
>         Attachments: LiveLockTest_diff.txt, LiveLockTest_with_Deadlock_look_diff.txt, LockTimeoutWithInserts.java, TryTimeout.java, TryTimeout2.java, TryTimeout2.out.10_1.deadlock, TryTimeout2.out.10_1.deadlock, TryTimeout2.out.10_1.locktimeout, TryTimeout2.out.10_1.locktimeout, derby-3980-1a.diff, derby-3980_javadoc_and_test_diff.txt, derby.log, derby.log.10_1, javacore.20081209.092827.9800.txt
>
>
> The attached program TryTimeout.java should detect a deadlock but instead throws a lock timeout exception.  The program has two threads that attempt:
> 	    
> 	    threadConnection.setAutoCommit(false);
> 	    /* set isolation level to repeatable read */
> 	    threadConnection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
> 	    
> 	    ResultSet rs = stmt.executeQuery("select * from t where i = 456");
> 	    while (rs.next());
> 	    stmt.executeUpdate("update t set i = 456 where i = 456");
> 	    threadConnection.commit();
> This gives SQLState 40001 (deadlock) with DB2 but a lock timeout with Derby.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira