Subject Re: [firebird-support] Deadlock
Author Ann W. Harrison
On 1/10/2011 2:53 AM, Milan Tomeš - Position wrote:
>
> I've run into problems with deadlocks.
> In my application I'm running multiple threads where every thread runs
> against different target database (but against same server). In that
> thread a single command is executed (update in this case) in a single
> transaction. Sometimes - totally randomly - command or server crashes
> with "deadlock" error and I'm really confused why this happen. If I
> restart that command against same database it finishes sometimes
> correctly and sometimes crashes again.
> Can anybody help me?

Probably, but it's going to take some effort on the part of several
people. With very high probability, you're running into an internal
server deadlock, which is not supposed to happen. The first thing
you'll need to provide is the exact text of the error message, and
if possible, some indication of what was happening on the system
when the error occurred.

User-data deadlocks occur when concurrent transactions attempt to
update or delete the same record. They are of two types. The first
is called an update conflict and is normally reported when one
transaction commits after updating or deleting a record that a
concurrent transactions has tried to update or delete. The second
is a classic deadlock: one transaction updates or deletes record
A then attempts to update or delete B; a second transaction updates
or deletes B then attempts to update or delete A. Firebird cannot
prevent user level deadlocks, but it does detect them and returns
errors that allow the application to break the deadlock. Since
every thread in your application runs on a different database, you
can't be updating the same record in several transactions.

System deadlocks occur when threads within the Firebird process
conflict on access to internal structures. In theory, Firebird's
design avoids or corrects those deadlocks automatically. In your
case, that appears not to work. The easiest solution might be to
use Classic mode, which will give you a process for each database.
That might be more efficient, in addition to not deadlocking. The
super classic version of 2.5 might also help.

However, if you can supply enough information to let the developers
find the problems you're seeing, they will be able to improve
Firebird for everyone.

Best regards,

Ann
>
> I'm running Firebird version 2.1.4.18308 x64 on server (64 bit Windows),
> application is 32 bit.
>