Download presentation
Presentation is loading. Please wait.
1
Distributed Systems1 Chapter 7: Distributed Transactions Transaction concepts Centralized/Distributed Transaction Architecture Schedule concepts Locking schemes Deadlocks Distributed commit protocol ( 2PC )
2
Distributed Systems2 An Updating Transaction Updating a master tape is fault tolerant: If a run fails for any reason, all the tape could be rewound and the job restarted with no harm done.
3
Distributed Systems3 Transaction concepts OS Processes DBMS Transactions A collection of actions that make consistent transformation of system states while preserving consistency Termination of transactions – commit vs abort Example: T : x = x + y R(x) Read(x) W(x) C Read(y) R(y) Write(x) Commit
4
Distributed Systems4 Properties of Transactions: ACID A tomicity All or Nothing C onsistency No violation of integrity constants, i.e., from one consistent state to another consistent state I solation Concurrent changes invisible, i.e. serializable D urability Committed updates persist (saved in permanent storage)
5
Distributed Systems5 Transaction Processing Issues Transaction structure Flat vs Nested vs Distributed Internal database consistency Semantic data control and integrity enforcement Reliability protocols Atomicity and durability Local recovery protocols Global commit protocols Concurrency control algorithms Replica control protocols
6
Distributed Systems6 Basic Transaction Primitives PrimitiveDescription BEGIN_TRANSACTIONMake the start of a transaction END_TRANSACTION Terminate the transaction and try to commit ABORT_TRANSACTION Kill the transaction and restore the old values READRead data from a file, a table WRITEWrite data to a file, a table
7
Distributed Systems7 a) Transaction to reserve three flights commits b) Transaction aborts when third flight is unavailable BEGIN_TRANSACTION reserve BJ -> JFK; reserve JFK -> TTY; reserve TTY -> MON; END_TRANSACTION (a) BEGIN_TRANSACTION reserve BJ -> JFK; reserve JFK -> TTY; reserve TTY -> MON full => ABORT_TRANSACTION (b) A Transaction Example
8
Distributed Systems8 Transaction execution
9
Distributed Systems9 Nested vs Distributed Transactions
10
Distributed Systems10 T S1S1 T 22 T 21 T 12 T 11 T2T2 T1T1 T S3S3 S2S2 S2S2 S6S6 S5S5 S4S4 S1S1 S3S3 (a) Distributed flat(b) Distributed nested S7S7 S0S0 A circle (S i ) denotes a server, and a square (T j ) represents a sub-transaction. Flat/nested Distributed Transactions
11
Distributed Systems11 Distributed Transaction A distributed transaction accesses resource managers distributed across a network When resource managers are DBMSs we refer to the system as a distributed database system Each DBMS might export stored procedures or an SQL interface. In either case, operations at a site are grouped together as a subtransaction and the site is referred to as a cohort of the distributed transaction Coordinator module plays major role in supporting ACID properties of distributed transaction Transaction manager acts as coordinator
12
Distributed Systems12 Distributed Transaction execution
13
Distributed Systems13 Distributed ACID Global Atomicity: All subtransactions of a distributed transaction must commit or all must abort. An atomic commit protocol, initiated by a coordinator (e.g., the transaction manager), ensures this. Coordinator must poll cohorts to determine if they are all willing to commit. Global deadlocks: there must be no deadlocks involving multiple sites Global serialization: distributed transaction must be globally serializable
14
Distributed Systems14 Schedule Synchronizing concurrent transactions Data base remains consistent Maximum degree of concurrency Transaction execute concurrently but the net effect of the resulting history is equivalent to some serial history Conflict equivalence The relative order of execution of the conflicting operations belonging to unaborted transactions in the two schedules is same
15
Distributed Systems15 BEGIN_TRANSACTION(T) : K : withdraw(A , 40) ; K : deposit(B , 40) ; END_TRANSACTION(T) ; BEGIN_TRANSACTION(U) : K : withdraw(C , 30) K : deposit(B , 30) END_TRANSACTION(U) ; OperationsbalanceOperationsbalance A.balance A.read() (A) 100 A.write(A.balance – 40) (A) 60 C.balance C.read() (C) 300 C.write(C.balance – 30) (C) 270 B.balance B.read() (B) 200 B.balance B.read() (B) 200 B.write(B.balance + 30) (B) 230 B.write(B.balance + 40) (B) 240 Lost Update Problem Transaction T and U both work on the same bank branch K
16
Distributed Systems16 Transaction T and U both work on the same bank branch K Inconsistent Retrieval Problem BEGIN_TRANSACTION(T) : K : withdraw(A , 100) ; K : deposit(B , 100) ; END_TRANSACTION(T) ; BEGIN_TRANSACTION(U) : K : Total_balance(A, B, C) … END_TRANSACTION(U) ; OperationsbalanceOperationstotal_balanc e A.balance A.read() (A) 200 A.write(A.balance – 100) (A) 100 total_balance A.read() 100 total_balance total_balance + B.read() 100 + 200 total_balance total_balance + C.read() 300 + 200 B.balance B.read() (B) 200 B.write(B.balance + 100) (B) 300 ….
17
Distributed Systems17 BEGIN_TRANSACTION(T) : K : withdraw(A , 40) ; K : deposit(B , 40) ; END_TRANSACTION(T) ; BEGIN_TRANSACTION(U) : K : withdraw(C , 30) K : deposit(B , 30) END_TRANSACTION(U) ; OperationsbalanceOperationsbalance A.balance A.read() (A) 100 A.write(A.balance – 40) (A) 60 C.balance C.read() (C) 300 C.write(C.balance – 30) (C) 270 B.balance B.read() (B) 200 B.write(B.balance + 40) (B) 240 B.balance B.read() (B) 240 B.write(B.balance + 30) (B) 270 Serial Equivalent Transaction T and U both work on the same bank branch K
18
Distributed Systems18 Serializability a) – c) Three transactions T 1, T 2, and T 3 d) Possible schedules BEGIN_TRANSACTION x = 0; x = x + 1; END_TRANSACTION (a) BEGIN_TRANSACTION x = 0; x = x + 2; END_TRANSACTION (b) BEGIN_TRANSACTION x = 0; x = x + 3; END_TRANSACTION (c) Schedule 1x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3Legal Schedule 2x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3;Legal Schedule 3x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3;Illegal (d)
19
Distributed Systems19 Concurrency control Algorithms Pessimistic Two-Phase locking based(2PL) Centralized 2PL Distributed 2PL Timestamp Ordering (TO) Basic TO Multiversion TO Conservative TO Hybrid Optimistic Locking and TO based
20
Distributed Systems20 A transaction locks an object before using it When an object is locked by another transaction, the requesting transaction must wait When a transaction releases a lock, it may not request another lock Strict 2 PL – hold lock till the end The scheduler first acquires all the locks it needs during the growing phase The scheduler releases locks during shrinking phase Two-Phase Locking (1)
21
Distributed Systems21 Two-Phase Locking (2)
22
Distributed Systems22 Two-Phase Locking (3) BEGIN_TRANSACTION(T) : K : withdraw(A , 40) ; K : deposit(B , 40) ; END_TRANSACTION(T) ; BEGIN_TRANSACTION(U) : K : withdraw(C , 30) K : deposit(B , 30) END_TRANSACTION(U) ; OperationsbalanceOperationsbalance BEGIN_TRANSACTION(T)BEGIN_TRANSACTION(U) A.balance A.read() lock (A) 100C.balance C.read() lock (C) 300 A.write(A.balance – 40) (A) 60C.write(C.balance – 30) (C) 270 B.balance B.read()lock (B) 200 B.balance B.read()Waiting for (B)’s lock B.write(B.balance + 40) (B) 240… END_TRANSACTION(T)release (A) (B)…lock (B) 240 B.write(B.balance + 30) (B) 270 END_TRANSACTION(U)
23
Distributed Systems23 Centralized 2PL One 2PL scheduler in the distributed system Lock requests are issued to the central scheduler Primary 2PL Each data item is assigned a primary copy, the lock manager on that copy is responsible for lock/release Like centralized 2PL, but locking has been distributed Distributed 2PL 2PL schedulers are placed at each site and each scheduler handles lock requests at that site A transaction may read any of the replicated copies by obtaining a read lock on one of the copies. Writing into x requires obtaining write lock on all the copies. Two-Phase Locking (4)
24
Distributed Systems24 Timestamp ordering (1) Transaction T i is assigned a globally unique time stamp ts(T i ) Using Lamport’s algorithm, we can ensure that the timestamps are unique (important) Transaction manager attaches the timestamp to all the operations Each data item is assigned a write timestamp (wts) and a read timestamp (rts) such that: rts(x) = largest time stamp of any read on x wts(x) = largest time stamp of any write on x
25
Distributed Systems25 Conflicting operations are resolved by timestamp order, let ts(T i ) be the timestamp of transaction T i, and R i (x), W i (x) be read/write operation from T i for R i (x): For W i (x) if (ts(T i ) < wts(x)) if (ts(T i ) < wts(x) and then reject R i (x) (abort T i ) ts(T i ) < rts(x)) else accept R i (x) then reject W i (x) (abort T i ) rts(x) ts(T i ) else accept W i (x) wts(x) ts(T i ) Timestamp ordering (2)
26
Distributed Systems26 Distributed commit protocols How to execute commit for distributed transactions Issue: How to ensure atomicity and durability One-phase commit (1PC): the coordinator communicates with all servers to commit. Problem: a server can not abort a transaction. Two-phase commit (2PC): allow any server to abort its part of a transaction. Commonly used. Three-phase commit (3PC): avoid blocking servers in the presence of coordinator failure. Mostly referred in literature, not in practice.
27
Distributed Systems27 Two phase commit (2PC) Consider a distributed transaction involving the participation of a number of processes each running on a different machine, and assuming no failure occur Phase1: The coordinator gets the participants ready to write the results into the database Phase2: Everybody writes the results into database Coordinator: The process at the site where the transaction originates and which controls the execution Participant: The process at the other sites that participate in executing the transaction Global commit rule: The coordinator aborts iff at least one participant votes to abort The coordinator commits iff all the participants vote to commit
28
Distributed Systems28 2PC phases
29
Distributed Systems29 2PC actions
30
Distributed Systems30 Distributed 2PC The Coordinator initiates 2PC The participants run a distributed algorithm to reach the agreement of global commit or abort.
31
Distributed Systems31 Problems with 2PC Blocking Ready implies that the participant waits for the coordinator If coordinator fails, site is blocked until recovery Blocking reduces availability Independent recovery not possible Independent recovery protocols do not exist for multiple site failures
32
Distributed Systems32 Deadlocks If transactions follow 2PL, then it may have deadlocks Consider the following scenarios: w1(x) w2(y) r1(y) r2(x) r1(x) r2(x) w1(x) w2(x) Deadlock management Ignore – Let the application programmers handle it Prevention – no run time support Avoidance – run time support Detection and recovery – find it at your own leisure!!
33
Distributed Systems33 T UV W W U T V (a) Simple circle(b) Complex circle Mutual exclusion Hold and wait(a) T U V W T No preemption(b) V W T V Circular chain V W V Deadlock Conditions
34
Distributed Systems34 Deadlock Avoidance WAIT-DIE rule If (ts(T i ) < ts(T j )) then T i waits else T i dies Non preemptive – T i never preempts T j Prefers younger transactions WOUND-WAIT rule If (ts(T i ) < ts(T j )) then T j is wounded else T i waits Preemptive – T i preempts T j if it is younger Prefers older transactions Problem: very expensive, as deadlock is rarely and randomly occurred, forcing deadlock detection involves system overhead.
35
Distributed Systems35 Deadlock Detection Deadlock is a stable property. With distributed transaction, a deadlock might not be detectable at any one site But a deadlock still comes from cycles in a Wait for graph Topology for deadlock detection algorithms Centralized – periodically collecting waiting states Distributed – Path pushing Hierarchical – build a hierarchy of detectors
36
Distributed Systems36 S 1 A S 2 S 3 D C B V W U wait lock wait S 1 : U → V S 2 : V → W S 3 : W → U Centralized – periodically collecting waiting states
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.