Subject Re: Deadlock errors (FirebirdSS-
Author Diederik Wierenga
--- In, Helen Borrie <helebor@t...>
> Error code 16 is not a Firebird error. If it is the update conflict
> 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
> 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.

Yes, I know that Deadlocks should be avoidable and I am persevering
this. However, if I set the options according to the firebird
documentation, I still get the error above.

With regards to the error code, I am pretty sure that it came from
firebird, but I will look at that later next week.

> However, you have not told us everything: for example, in your
> inquiry in the UIB forum, you said that you were running multiple
> threads sharing a single connection, and that the error was
> during an HTTP request. On Linux, error code 16 is an unspecific
> error. A pppd socket crash would be entirely consistent with that
> practice. One thread, one connection is the golden rule.

With regards to this, what is the validity of the comments in the
release docs of 1.0:

SFID 446227.- On Linux, client library is not thread-safe.
A threadable was included in release 1.0 but the thread-
safety issues are not resolved.

Is it really save to open multiple connections simultaneaously?

>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
> in UIB).

I tried connection pooling (build my own) only to experience more
problems. I am not sure whether this a UIB problem or not so I am
looking at this later.

> 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
> was unknown to him but someone had recommended a fix. Ten days ago
> offered you the patched version of his jvUib.pas unit to test. You
> ask him whether the effect of his modification is to block starting
a new
> thread on an existing connection.

I requested the fix, but have yet to receive the file. I will take
this up with Henri.

> You need to decide about the wisdom of putting http-initiated
> 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
> wandered away during an interminable WAIT, leaving an unresolved
> conflict. In any event, your web server layer should be written to
> responsibility for what a web client does (or does not do).

Strictly speaking, the connections are XMLRPC based and coming from
our own applications. We are addressing the HTTP issues, but the
general feeling is still that this is a viable road.

I will be out of office for a few days, but will certainly come back
to this thread.