db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3980) Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
Date Thu, 11 Dec 2008 20:22:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-3980:

> 1) Why did we not detect the deadlock when Thread0 did Deadlock.look()? The locks were
the same at that point.
To me this looks like another instance of the bug.  Either thread searching should find the
deadlock once they have both gone 
into waiting, which I believe is the case here.  I believe knut's comment on canSkip may be
relevant.  I still don't understand the
code using skip.  

> 3) Should the order of the LockControl objects matter? 
If things are working right deadlock detection should find it no matter what, the order though
might change which one is picked as victim.

> 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:,,,,
>            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.

View raw message