Nested vs distributed transaction; 2PC

Nested transactions versus distributed transactions

• Nested transaction: a transaction made of sub-transactions in a tree. The top-level transaction contains child transactions, which may contain their own children. Sub-transactions at the same level can run concurrently, and a sub-transaction can abort without aborting its parent; the parent may retry or choose another action. Example: a book trip transaction with sub-transactions book flight, book hotel, book taxi. If the taxi booking fails, the parent can try another company.

• Distributed transaction: a (flat or nested) transaction whose operations access objects on several servers. What matters is not the structure of the transaction but that its data are distributed. It needs a coordinator to commit or abort it at all servers. Example: transferring money from an account at bank server X to an account at server Y.

A transaction can be both (a nested distributed transaction, e.g. a book trip that has sub-transactions at airline, hotel and taxi servers).

Commitment: two-phase commit

The two-phase commit protocol (2PC) makes sure that all servers (participants) of a distributed transaction either all commit or all abort. One server acts as the coordinator (usually the one that the client contacted); others are participants.

Phase 1: voting

1. The coordinator sends canCommit? to every participant.
2. Each participant replies Yes (it has saved the transaction's changes to permanent storage and is prepared; it can no longer unilaterally abort) or No (it aborts at once).

Phase 2: completion 3. If all votes (including the coordinator's own) are Yes, the coordinator records the decision and sends doCommit; if any vote is No or a timeout occurs, it sends doAbort. 4. Participants carry out the decision and send haveCommitted to the coordinator.

Coordinator            Participants
   |--- canCommit? ------->|
   |<------ Yes / No ------|
   | (decide, log)         |
   |--- doCommit/doAbort ->|
   |<---- haveCommitted ---|

Failures

• If a participant crashes before voting, the coordinator times out and aborts.
• A participant that has voted Yes is in the uncertain state; if the coordinator fails it must wait (it blocks) or ask other participants for the decision.
• On recovery, servers use their logs to complete the protocol.

Drawbacks: blocking if the coordinator fails, and extra messages and delays (about 3N messages for N participants).