[
https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3980:
----------------------------------
I don't have answers, but more questions. It looks like there are also timing
bugs going on. It might help if the program dumped more timing information
along with print outs.
For the timeout case, ignoring that it should be a deadlock, it seems like we
should see a timeout after 60 seconds for Thread0 and then a timeout for
Thread1 after 70 seconds, but it looks like they both timeout at the same time.
> 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.log, derby.log.10_1,
> javacore.20081209.092827.9800.txt, TryTimeout.java, TryTimeout2.java,
> TryTimeout2.out.10_1.deadlock, 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.
