A well-designed transaction should have the following properties:
The integrity of the database will be maintained at all times.
The duration and coverage of locks will be minimized. Locks should be applied to as few rows as possible and maintained for the shortest possible duration.
Rollbacks will be minimal—transactions that eventually issue a rollback have needlessly consumed resources.
User expectations about the persistence of data will be met. For instance, a user who clicks a Save or Apply button has a reasonable expectation that the data will not disappear if he subsequently clicks Cancel on another page.
To achieve these goals, we recommend the following general guidelines for transaction design:
A transaction should generally include as small a logical unit of work as possible to reduce the duration of locks.
For instance, rather than trying an insert and rolling back if there is a “duplicate key” error, check for the existence of the key value before issuing the DML.
The existence of a savepoint may indicate that you have failed to check for success criteria before issuing a DML statement and may indicate a transaction design that encourages rollbacks.
Lock rows that you
SELECT if the results of the
SELECT statement affect DML executed later in the transaction. Pessimistic locking is easy ...