I'd say instead of using the database transaction, define your
application specific transactions, record undo information and/or use
versioning on your data so you can easily revert to an earlier version
of the data, and/or separate an 'uncommited' view of the data from the
current valid ('committed' view).

I think that is better, more flexible and more scalable (and in the long
run maybe even easier) than to abuse database transactions for what are
actually user conversations that can be undone.

Mark

Svein Erling Tysvær wrote:

> There is another option as well. You could code in your program that if there's no activity within xx minutes, then you rollback the transaction. This way, your users will quickly learn not to leave half finished work at their desktop.

--
Mark Rotteveel