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-3980) Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
Date Tue, 16 Dec 2008 22:46:44 GMT

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

Knut Anders Hatlen commented on DERBY-3980:
-------------------------------------------

I understood Mike's comment as that we should make sure a livelock wasn't detected as a deadlock
(false positive) after we make the changes, which means we would have to run deadlock detection
on a possible livelock situation in order to test it. I have problems seeing how changes to
the deadlock detection algorithm could cause a regression in a test that doesn't exercise
that algorithm. But I agree that it's good to have this test too. Just shortening the deadlock
timeout or increasing the time the select threads hold the locks would additionally make it
test the deadlock detection algorithm, though.

> 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: Store
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
>            Reporter: Kathey Marsden
>         Attachments: derby-3980_javadoc_and_test_diff.txt, derby.log, derby.log.10_1,
javacore.20081209.092827.9800.txt, LiveLockTest_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
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message