db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Parsing lockTable dumps
Date Tue, 01 Nov 2005 14:36:23 GMT
Lars Clausen <lc@statsbiblioteket.dk> writes:

> 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?  

You have misinterpreted IS and IX locks. These are intentional locks,
which means that the transaction intends to lock rows in that
table. For example, if a transaction wants an exclusive lock on row R1
in table T1, it will lock table T1 with intent exclusive (IX) and row
R1 in exclusive mode (X). This prevents others from locking the entire
table or that particular row, but not from locking other rows in the
table.

> 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

-- 
Knut Anders


Mime
View raw message