[
https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3980:
----------------------------------
Looking at the error log there are a few wierd things:
1) I would expect to see 2 waiting locks.
2) Given that it should be repeatable read, and there is no index I would
expect the lock list to contain row locks for
every row in the table. Maybe it would useful to dump the lock table
after the select using the lock vti just to see if
it matches. Maybe this will lead to whether the issue is the actual lock
table, or just some issue with contruction the
error message. (1, 9) is likely the row in question. The other rows are
likely (1, 6), (1,7), and (1,8). The id's before
6 are reserved for special use so real rows start at 6 and increase.
3) Just to be complete it would be good to verify that both threads are in a
wait state in the lock, I would just dump the
stacks using signal or cntrl key depending on jvm while it is stalled. I
looked at program and can't imagine anything else
going on.
4) Anyone who wants to look at this one, the code is pretty isolated. The
interesting code is in
opensource/java/engine/org/apache/derby/impl/services/locks/LockSet.java
5) some debugging steps I would take would include:
o verify if a deadlock search is being made or not?
o run in sane mode and turn on the SanityManager.DEBUG_ON("DeadlockTrace")
flag.
o If a deadlock search is being made, use the sanity code to dump out the
lock table when the deadlock search is done and
misses the deadlock.
o see if the bug still happens if there is only 1 row in the table.
ERROR 40XL2: A lock could not be obtained within the time requested. The
lockTable dump is:
2008-12-09 00:50:40.640 GMT
XID |TYPE |MODE|LOCKCOUNT|LOCKNAME
|STATE|TABLETYPE / LOCKOBJ
|INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
186 |ROW |U |0 |(1,9)
|WAIT |T
|NULL |T
|
*** The above row is the victim ***
184 |ROW |S |1 |(1,9)
|GRANT|T
|NULL |T
|
186 |ROW |S |1 |(1,9)
|GRANT|T
|NULL |T
|
184 |ROW |U |1 |(1,9)
|GRANT|T
|NULL |T
|
184 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
186 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
184 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
186 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 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
>
>
> 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.
