|Subject||Re: gds32.dll thread safety...still...again|
> Can somebody please clarify the issue and address the issuessurrounding a
> fix? I was unable to find the bug listed in sourcforge. Thisseems like a
> rather important isssue and solving (or at least fully describingit) for a
> community that uses IB/FB extensively as well as a commercialvendor who
> supports IB/FB as the ASTA folks do seems like it should be a highpriority.
> 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 !
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
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