| Subject | RE: [firebird-support] Firebird.log |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-09-02T13:53Z |
At 07:14 AM 2/09/2005 +0200, you wrote:
However, for the low-level locking that goes on in memory, you can do a lock print. Interpreting a lock print is a science unto itself. I doubt that I have ever encountered anything so abstruse! However, it's neither accessible to the API nor useful to anyone who doesn't understand it. Ann's introduction to it, from her paper at the first Firebird conference, is here: http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;PAGES;NAME='ibp_locking'
However, going back to *your* problem, if you see a DEADLOCK in the firebird.log, this is not the kind of deadlock that Mauro has helpfully explained to you. It has to do with the activities of the Lock Manager that maintains the states of data pages that are receiving writes. Mauro is talking about the kind of deadlock that can be caused by row-level conflicts having been incompletely handled by the client applications.
(Incidentally, not all "deadlock" messages from Firebird actually reflect deadlocks. Other, non-deadlocking conflicts also get reported at the top level as deadlocks.)
As Ann explained, the firebird.log is reporting an internal situation that should not have occurred. Hopefully, Ann will pick up the thread again tomorrow and try to make sense of it. I'm interested in it too, as I've never encountered a deadlock message in the log in all these years!
./heLen
>That's interesting. I firebird really killing the transactionNo, Firebird doesn't kill transactions at all.
>or will it wait infinite until the client will kill the connection?Ideally, it will wait until one client rolls back the transaction. In cases where you code up a situation where a true deadlock could occur, you must also protect that situation by correct treatment of the deadlock. When transactions are set to WAIT, it means you intend for them to wait until any conflicting transactions are rolled back. Therefore, in practical terms, you should be prepared to roll back a transaction to resolve such conflicts.
>Is it possible to wait only a few seconds and catch an error then?Only if you CODE for this behaviour in the client, by using NO WAIT transactions and allowing the application to retry in a timed loop until it succeeds. A conflict always has to be resolved.
>Is it possible to log which table is deadlocked?No, not for application use or access. And it is not tables that are deadlocked, but transactions.
However, for the low-level locking that goes on in memory, you can do a lock print. Interpreting a lock print is a science unto itself. I doubt that I have ever encountered anything so abstruse! However, it's neither accessible to the API nor useful to anyone who doesn't understand it. Ann's introduction to it, from her paper at the first Firebird conference, is here: http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;PAGES;NAME='ibp_locking'
However, going back to *your* problem, if you see a DEADLOCK in the firebird.log, this is not the kind of deadlock that Mauro has helpfully explained to you. It has to do with the activities of the Lock Manager that maintains the states of data pages that are receiving writes. Mauro is talking about the kind of deadlock that can be caused by row-level conflicts having been incompletely handled by the client applications.
(Incidentally, not all "deadlock" messages from Firebird actually reflect deadlocks. Other, non-deadlocking conflicts also get reported at the top level as deadlocks.)
As Ann explained, the firebird.log is reporting an internal situation that should not have occurred. Hopefully, Ann will pick up the thread again tomorrow and try to make sense of it. I'm interested in it too, as I've never encountered a deadlock message in the log in all these years!
./heLen