One thing is, if you only read data, then use a read-only transaction.

> In combination with the read committed isolation level, you are in a
> transaction mode with very low overhead and OIT/OAT won't get stuck as
> well, even for long runners.

True, but programmers are human and lazy and forgetful. They use read/write transactions when they shouldn't. Ultimately, I am trying to provide a "database connection" class that will set appropriate timeout values for all transactions associated with the connection. Everyone will use this class OR ELSE. That way, even if the programmer goofs up, the transactions will be closed in a timely manner.

> Use some kind of tracing to figure out what's exactly going on. Either
> with IBO's stuff

I've used TIB_Monitor and it's OK but it sure is tedious to wade your way through all that stuff. I've found the most useful thing is to roll my own by examining the active transactions and active queries and just displaying the offenders. But that is on a program by program basis and is only useful if you know which program is screwing up.

> or if you are on Firebird 2.5, then get used to the
> Trace API. An invaluable feature.

Gonna have to look into that one of these days.

> And even better, give our FB
> TraceManager product a try. ;-))

I'll have a look.