Vlad Horsun wrote:

>> 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.
>>
>
> Exposing lock table info via virtual relation can be not a bad idea but
> i doubt it is easy to do.

You know better than me. :) As an outsider here, I see, for you, an
advantage to have a self-contained engine, not having the headache to
keeping in sync the writer (ie. the provider) and the reader. IMHO, this
can be achieved even if you have an per-engine lock table (which can be
stored in a file/memory) but of course you know much better how hard is
to do it. On the other side, for me (as an application coder) I have a
relation which I can filter (using WHERE for ex.) sort, Join in a
standard way, using the existing connection libraries. No more API
calls, no wait for upgrades, no more libraries in beta, no more tests
("it is work/it isn't?")

> And this info can't help you to resolve problem
> you wrote below
>
>
>> 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.
>>
>
> Deadlocks in lock manager and deadlocks you see in error messages
> are two very different things. The most common 'deadlock' message is
> isc_update_conflict : update conflicts with concurrent update
>
> where isc_update_conflict is secondary error code (primary is confusing
> isc_deadlock). Here we trying to update record which is already updated
> by another not committed transaction. This is not a deadlock in classical
> meaning. Of course lock table have no information about which transaction
> updated record before us. We can see this info only in record header and
> we can include it in error message. But what will you do with this transaction
> number ? And of course it is impossible to include such information into
> monitoring table.
>
>

Yes, AFAIS. Also, a 'deadlock' column (in the 'update conflicts with
concurrent update' manner) can be added in MON$TRANSACTIONS (available
in 2.1) wich will give us the entire transaction info, including the
ATTACHEMENT_ID (IIRC) and another JOIN with MON$ATTACHEMENTS (I cite now
from my bad memory - perhaps the monitoring tables aren't like this...)
will give us the full attachement info (for me, now, the most important
is the IP_ADDRESS in order to 'hunt' for the 'guilty' - ask what he did,
get out a stack trace from his workstation aso.). But also the above
mentioned JOIN path can be followed also for the internal deadlocks or
problems exposed by the lock table in order to mitigate the problem. For
example, now with fb_lock_print if I have a problem how can I find where
and who is the problem? I know that my question is quite general, but I
want to emphasize the fact that for us, common men, the fb_lock_print
output isn't quite readable. And 'selectable'. But if is hard to improve
it, doesn't matter. I rather prefer to have true SMP support in a week
if you can deliver it... :)

>> Anyway, the fb_lock_print doesn't work anymore on Win2003 via 'Remote
>> Desktop Connection'.
>>
>
> You wrong here. It will work when i'll fix it :)
>

I'm very happy that I'm wrong. :)

All best wishes,

m. th.

> Regards,
> Vlad
>
>