Distributed Systems1 Chapter 7: Distributed Transactions Transaction concepts Centralized/Distributed Transaction Architecture Schedule concepts Locking schemes Deadlocks Distributed commit protocol ( 2PC )

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.

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

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)

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

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

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

Distributed Systems8 Transaction execution

Distributed Systems9 Nested vs Distributed Transactions

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

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

Distributed Systems12 Distributed Transaction execution

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

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

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

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() total_balance  total_balance + C.read() B.balance  B.read() (B) 200 B.write(B.balance + 100) (B) 300 ….

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

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)

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

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)

Distributed Systems21 Two-Phase Locking (2)

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)

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)

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

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)

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.

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

Distributed Systems28 2PC phases

Distributed Systems29 2PC actions

Distributed Systems30 Distributed 2PC The Coordinator initiates 2PC The participants run a distributed algorithm to reach the agreement of global commit or abort.

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

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!!

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

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.

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

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