Ramiro Barreca schrieb am 20.12.2010 um 13:55 (-0300):

> The problem is not with TCP connections, but with FB transactions.
> Some users do use an app and, after a task the app remains open for a
> long time. While it is opened, the transaction appears as STARTED in
> the MON$TRANSACTIONS table and in the stats as the OAT.

As long as the TCP connection is open … Or do you connect by some other
means?

> It must be sure that the developer has not perform a commit after the
> query (even selects) or there is a problem whith the connection
> component of the app.

You could call it a bug in the software.

> 1. Is there a parameter for the client connection to use a type of
> transaction that can handle better this?

You could go with READ COMMITTED if all you ever want to do is read.

> 2. Which on is the better transaction model to use (even for
> selects)?

Possibly READ COMMITTED, possibly not. It all depends on your
application requirements. I don't think there is an easy and general
answer.

> 3. Is there a "magic" way of "suggest" developers to handle
> transactions in the right way?

Have you considered the options presented so far?

> 4. Can I automate the kill of TCP connections of not committed
> transactions so FB server can rollback them to allow the other
> clients continue working?

Didn't someone mention the TCP Keepalive settings? :-)

Michael