>> A number one reason for a stuck OAT can be transaction which has been
>> *committed* with COMMIT RETAINING. Funny, right? Committed but still
>> active. ;-)
>>
>> Data access components tend to use commit retaining aka soft commits,
>> especially when being in autocommit mode.
>
> My components are set to:
>
> Commit Retaining = OFF
> Isolation Level = ReadCommited

* Which component set?
* Do you use some kind of autocommit?
* When happens if you commit? Gets the query component closed?

It really depends on the access components. For instance, IBO has some
advanced techniques which will advance the OIT/OAT behind the scenes for
read committed transactions. IBX is in that respect not that mature.

IBO also has a IB_StatusDialog component which allows you to identify a
long-running transaction more easily.

> Which AFAIK is the best setup, so..

Well, the best from a OIT/OAT POV would be a read-only read committed
transaction, but then you can't change data. ;-)

> Is there a way to verify in the database that the transactions are
> created following this parameters?
> I believe I could use the monitoring tables in 2.1+, right?

Right.

> What about 2.0?

It's up to the application developer to identify long-running
transactions in the application.



--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com