Patrick J. P. Griffin wrote:

>I'm confused. I thought I understood gds_lock_print output - until today.

I'm impressed.

>(I run Firebird AIX Classic 6.0.9.1)
>Today I encountered a large number of users that appear to be waiting on
>just one lock.

Usually that's a signalling problem - which I don't see from this lock
print.

>I started with:
>
>LOCK BLOCK 31216
> Series: 3, Parent: 14760, State: 3, size: 4 length: 4 data: 0

The interesting bits here are that it's a series 3, meaning it's a bdb
(buffer descriptor block, aka one page in the cache) and that its state is
3, meaning that it thinks someone has the lock in shared read mode.

> Key: 009294, Flags: 0x00, Pending request count: 16

The key is, as you know, the page number of the page in the cache,
probably a data page or an index page. You won't find either of
those page types in the RDB$PAGES - relation, just the pointer
pages (data) and index root pages for each table. It could also
be a pip page... Unlikely though, as so may transactions want it
for read.

> Hash que (11): forward: 1194376, backward: 2172

This stuff is interesting when looking at a broken lock table - not
here.

> Requests (16): forward: 607596, backward: 1667408
> Request 607596, Owner: 901460, State: 0 (6), Flags: 0x82
> Request 1185088, Owner: 1083572, State: 0 (3), Flags: 0x02
> Request 1400316, Owner: 405448, State: 0 (3), Flags: 0x02
> Request 1711920, Owner: 1166816, State: 0 (3), Flags: 0x02
> Request 1489908, Owner: 1213756, State: 0 (3), Flags: 0x02
> Request 593600, Owner: 330128, State: 0 (3), Flags: 0x02
> Request 185740, Owner: 734556, State: 0 (3), Flags: 0x02
> Request 629548, Owner: 497384, State: 0 (3), Flags: 0x02
> Request 125812, Owner: 620516, State: 0 (3), Flags: 0x02
> Request 1701860, Owner: 1316988, State: 0 (3), Flags: 0x02
> Request 472716, Owner: 14636, State: 0 (3), Flags: 0x02
> Request 1544416, Owner: 575276, State: 0 (3), Flags: 0x02
> Request 808704, Owner: 153208, State: 0 (3), Flags: 0x02
> Request 682684, Owner: 396828, State: 0 (3), Flags: 0x02
> Request 1230752, Owner: 198832, State: 0 (3), Flags: 0x02
> Request 1667408, Owner: 1195636, State: 0 (3), Flags: 0x82
>
>
>And can't understand why none of these requests get satisfied?

The state (0) means that the lock has not been granted. The number
in parenthesis is the type of lock requested. The first request in
queue wants a write lock which is inconsistent with the state the lock
considers itself to be in (3, shared read). The x02 flag indicates that
the request is pending. The x82 flag indicates that the request is
pending and that the request has been through a deadlock scan....

>Lock block 14760 is a series 1 database lock.

The big momma of locks.

>The lock header did not show any deadlocks, but since they were the subjects
>of a deadlock scan, I examined:
>
>OWNER BLOCK 901460
> Owner id: 86546, type: 3, flags: 0x02, pending: 607596,
> semid: 156
> Process id: 86546, UID: 0xC8 Alive
> Flags: 0x02 scan
> Requests (85): forward: 1465280, backward: 607596
> Blocks: *empty*
>
>....
>And couldn't find any evidence that these tasks were not responding.

Your owners haven't been signaled, so the lock block thinks it still
has a granted lock in shared read mode. What does the history look like?

>Anyone have any suggestions where I should look? (I've saved copies of the
>output from gds_lock_print, semdisp, ps -ef, and ps aux so that I can
>continue to hunt.)

Are your various owners in different groups?

Very strange indeed.


Regards,

Ann
www.ibphoenix.com
We have answers.