db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Clausen ...@statsbiblioteket.dk>
Subject Parsing lockTable dumps
Date Tue, 01 Nov 2005 13:19:31 GMT
Hi!

Delving further into our deadlock/lock timeout problems, I now have a
dump of the locks in question.  I think I understand what they're
saying, but my interpretation doesn't make as much sense as I'd like it
to.  The lockTable dump is as follows:

ERROR 40XL2: A lock could not be obtained within the time requested.  The lockTable dump is:

2005-11-01 12:14:33.516 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 ***
20965     |ROW          |X   |0        |(4,105)     |WAIT |T                    |NULL    
                                         |SEEDLISTS               |
*** The above row is the victim ***
20963     |ROW          |S   |1        |(12,6)      |GRANT|T                    |NULL    
                                         |CONFIGURATIONS          |
20965     |ROW          |X   |3        |(3,171)     |GRANT|T                    |NULL    
                                         |DOMAINS                 |
20963     |ROW          |S   |1        |(20,1)      |GRANT|T                    |SQL050923115052590
                               |CONFIGURATIONS          |
20963     |TABLE        |IS  |9        |Tablelock   |GRANT|T                    |NULL    
                                         |SEEDLISTS               |
20965     |TABLE        |IS  |1        |Tablelock   |GRANT|T                    |NULL    
                                         |SEEDLISTS               |
20965     |TABLE        |IX  |2        |Tablelock   |GRANT|T                    |NULL    
                                         |SEEDLISTS               |
20963     |ROW          |S   |9        |(4,105)     |GRANT|T                    |NULL    
                                         |SEEDLISTS               |
20965     |ROW          |S   |1        |(4,105)     |GRANT|T                    |NULL    
                                         |SEEDLISTS               |
20963     |ROW          |S   |1        |(10,1)      |GRANT|T                    |SQL050923115052500
                               |DOMAINS                 |
20965     |ROW          |S   |1        |(5,1)       |GRANT|T                    |SEEDLISTDOMAIN
                                   |SEEDLISTS               |
20963     |TABLE        |IS  |1        |Tablelock   |GRANT|T                    |NULL    
                                         |CONFIGURATIONS          |
20963     |ROW          |S   |1        |(5,67)      |GRANT|T                    |NULL    
                                         |DOMAINS                 |
20965     |TABLE        |IX  |2        |Tablelock   |GRANT|T                    |NULL    
                                         |DOMAINS                 |
20963     |TABLE        |IS  |1        |Tablelock   |GRANT|T                    |NULL    
                                         |DOMAINS                 |
20963     |TABLE        |IS  |1        |Tablelock   |GRANT|T                    |NULL    
                                         |HARVEST_CONFIGS         |
-------------------------------------------------------------------------------------------------------------------------------------------------------------

The interesting lock of course is on the SEEDLISTS table.  It appears to
me that the 20963 XID has a shared table lock while the 20965 XID has an
exclusive table lock.  That's the first thing that doesn't make sense --
doesn't seem like a very exclusive lock that.  Also, I would expect the
20965 XID to have no problems getting an additional lock on a SEEDLISTS
table row, since it already has a lock on the entire table.  Could
somebody explain these oddities to me?  

I've also been looking around for some docs on that the fields mean,
especially the lockname of which I suspect one part is the row number. 
The I part of the MODE field seems to correspond to it being a table
lock, is that all there is to it?

Thanks in advance,
-Lars


Mime
View raw message