Subject | Re: [firebird-support] Deadlock |
---|---|
Author | Helen Borrie |
Post date | 2006-02-10T12:03:25Z |
At 09:08 PM 10/02/2006, you wrote:
conflict. Avoid it? NOT! This is multi-user concurrency at
work. What you do is catch the exception and try again (if
appropriate) or roll back and send your user a friendly message, e.g.
"Another user is already updating this record" or "Another user
posted changes that make your changes invalid".
Ah - yes - all lock conflicts bubble up and are reported as deadlocks
at the higher (SQLCode) level. It's important for you to respond
correctly to the lower-level exception (the one described in the
detailed message and identified by the GDSCode/isccode, which IBX
terms an "IB Error number").
Genuine deadlocks are rare and, to a large extent, avoidable. One
party (transaction) in a genuine deadlock must relinquish by rolling
back. How your application responds to other types of locking
exceptions depends on how the transaction is configured (isolation
level, lock wait strategy, and, for read committed isolation, the
record version policy.) It may be appropriate to roll back and try
again in a new transaction, anyway; or it may be sufficient just to
put your Post code into a timer loop until your transaction is able
to get the lock and succeed.
./hb
>Hi,First, this is not a deadlock, it's a lock (record version)
>
>I'm using Firebird-1.5.2.4731 an IBX 7.08 drivers in a Delphi application.
>
>Occasionally I get a deadlock situation with the following message:
>
>Lock conflict on no wait transaction. Deadlock. Update conflicts
>with concurrent update.
>SQL Code: -901
>IB Error Number: 33 55 44 345
>
>What is causing it and how do I avoid it?
conflict. Avoid it? NOT! This is multi-user concurrency at
work. What you do is catch the exception and try again (if
appropriate) or roll back and send your user a friendly message, e.g.
"Another user is already updating this record" or "Another user
posted changes that make your changes invalid".
Ah - yes - all lock conflicts bubble up and are reported as deadlocks
at the higher (SQLCode) level. It's important for you to respond
correctly to the lower-level exception (the one described in the
detailed message and identified by the GDSCode/isccode, which IBX
terms an "IB Error number").
Genuine deadlocks are rare and, to a large extent, avoidable. One
party (transaction) in a genuine deadlock must relinquish by rolling
back. How your application responds to other types of locking
exceptions depends on how the transaction is configured (isolation
level, lock wait strategy, and, for read committed isolation, the
record version policy.) It may be appropriate to roll back and try
again in a new transaction, anyway; or it may be sufficient just to
put your Post code into a timer loop until your transaction is able
to get the lock and succeed.
./hb