Thank you Anne,

I commit and start transaction as often as practical.

Certainly there are no large looping processes that are contained within a single transaction.

The majority of my processes are essentially inserts and updates, deletes are rare; it would be the updates causing the issue.

Some stored procedures and triggers are relatively complex in posting before and after update values to multiple tables.

Shifting processing logic from programs to the database obviously comes at a price.

Stephen

----- Original Message -----
From: Ann W. Harrison
To: firebird-support@yahoogroups.com
Sent: Saturday, November 18, 2006 4:12 AM
Subject: Re: [firebird-support] Deadlock Simplified


Stephen Davey wrote:

> Is there a quick and simple solution to deadlocks ?

Well, Here are some less than practical suggestions...

Single user applications never deadlock.

Multi-user applications never deadlock unless they
update or delete records.

Multi-user applications that do updates and deletes
won't deadlock if the updates and delete transactions
are serialized with something like a mutex that
allows only one to be active at any one time.

More practically, keep transactions that do updates and
deletes as short as possible, remembering that updates
and deletes done by triggers also count.

> Is the classic server less likely than superserver to encounter issues ?

No. Deadlocks are created by application logic and aren't (in theory)
produced by the server.

Regards,

Ann




[Non-text portions of this message have been removed]