db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (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 18:07:44 GMT

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

Kathey Marsden updated DERBY-3980:

    Attachment: TryTimeout2.out.10_1.locktimeout

I did the runs with some additional  println's.  
1) Upon entering Deadlock.look, I print:
System.out.println(Thread.currentThread().getName() + " Deadlock look");
2) Upon entering the block of code Knut mentioned I print  
   if (lock.canSkip) {
                System.out.println("rollback(chain). Not a deadlock");

Here is the output of the run with deadlock TryTimeout2.out.10_1.deadlock and the run with
timeout TryTimeout2.out.10_1.locktimeout.

In both cases it first does a Deadlock.look for Thread0 which does not detect any deadlocks.

On the Deadlock.look for Thread1  we see it pass through the "Not a deadlock" line for the
deadlock case, not the lock timeout case, which is the reverse of what I would expect if that
code were the problem.

What I do notice is that always when we deadlock the lock[0] and lock[1]  of the Thread1 LockControl
objects are in the reverse order from the timeout run.  Perhaps there is some problem in the
logic when they are ordered in this way.

A few general things I don't understand. Sorry for my newbieness.

1) Why did we not detect the deadlock when Thread0 did Deadlock.look()?  The locks were the
same at that point.

2) Why in the timeout case do we do a second Deadlock.look on Thread0?

3) Should the order of the LockControl objects matter?

4) Could someone give me a high level description of the arguments to Deadlock.look()
static Object[] look(SinglePool factory, LockSet set, LockControl control, ActiveLock startingLock,
byte deadlockWake) {
There is no javadoc.  I would be happy to add some if someone could post the information here.

> 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