Commit-retaining and commit/start do not behave exactly identically. Commit-retaining may not see
changes that commit/start can. 'retaining' will see exactly what the initial transaction saw, plus
changes made by the transaction, plus other changes as provided for by the isolation level. A new
transaction may see more, depending on your isolation level. The two are not identical though, so
consider what you need carefully.

The reason for keeping transactions short is to prevent garbage from building up in the database.
Garbage builds up when a transaction is open and needs visibility "back in time" to its beginning.
So long as that stays true, the engine can't clean up old record versions. If anything, I would
expect 'commit retaining' to be worse in this case. Each time a transaction is fully released,
garbage collection has a new opportunity to remove old versions of records. Using commit-retaining
keeps the "view in time" of your transaction back at an earlier point than necessary.

Commit-retaining doesn't have to recalculate isolation/visibility to other transactions the way new-
transaction does, and is useful (on the logical level) under some circumstances. I doubt it's a
useful performance enhancement though (physical level.)

Anyone else care to comment?

-Philip

---------- Original Message -----------

> Hi,
> everybody here say, keep your transactions as short as possible and
> don't leave them opened.
> But in the API documentation of IB6 on page 75, I found a hint, which
> says, it is better to start a transaction for every user and use
> isc_commit_retaining(), than closing and starting a new transaction with
> isc_commit_transaction().
>
> thx,
> Stefan

------- End of Original Message -------