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 Tue, 09 Dec 2008 18:39:44 GMT

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


Mime
View raw message