Morning Milan,

>> I'm having troubles with deadlocks in very strange behaviour.

I hate to say this, but almost always deadlocks are caused by the
application. I see this all the time in my line of work. All databases
will deadlock if the application gets it wrong. :-(

>> Situation - one or more connections to a database, one
>> running update query per connection (long term query - more than

hour) but

>> every query use some records which another query doesn't.

Transactions

>> are set to wait, but I don't think this is a problem.

Waiting transactions *are* a problem. If the transaction is set to not
wait, it will raise an exception if the resources it needs to lock are
currently locked. They will wait forever for the resource it needs and
if "this" transaction holds resources that "that" transaction needs, and
vice versa, then both will wait "forever".

Have you tried setting the transactions to wait for a limited time?

>> There is a firebird.log entry that says database name and "deadlock"
>> message, but application freeze.

Well, if you have the application in a deadlock state, it will most
likely freeze. Those waiting transactions will wait forever. (Subject to
any engine handling of deadlocks of course!)

>> Any idea what to do to avoid this?

NO WAIT or WAIT n transactions. Then check the application logic for
resource acquisition. A "rule" used to be get everything in alphabetic
order and if everything does this, then deadlock possibilities are
reduced.

So session 1 gets tables a, b, c and when session 2 tries to get a, it
finds it locked. Had session 2 already locked C, then there would be a
deadlock.

Other advice, commit "frequently" - however, it has to be done where
appropriate. Don't just commit for the sake of it. The transaction has
to work fully or not at all. I've seen too many (oracle) programs which
commit in a loop to "avoid holding locks" - hopeless and a right
nightmare when it all falls over - with half completed, but committed,
transactions.

Up the frequency of the DeadlockTimeout scanner in firebird.conf *might*
help detect them, but can also reduce efficiency of the database. The
default is 10 seconds.

However, when a deadlock is detected by the engine, it picks one of the
two transactions and sends it a deadlock exception. It is up to the
application to trap that and handle it appropriately - rolling back and
trying the transaction again perhaps.

I'm sure there are other methods of deadlock prevention, but I've not
had enough coffee yet! Part 6 of Helen's Firebird Book has a good
write-up on deadlocks, livelocks and deadly embraces. Plus, a note in
Chapter 40 page 858, to the effect that the lock manager may report as
deadlocks, things that are not quite deadlocks.

Good hunting!


Cheers,
Norm. (At work!)

Norman Dunbar
Contract Senior Oracle DBA
Capgemini Database Team (EA)
Internal : 7 28 2051
External : 0113 231 2051


Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk