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.

----- Original Message ----
From: Adam <s3057043@...>
To: firebird-support@yahoogroups.com
Sent: Tuesday, September 30, 2008 6:49:08 PM
Subject: [firebird-support] Re: Commit Client Transaction - Monitoring Tables

> I am using D6 / IBX / FB 2.1 CS/ Windows Server 2003.  My

transaction params are [read_committed, rec_version, wait].  I have a
multi-threaded app which has a connection per thread.  I am
experiencing an issue where when I issue a "commit' on the
transaction, I get no response from the server.  When I look at the
properties of the connection through the monitoring tables, the
connection is marked as "idle".  When stepping through the code in the
debugger, I get to TIBTransaction. Committ and it does not step to the
next line of code.

TIBTransaction. Commit is part of IBX, not Firebird.

In order to commit, the server must receive a call on its API. That
call will come from the client library fbclient.dll (or gds32.dll in
your case). That dll will be wrapped by the connectivity layers. Until
you see your code leaving delphi and calling an exported method of
gds32.dll, I wouldn't be confident something isn't happenning inside IBX.

>Shouldn't the server be forcibly closing these connections after
>being idle for a certain time?

Certainly not. That would be really bad for anyone who makes use of
connection pooling.

idle <> disconnected

A connection may be abandoned (for example trip over power cord) but
the dbms does not know about it until the OS bothers to inform it. On
most OS, that timeout is about 2 hours.

But an 'idle' connection (available just not currently being used)
should remain indefinitely.

I am not knowledgable enough to help with your problem. I do see
however you are using Classic. Committing a transaction involves
locking the TIP on disk (so presumably some additional mutexes are
required to make sure two connections don't write the TIP at once and
cause a lost update). But I would be just guessing to draw any
conclusions about potential deadlocks from that alone.

Adam



[Non-text portions of this message have been removed]