[
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.
