Cascading aborts; three-phase commit

Cascading aborts

A cascading abort happens when a transaction reads a value written by another transaction that has not yet committed (a dirty read), and the writer then aborts. The reader has used data that never officially existed, so it must also abort, and every transaction that read the reader's data must abort too, forming a chain.

Example: T writes A = 50 (old value 30); U reads A = 50 and writes B based on it; T aborts, so A returns to 30. U's work is invalid and U must abort; any V that read B aborts too.

Solutions

• Strict execution: delay reads and writes of an object until the transaction that last wrote it has committed or aborted. In practice this is strict two-phase locking (hold write locks until commit/abort).
• Allow transactions to read only committed data (no dirty reads).
• In timestamp ordering, make a reader wait for the tentative version to commit (strict timestamp ordering).

This also avoids the related problem of premature writes (restoring before-images wrongly) when aborts occur.

Three-phase commit

The three-phase commit protocol (3PC) is an extension of 2PC that avoids blocking when the coordinator crashes, by adding a pre-commit state between the vote and the commit. Its states satisfy two conditions: there is no state from which a process can move directly to both COMMIT and ABORT, and there is no state in which a process cannot yet make a final decision but can move directly to COMMIT.

Phases

1. canCommit: the coordinator sends Prepare/canCommit?; participants reply Yes or No. If any No, or a timeout, the coordinator sends abort.
2. preCommit: if all say Yes, the coordinator sends Pre-commit; participants acknowledge. Now everyone knows that all have voted Yes.
3. doCommit: after all acknowledgements, the coordinator sends Commit; participants commit and reply.

Coordinator states:
 INIT --canCommit?--> WAIT --all Yes--> PRECOMMIT --acks--> COMMIT
                        |any No/timeout
                        v
                      ABORT

Participant states:
 INIT --Yes--> READY --preCommit--> PRECOMMIT --commit--> COMMIT
   |No          |abort/timeout
   v            v
 ABORT        ABORT

Recovery rule: if the coordinator fails, the participants elect a new one. If any participant is in PRECOMMIT, all can commit; if none is, all can abort. Timeouts drive transitions so the system never blocks indefinitely.

Compared with 2PC: 3PC is non-blocking under crash failures (not for network partitions), but needs one more round of messages, so it costs more and is less used in practice.