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 Fri, 12 Dec 2008 18:14:44 GMT

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

Mike Matrigali updated DERBY-3980:

i am wondering if the problem is that lock manager not beeing able to tell the difference
for the purpose of deadlock detection
the case of a waitor on a waitor because of live lock, and a waitor on a waitor because both
are blocked.  lockSkip may come into
it.   In this case I think lockSkip is getting set for both waitors, which properly means
it is ok for them to skip waitors as they already
hold a lock blocking waitors, but they can't get granted now.   

granted: T0(S), T1(S), T0(U)
waiting:  T1(U), T0(X)

I think at least in the lastest repro which does 2 deadlock scans something is going wrong
during 1st search which misses
the deadlock with respect to waiting on waitors case.  The problem comes when
we get to I think T0(X) which is marked waiting on a waitor.  For this we get to the "waiting
on a waitor" part of the deadlock search and
it does not push anything on the stack.  Seems like it should push whatever granted locks
are incompatible with it. It just changes 
the current search compatibility space to be the waitor space, which may be fine if it is
just waiting for waitors in front of it to get 
granted and there is not current incompatible lock.  

we need to make sure any fix does not start giving back false positives for livelock type
waits.  The test suite really has almost no
testing for dealock/livelock cases, probably should add some as part of this fix.  The problem
in the past has been depending on
timing it is sometimes hard to guarantee which waiting thread gets the deadlock in a system
independent way.  

> 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-3980_javadoc_and_test_diff.txt, derby.log, derby.log.10_1,
javacore.20081209.092827.9800.txt, TryTimeout.java, TryTimeout2.java, TryTimeout2.out.10_1.deadlock,
TryTimeout2.out.10_1.deadlock, TryTimeout2.out.10_1.locktimeout, 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