--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

>
> 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.

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

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.

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

SFID 446227.- On Linux, gdslib.so client library is not thread-safe.
A threadable gdslib.so 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

implemented

> 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

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.
>

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

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

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.

Thanks,

Diederik