Transaction atomicity

Transaction atomicity gives a database transaction an all-or-nothing effect: either its committed updates take effect together or its partial updates do not remain as a completed result. This can be implemented with undo information, version visibility, recovery logging or combinations of these mechanisms. It does not require every physical write to happen at the same instant.

For example, transferring five units between accounts requires a debit and a credit. If an error occurs after the debit, aborting the transaction must not leave only that debit as the final database result. SQL transaction blocks use BEGIN, COMMIT and ROLLBACK to express the boundary.^[ref] Atomicity alone does not say how transactions interact before completion; transaction isolation governs that. Nor does it make a committed result survive a crash; that is transaction durability. External effects such as a sent email require coordination beyond rolling back the database changes.