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 19:58:44 GMT

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

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

The test looks OK to me. It tests what its class javadoc says (that the two readers don't
starve the writer). But wasn't the point actually to test that the deadlock detection doesn't
incorrectly report it as a deadlock? I'm not sure if deadlock detection will be performed
in this case. If I understand the description of the test correctly, the update thread will
be granted the exclusive lock after two seconds, but deadlock detection is not performed unless
it needs to wait more than five seconds.

Some minor nits:

* This code in selectWorker() doesn't do anything:

+            if (delay > 0)
+                ;

* The while loop in selectWorker() checks the exit condition twice, here

+            while (!isUpdateDone() && tries <= 10) {

and here

+                if (tries == 10)
+                    fail("Update did not occur after 10 selects");

The first check has no effect currently, and it should probably be removed so that one later
doesn't disable the last check by accident if one decides to change to some other number of
iterations and forgets to update one of the places.

> 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