Dmitry Yemanov wrote:

> Arno Brinkman wrote:
>
>> LockFile can be set in configuration and fb_lock_print use that one too.
>> Also the lock-filename can be passed with fb_lock_print, so i don't see problems here?
>>
>
> A single fb_lock_print executable cannot handle different versions of
> the lock tables. Would you suggest to name it fb_lock_print10,
> fb_lock_print11 etc and deliver along with the appropriate engine providers?
>
>
> Dmitry

Sorry for jumping in, but, as always not knowing your code, perhaps I
can give another way to see the things. You'll decide if is something
useful here...

Perhaps you can do a lock table for each database and embed this
somewhere in the db file and/or in a shared memory zone (recommended,
for speed). In this way, the issues raised at the beginning of the
thread will be solved. The lock table info will be extracted via SQL
from a (virtual) MON$LOCKS table (so each engine is responsible for
exposing this). This is a feature which will be very useful for us in
finding problems on server. When I have a deadlock (the most encountered
problem), personally, I want to know who is implied in the deadlock and
the fb_lock_print is already very cluttered for this simple task.
Anyway, the fb_lock_print doesn't work anymore on Win2003 via 'Remote
Desktop Connection'. Why not simply drop it? IMHO, is simpler to
maintain the Fb without fb_lock_print. The drawback, I presume, is,
IMHO, the amount of code which must be written in the engine for this.
But after that, perhaps it will be a superior architecture.

------------------------------------
...For conformity, after finishing my message I had a look at PostgreSQL
8.2 (just released - highly recommended for a look!) and the have a
similar approach with the pg_locks system table. (Open pgAdmin III -
Help search for "Lock, monitoring" - interesting text for the way in
which this sys view works)

hth,

m. th.

PS: As an aside, Dmitry, I have a quick look at
http://firebird.cvs.sourceforge.net/firebird/firebird2/doc/README.monitoring_tables?revision=1.1&view=markup
and I saw that in MON$TRANSACTIONS perhaps, if it's possible, you can
add a field which can show us if the Transaction is in a deadlock with
another one. IMHO, it will be a _very_ useful debugging tool. (more to
come on monitoring tables, but I thought that this is related to our
theme...)