At 10:21 PM 17/05/2006, you wrote:

>Hi,
>
>reading about transactions isolation on a Borland's article, I've found the
>following:
>
>"....
>
>However, with InterBase 7.1 SP 1 and later not every active transaction will
>cause the OAT to stick. Here are the rules.
>
> 1. A read only read committed transaction can remain open indefinitely
> without causing the OAT to stick.

This has always been the case.

> 2. A read/write read committed transaction can remain open
> indefinitely as long as you call commit retaining each time the
> transaction
> updates the database.

True for Firebird 2, thanks to a bug fix by Vlad Horsun. (See P. 118
of the release notes.) And (as with InterBase), if you write
applications that hold read-write transactions open indefinitely
without committing them by any means, e.g. in ClientDataSets, the
stuck OAT problem remains.

> 3. Any snapshot transaction will stick the OAT. Snapshot transactions
> should be committed as soon as possible to prevent performance
> degradation.

Good advice. Emphasis on COMMIT. CommitRetaining shouldn't be used
with snapshot transactions unless you are applying strict timeouts on
user activity in the client application to force hard commits. No
change here from the historical situation.

>Is there some improvement regarding OAT & Commit Retaining in the
>upcoming Firebird 2?

Yes. If you want to know what's in Firebird 2, download the release
notes and search them. There are links to the RC 2 download page
right on the homepage of the main Firebird website http://www.firebirdsql.org

./heLen


./heLen