Subject Re: gds32.dll thread safety...still...again
Author Béru
> Can somebody please clarify the issue and address the issues
surrounding a
> fix? I was unable to find the bug listed in sourcforge. This
seems like a
> rather important isssue and solving (or at least fully describing
it) for a
> community that uses IB/FB extensively as well as a commercial
vendor who
> supports IB/FB as the ASTA folks do seems like it should be a high
> I will be happy to forward the ersponse to the ASTA folks.

Charlie Caro explained the problem a while ago on the mers list.
Here's the repost !

Berenger Enselme

I made the recommendation about the remote interface because I know
the local interface written for InterBase/Windows is locked for the
duration of a low-level InterBase API call. So if client thread 1
updates a row and client thread 2 attempts to update the same row in a
different transaction, client thread 2's alter ego thread in the
will block awaiting the COMMIT of client thread 1.

However, since the local interface in the client process is locked,
thread 1 can't communicate its COMMIT call or statement to the server.
Hence, the client application hangs.

Somewhere in the InterBase archives should be a related topic. A
developer was trying to execute non-blocking queries across multiple
threads in the client process. They noticed that the queries were
serialized such that short running queries had to wait for the first
from long running queries to be returned before they could proceed.

I gave the same advice then: Use the remote interface because it
lock itself awaiting the reply from low-level InterBase APIs. This
a significant difference in the interleaving of concurrent requests to
the server.

I'm not trying to imply that this will be a panacea for all of your
multithreading problems but it is a necessary condition. At some point
in the future, I would expect that limitation of the local interface
be addressed.