At 02:24 PM 18/12/2005 +0100, you wrote:

>Suppose the network is good, I start my ACTION (connect to FB server,
>start a transaction, do something, commit or rollback, disconnect).
>
>Just before starting the ACTION, I start a timer in another thread.
>
>I keep monitoring this timerthread and some flag that indicates that
>ACTION should have been finished. At a certain time I might find:
>'ACTION is taking too long, something obviously went wrong, something
>that apparantly does not trigger any errors or timeouts in the NOS, the
>sockets, the API, my IBObjects, my application. I want to, I even must
>abort'.
>
>Same thing on explorer, mozilla or whatever browser. It can and will
>tell me if a server can be reached, it can tell me if there are errors
>in the pages etc etc. But it happens quite frequently that NO errors are
>triggered, that a message 'loading data from xxxx' is displayed on the
>statusbar and that some animated gif shows me the waiting state of the
>browser. But there IS a button to interrupt/abort the process! You don't
>need taskmanager to kill the application...

HTTP protocol is stateless. The database's API certainly isn't.

>And that is my simple question. How to abort gracefully a bad
>connection? Can it be done? If not gracefully, would it be possible and
>safe (and how?) to use something like IB_Connection.Forcedisconnect?
>Would it be responsive or would it be busy and trapped in its own thread?

This one is definitely an IBO question, right off-topic here.

On the Firebird side, you are talking about two totally different
things. One one hand, inability to *get* a connection, while, on the
other, some way to decide that the connection you have got is too slow.

If you can't *get* a connection, you are waiting for the NOS to timeout
your request. If you connected to the database, started a transaction and
submitted a request, then there is no way to stop that running transaction.

IBO does have ways to abort a request (study the helpfile). So it's
possible to define your own request_too_slow exception and call on the
session timer to monitor the time it takes to satisfy a Fetch or some other
request; write a handler for the exception that sets off the graceful
unwinding back through request-transaction-connection.

However, the API itself has no way to know that the request is taking too
long; nor does it have any way to know if the network connection has been
broken. So, in IBO, the Connected property remains true. The first the
app will know that the connection is gone is when it submits *another*
request and gets an exception.

Your idea of monitoring in a different thread won't work if that thread is
monitoring a different connection, as it must: trying to access a single
connection from multiple threads is a no-no... And IBO is very aggressive
about enforcing this: each data access thread must instantiate its own
Session wrapper, as well as connection[s], transaction[s] and statement[s]
within that session.

./heLen