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