You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <ji...@apache.org> on 2011/03/14 15:16:29 UTC
[jira] Commented: (DERBY-3980) Conflicting select then update with
REPEATABLE_READ gives lock timeout instead of deadlock
[ 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