Hi,

> That would be very bad if it did. Coming from a BDE background, you
> may not fully appreciate transactions (I didn't before moving across
> to Firebird). Transactions in Firebird are ACID compliant. They
> define an Atomic operation. That means that any queries run either
> all run, or none of them run. If there is a problem, crash, power
> loss, whatever mid transaction, then the whole transaction is rolled
> back.

I understand very well the transaction issue. What I don't understand
is why there is a performance issue when an CommitRetaining is applied.
Since the comands related to the transaction won't be "rollbacked"
anymore, other transaction have no interest on this one anymore, so
they should not have a performance impact. The long-running
transaction should suffer a performance impact, that is understandable.
Is there some improvement on FB2 related to this issue?

I work with other databases (PG, MSSQL) but on those I've been
developing the systems since the beginning so the transactions are
well-designed.
My problem with this FB application is really the legacy code, which
is very large and revising it completely to fix this transaction issue
would take too much time. If I have to to that, I would prefer to
change the system to PG, which has been used to develop our new systems.

> No, see above. What would be useful would be a mechanism to identify
> some information about the stuck transaction (MAC address of the
> connection, user name, role, time started etc would be a good start
> in many cases of identifying the long transactions.

Yes, that would be very good. Actually any sort of monitoring utility
for FB like IBMonitor for IB7/7.5 would be very appreciated.

Is there some development regarding this monitoring issue on FB2?

> I do wish my news was better, but at least you have a starting point.

Thanks for your attention
Rodrigo