Adriano dos Santos Fernandes wrote:

> Vlad Horsun wrote:
>
>> 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 ?
>>
> Actually, I do this yesterday!
> I.e., it returns "update conflicts with concurrent update in transaction
> %d".
>
> With the transaction number and the MON$ tables, an admin could know the
> connection which is blocking the record.
>
>
> Adriano

1. Transaction %d is the transaction which holds the resource or "our"
transaction? IMHO, is better to write both numbers in the message...
2. What if you have more than two transactions in a deadlock IOW
"deadly-embrace"?

my 2c,

m. th.