db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3980) Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
Date Mon, 14 Mar 2011 14:16:29 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006419#comment-13006419
] 

Bryan Pendleton commented on DERBY-3980:
----------------------------------------

Wow! Now that's a test case! :)

Seriously, though, the new tests look excellent; they're commented very
well, and the code is clearly written. There's no easy way to write deadlock
test cases; your effort here should lead the way and make it easier for
people to write additional deadlock test cases in the future. Thanks very
much for taking the time to do so.

It's too bad we can't set the deadlock timeout to less than a second. Nowadays,
that's an eternity on a modern computer.



> 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

Mime
View raw message