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

>
> At 11:07 1/10/2008, you wrote:
> >Thanks for taking a crack at it. I actually have stepped through

the IBX code to the point where it calls the following method from the
client library

> >
> >isc_commit_transaction
> >
> >This is where the trail ends and does not step to the next line of

code.

>
> You are using WAIT transactions in your threads, which is a hang-up

waiting to happen. Your COMMIT calls only *request* a commit. They
won't return until waiting transactions are able to either commit or
throw lock conflicts. You're only getting what you asked for...you
really need to assess what benefit you're getting from running WAIT
transactions in user-initiated threads.

---

Helen,

I was on the understanding that a lock conflict was a conflict between
two statements attempting to modify a single record, something only
possible during an update or delete (or by indirectly causing an
update or delete inside a stored procedure or trigger).

I can't otherwise imagine why a commit would ever be waiting, unless
the OP is using a TRANSACTION COMMIT trigger that is attempting to
perform an update or delete (either directly or indirectly via
triggers or stored procedures). In this case, the reported scenario
makes perfect sense, the transaction has a lock conflict to contend
with and the OP has asked it to wait for the other transaction to
commit or rollback first.

(But I otherwise agree that WAIT is probably not the best choice in
many cases where it is used)

Adam