Atomicity means that an operation is observed as completing completely or not taking effect at all. It prevents failures from exposing a misleading partial result. section 5.3 section 11.1
A useful mental model treats a process as a sequence of atomic actions. A single action may be failure-atomic, but failure atomicity does not automatically compose across multiple actions: a crash can stop execution after a prefix. section 1.8 section 11.2.2
A payment and account-creation failure
Suppose signup charges a user's credit card and then creates an account. If execution crashes between those actions, the user is charged without receiving access. Atomicity requires the outcome to be observably equivalent to both actions completing or neither action taking effect. section 11.1
Atomicity has two related forms. Concurrency atomicity hides intermediary states from other processes; failure atomicity makes an interrupted operation appear to have happened completely or not at all. Failure atomicity is often needed to move from one correct state to another without exposing an incorrect intermediary. section 11.1
For a transaction, atomicity is represented by exactly one commit or abort. On one resource manager, local state can provide the guarantee; across multiple resource managers, an atomic commit protocol makes all subtransactions commit or all abort. section 5.3 section 6.1
A correct distributed atomic commit protocol provides two guarantees:
- Safety prevents conflicting decisions: no participants commit while others abort. section 6.1.2
- Liveness requires every participant eventually to settle permanently on commit or abort. section 6.1.2
Listing 6.1 Money transfer on one RM executing in one transaction
BEGIN UPDATE accounts SET balance = balance - $1 WHERE id = $2; UPDATE accounts SET balance = balance + $1 WHERE id = $3; COMMIT
Use the two-update money transfer to see atomicity on one resource manager: both balance changes belong to one transaction and one commit decision. section 6.1
