= m. Th = wrote:

>
> As much as we test the app in lab
> we cannot prevent all the deadlock situation which can arise in a real
> world LAN with many more users, so our 'lab' is extended using as
> 'beta-testers' the users from the entire LAN. One (or some) of them
> tells me that's a problem with his communication client. I run my app
> and I see from the debugger that, in deed, there is a deadlock when
> issuing a DELETE FROM USERS WHERE ...

What you're seeing is probably not a deadlock in the classic sense -
two (or more) lock requests that create a cycle in the lock request
graph - but one transaction which has an uncommitted change that
blocks others which has either died or gone out for coffee. A solution
to the case where the client has died is found in the configuration
file...

#
# Normally, Firebird uses SO_KEEPALIVE socket option to keep track of
# active connections. If you do not like default 2-hour keepalive timeout
# then adjust your server OS settings appropriately. On UNIX-like OS's,
# modify contents of /proc/sys/net/ipv4/tcp_keepalive_*. On Windows,
# follow instrutions of this article:
# http://support.microsoft.com/default.aspx?kbid=140325

The solution to going out for coffee, lunch, vacation, or a life is
to put a timer in the application that rolls back transaction that
have shown no activity for some period of time.

The classic deadlock actually returns an error code to the calling
application which should be caught and handled by rolling back the
transaction. When all transactions that got deadlock errors have
rolled back, the deadlock is gone.


Regards,


Ann