Subject Re: Deadlocks in test application
Author Fabiano
Hi again,

After some searching, i found out that when a concurrent update happens in the same record in Firebird, the second transaction default behaviour is to wait for the first transaction to commit and then to raise a deadlock exception.

Is this information correct?

Supposing it is correct (what explains the deadlocks happening in the test), what is the recommended procedure to follow to prevent (or to deal with) deadlocks?