{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

chapter13 - Chapter 13 Distributed Transactions...

Info iconThis preview shows pages 1–11. Sign up to view the full content.

View Full Document Right Arrow Icon
Introduction Flat and nested distributed transactions Atomic commit protocols Concurrency control in distributed transactions Distributed deadlocks Transaction recovery Summary Chapter 13: Distributed Transactions
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Distributed transaction A flat or nested transaction that accesses objects managed by multiple servers Atomicity of transaction All or nothing for all involved servers Two phase commit Concurrency control Serialize locally + serialize globally Distributed deadlock Introduction
Background image of page 2
Introduction Flat and nested distributed transactions Atomic commit protocols Concurrency control in distributed transactions Distributed deadlocks Transaction recovery Summary Chapter 13: Distributed Transactions
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Flat transaction Nested transaction Nested banking transaction The four subtransactions run in parallel Flat and nested distributed transactions
Background image of page 4
The coordinator Accept client request Coordinate behaviors on different servers Send result to client Record a list of references to the participants The participant One participant per server Keep track of all recoverable objects at each server Cooperate with the coordinator Record a reference to the coordinator Example The architecture of distributed transactions
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Introduction Flat and nested distributed transactions Atomic commit protocols Concurrency control in distributed transactions Distributed deadlocks Transaction recovery Summary Chapter 13: Distributed Transactions
Background image of page 6
The protocol Client request to end a transaction The coordinator communicates the commit or abort request to all of the participants and to keep on repeating the request until all of them have acknowledged that they had carried it out The problem some servers commit, some servers abort How to deal with the situation that some servers decide to abort? One-phase atomic commit protocol
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Allow for any participant to abort First phase Each participant votes to commit or abort The second phase All participants reach the same decision If any one participant votes to abort, then all abort If all participants votes to commit, then all commit The challenge work correctly when error happens Failure model Server crash, message may be lost, no arbitrary fails Introduction to two-phase commit protocol
Background image of page 8
When the client request to abort The coordinator informs all participants to abort When the client request to commit First phase The coordinator ask all participants if they prepare to commit If a participant prepare to commit, it saves in the permanent storage all of the objects that it has altered in the transaction and reply yes . Otherwise, reply no Second phase The coordinator tell all participants to commit ( or abort) The two-phase commit protocol
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Operations for two-phase commit protocol
Background image of page 10
Image of page 11
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}