At 11:38 AM 8/09/2005 +0000, you wrote:

>Hello
>
>Every once in a while, I get an "deadlock deadlock Error Code: 16"
>error on updating in the database. I have been fiddling around with
>transaction options, but have not been able to eliminate this.
>Unfortunately, we cannot move to FB1.5 since we are using Redhat 7.
>
>OS: Redhat 7.3
>Firebird: FirebirdSS-1.0.3.972
>Compiler: Kylix 3
>Components: JvUIB 2.0
>Transaction options:
> coptReadOnly : TTransParams = [tpWait,tpRead,tpReadCommitted,
>tpRecVersion];
> coptReadWrite : TTransParams = [tpWait,tpWrite,tpReadCommitted,
>tpRecVersion];
>
>Can anybody give me a clue where to start looking?

Error code 16 is not a Firebird error. If it is the update conflict that
causes some "error code 16" that belongs to UIB, then you should find out
how to trap it, and handle it. Update conflicts are normal; real deadlocks
are avoidable. The SQLCode associated with the "Deadlock" message
encompasses a number of locking conflict types, each distinguished by its
own GDSCode and message detail.

However, you have not told us everything: for example, in your current
inquiry in the UIB forum, you said that you were running multiple database
threads sharing a single connection, and that the error was occurring
during an HTTP request. On Linux, error code 16 is an unspecific pppd
error. A pppd socket crash would be entirely consistent with that unsafe
practice. One thread, one connection is the golden rule. Alter your
architecture so that each thread creates its own connection (or picks up an
available connection from a pool, if connection pooling can be implemented
in UIB).

I think you should persevere with your inquiry in the UIB forum. The guy
who offered to help you, Henri Gourvest, is actually the developer of the
UIB components. Apparently the problem of threading across a connection
was unknown to him but someone had recommended a fix. Ten days ago Henri
offered you the patched version of his jvUib.pas unit to test. You should
ask him whether the effect of his modification is to block starting a new
thread on an existing connection.

You need to decide about the wisdom of putting http-initiated transactions
under WAIT policy, too. Web users have a habit of disappearing at
will. Maybe a user at the other end lost his Internet connection or simply
wandered away during an interminable WAIT, leaving an unresolved update
conflict. In any event, your web server layer should be written to take
responsibility for what a web client does (or does not do).

./heLen