Distributed Systems Fall 2009

Distributed transactions

Fall 2009 5DV020 3

Outline

• Flat and nested distributed transactions

• Atomic commit– Two-phase commit protocol

• Concurrency control– Locking– Optimistic concurrency control

• Distributed deadlock– Edge chasing

• Summary

Fall 2009 5DV020 4

Flat and nested distributed transactions

• Distributed transaction:– Transactions dealing with objects managed by different processes

• Allows for even better performance– At the price of increased complexity

• Transaction coordinators and object servers– Participants in the transaction

Fall 2009 5DV020 5

Atomic commit

• If client is told that the transaction is committed, it must be committed at all object servers– ...at the same time– ...in spite of (crash) failures and asynchronous systems

Fall 2009 5DV020 6

Two-phase commit protocol

• Phase 1: Coordinator collects votes– “Abort”

• Any participant can abort its part of the transaction

– “Prepared to commit”• Save update to permanent storage to survive crashes

• May not change vote to “abort”

• Phase 2: Participants carry out the joint decision

Fall 2009 5DV020 7

Two-phase commit protocol (in detail)

• Phase 1 (voting):– Coordinator sends “canCommit?” to each participant

– Participants answer “yes” or “no”• “Yes”: update saved to permanent storage

• “No”: abort immediately

Fall 2009 5DV020 8

Two-phase commit protocol (in detail)

• Phase 2 (completion):– Coordinator collects votes (including own)• No failures and all votes are “yes”? Send “doCommit” to each participant, otherwise, send “doAbort”

– Participants are in the “uncertain” state until they receive “doCommit” or “doAbort”, and may act accordingly• Confirm commit via “haveCommitted”

Fall 2009 5DV020 9

Two-phase commit protocol

• If coordinator fails– Participants are “uncertain”

• If some have received an answer (or they can figure it out themselves), they can coordinate themselves

– Participants can request status– If participant has not received “canCommit?” and waits too long, it may abort

Two-phase commit protocol

• If participant fails– No reply to “canCommit?” in time?

• Coordinator can abort

– Crash after “canCommit?”• Use permanent storage to get up to speed

Fall 2009 5DV020 11

Two-phase commit protocol for nested transactions• Subtransactions a “provisional commit” – Nothing written to permanent storage

• Ancestor could still abort!

– If they crash, the replacement cannot commit

• Status information is passed upward in tree– List of provisionally committed subtransactions eventually reach top level

Fall 2009 5DV020 12

Two-phase commit protocol for nested transactions

• Top-level transaction initiates voting phase with provisionally committed transactions– If they have crashed since the provisional commit, they must abort

– Before voting “yes”, must prepare to commit data• At this point we use permanent storage

– Hierarchic or flat voting

Fall 2009 5DV020 13

Hierarchic voting

• Responsibility to vote passed one level/generation at a time, through the tree

Fall 2009 5DV020 14

Flat voting

• Contact coordinators directly using parameters– Transaction ID– List of transactions that are reported as aborted• Coordinators may manage more than one subtransaction, and due to crashes, this information may be required

Fall 2009 5DV020 15

Concurrency control revisited• Locks

– Release locks when transaction can finish• After phase 1 if transaction should abort• After phase 2 if transaction should commit

– Distributed deadlock, oh my!

• Optimistic concurrency control– Validate access to local objects– Commitment deadlock if serial– Different transaction order if parallel

– Interesting problem! Read book!

Fall 2009 5DV020 16

Distributed deadlock

• Local and distributed deadlocks– Phantom deadlocks

• Simplest solution– Manager collects local wait-for information and constructs global wait-for graph• Single point of failure, bad performance, does not scale, what about availability, etc.

• Distributed solution

Fall 2009 5DV020 17

Edge chasing

• Initiation: a server notices that T waits for U for object A, so sends <T → U> to server handling A (where U may be blocked)

Edge chasing

• Detection: servers handle incoming requests by inspecting if the relevant transaction (U) is also waiting for another transaction (V) – if so, updates probe (<T → U → V>) and sends it along– Loops (e.g. <T → U → V → T>) indicate deadlock

Edge chasing

• Resolution: abort a transaction in the cycle

• Servers communicate with the coordinators for each transaction to find out what they wait for

Fall 2009 5DV020 20

Edge chasing

• Any problem with the algorithm?– What if all coordinators initiate it, and then (when they detect the loop) start aborting left and right?

• Totally ordered transaction priorities– Abort lowest priority!

Edge chasing

• Optimization: only initiate probe if a transaction with higher priority waits for a lower one– Also only forward probes to transactions of lower priority

Fall 2009 5DV020 22

Edge chasing

• Any problem with the optimized algorithm?– If higher transactions wait for a lower one (but the lower one is not blocked when the request comes), and it then becomes blocked, it will not initiate probing

Edge chasing

• Add probe queues!– All probes that are related to a transaction are saved, and are sent (by the coordinator) to the server of the object with the request for access

– Works, but increases complexity– Probe queues must be maintained

Fall 2009 5DV020 24

Summary

• Distributed transactions• Atomic commit protocol

– Two-phase commit protocol• Vote, then carry out order• Flat transactions• Nested transactions

– Voting schemes

• Concurrency control– Problems!– Distributed deadlock

• Edge chasing

Fall 2009 5DV020 25

Next lecture

• Daniel takes over!

• Beyond client-server– Peer to peer (P2P)– BitTorrent– ...and more!