Hi Ann,

> Unless you're using NO_WAIT transactions, the transaction that got
> a deadlock can retry immediately. The error isn't returned until
> the previous transaction is finished. If you've got three or four
> transactions running simultaneously, some transactions may get
> several deadlocks in a row, but eventually they should get in. If
> the successful transaction goes on to store a record in another
> table, you should get pretty good distribution.

You're right. If I do not call a sleep after a deadlock and retry
immediate then I get quite a good distribution. Though I had to
increase the max attempt count. 30 wasn't enough [ firebird is too
fast ;-) ]. I tried with 300 instead and right now 6 clients
simultaneously generate counter values quite successfull for several
minutes now.
Oops, though in the very moment I got deadlocks again :-(
And again a bit strange: there is not only ONE deadlock but FOUR of my
clients got deadlocks almost at the same time.
Maybe it's just that firebird was busy at that moment? But two of the
clients are still running!?

But anyway: what I still don't like is that my clients have to be
really busy while waiting to get an exclusive lock. Isn't there a way
to get a server side queueing and wait mechanism for getting exclusive
access to a table row? That's why I asked for something like
"SELECT ... FOR UPDATE WITH LOCK" (and wait for it) in a previous post.

--Heiko