[
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
