--- In ib-support@y..., "Woody" <woody.tmw@i...> wrote:

> Hi all. I try to help as many people as I can even though I'm

relatively new to IB (about 4 months now). I am still trying to
understand all of the aspects of a deadlock situation. One recurring
problem I have is that a client occasionally (maybe once every other
week) starts getting a deadlock error trying to update a record. It
doesn't always occur on the same table or data. No other user is
editing the same record nor even sitting on the record. It appears
that it's just a hung transaction or something like it. Could anyone
explain what types of situations can cause a transaction not to be
automatically commit/rollback-ed if a user looses connection or
something like it. My understanding is that IB rolls back any
transactions if a user gets disconnected abruptly and IB can no longer
"see" the user. Is that right and are there any particular situations
to look for that can cause this type of deadlock?

Hi, Woody. Deadlock (BTW, my opinion is that usage of this word as
synonym for lock conflict is'nt fully correct) occures when two or
more transactions tries to change one record. It is'nt "editing the
same record nor even sitting on the record". Interval between updates
is not limited. One user could edit this record hour ago and another
will have lock conflict now if:
1. Transaction within which first update was made is not commited or
rolled back (read_commited mode for second transaction).
2. Transaction within which second update is made have concurrency
mode and was started before first transaction was commited or rolled
back.
There are more exotic cases with no_rec_version and consistensy but
this modes are specific and seldom used.
So most likely you should check once more your application to find
long-live transactions within which changes are made.
One more possibility: if you use triggers to update records in
another tables (stored aggregates and so on), you can have "hidden"
from application's interface logic lock conflicts.
If client machine looses connection to server and at this moment on
server was not activity within this connection (long running query and
so on) server process (CS) or thread (SS) should die within
connection_timeot parameter in isc_config (ibconfig on Windows) file.
If such activity is present, it should finish job before feel loss of
conection.
Last possibility is corrupted database or some IB bug. First can be
easy checked and I know only 2 occurances of such kind of corruption
within 6 years work with IB and both not on my databases. Second is
nearly impossible I think, but 1e-..................... possibilty
always present. :)

Best regards.