8.1 Transaction Rollback
A transaction can be rolled back at any point before the database commit (§7.4 step 3). After that commit the transaction is committed, and what remains is cleanup rather than rollback.
8.1.1 When it happens #
- Any step of any operation fails — a hash does not verify, disk space runs out, a security descriptor is rejected.
- The operator cancels.
- The process terminates abnormally before commit, in which case rollback runs on the next invocation (§7.8).
8.1.2 The procedure #
- Discard the transaction's staged files.
- Leave the pending database changes uncommitted — the commit never ran — and clear the transaction from the journal.
- Restore every displaced original by renaming its backup back into place.
- Remove the directories the transaction created.
- Release the lock.
Side effects are not involved. They run only after the database commit, so a rolled-back transaction never reached one and there is nothing to undo.
8.1.3 Ordering #
File operations are reversed in the opposite order to the one they were applied in, and each step checks the current state before acting, so a rollback interrupted partway and re-run reaches the same result.