At 01:58 AM 11/05/2004 +0000, you wrote:

>In Paul Beach's paper "InterBase and the Oldest Interesting
>Transaction", he mentions a scenario where a sweep does not
>improve performance and at the end explains that this is
>because the sweep does not work if there is a "transaction left
>permanently open".
>
>What would cause this? Shouldn't transactions be
>automatically rolled back on a disconnect?

Yes, eventually non-completed transactions will be cleaned up. He is
talking about servers that stay running 24/7 and users never log out (the
common case) where applications never take care to enforce hard
commits. (CommitRetaining is not a "hard" commit and will inhibit garbage
collection if used sans periodic Commits).

>If they're not, how do you commit them short of
>doing a backup/restore?

Call Commit.

>I also don't understand what he means by not 'rolling
>back transactions unnecessarily' and how this would
>help prevent said problem.

You have two ways to end transactions: Commit or Rollback. Rollback costs
more in terms of overhead and the time garbage is in flux. Transactions
that only select don't need to be rolled back - you can commit them.

/heLen