> For inserts and updates, for example, a window representing a row from the database opens, a transaction starts, a row is read, the transaction commits. The user does what they want with the contents of the row, hits "OK" and if the data has changed, a transaction starts, the row is inserted or updated, and the transaction is committed. If the user hits "Cancel", the transaction doesn't even start.
>
> Now I'd like to provide a window where the user can make repeated update operations to the data, query the data and, at the end of the operation, hit the "OK" button to commit, or "Cancel" to roll back the transaction.
>
> I believe this would involve starting a transaction when they open the window, and leave the transaction open for possibly a long time.

What prevent you from using the same pattern? Start transaction when
necessary and stop it when the action is done.

> I wouldn't be surprised if people go to lunch, or even go home for the weekend, while the window, and transaction, are open. They could even turn off their PC or the server could go down for maintenance and never properly quit the window and commit or roll back the transaction.
>
> Is this a problem?

Yes, it is. If active transaction is left for weekends and other
activity still continues, the difference between Oldest Transaction and
Next Transaction will grow, so server will run autosweep immediately
after old transaction is released. It can drop server performance for
awhile.
On the other hand, if there is no big parallel activity (say, 20000
transaction during this transaction lifetime), long transaction is
almost harmless.

SY, SD.