> 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

priority.

> 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
that
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
server
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
row
from long running queries to be returned before they could proceed.

I gave the same advice then: Use the remote interface because it
doesn't
lock itself awaiting the reply from low-level InterBase APIs. This
makes
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
to
be addressed.

Regards,
Charlie