Computer Science 425 Distributed Systems Lecture 21 Transaction Processing and Concurrency Control Reading: Sections

Acknowledgement The slides during this semester are based on ideas and material from the following sources: –Slides prepared by Professors M. Harandi, J. Hou, I. Gupta, N. Vaidya, Y-Ch. Hu, S. Mitra. –Slides from Professor S. Gosh’s course at University o Iowa.

Administrative MP2 posted October 5, 2009, on the course website, –Deadline November 6 (Friday) –Demonstration, 4-6pm, 11/6/2009 –Sign Up for demonstrations – Friday 4-6pm in 216 SC

Banking transaction for a customer (ATM) Transfer $100 from saving to checking account; Transfer $200 from money-market to checking account; Withdraw $400 from checking account. Transaction: 1. savings.deduct(100) /* includes verification */ 2. checking.add(100) /* depends on success of 1 */ 3. mnymkt.deduct(200) /* includes verification */ 4. checking.add(200) /* depends on success of 3 */ 5. checking.deduct(400) /* includes verification */ 6. dispense(400) 7. commit Example Transaction Client Server Transaction

 Sequence of operations that forms a single step, transforming the server data from one consistent state to another.  All or nothing principle: a transaction either completes successfully, and the effects are recorded in the objects, or it has no effect at all. (multiple clients, or crashes)  Transactions’ operations are indivisible (atomic) from the point of view of other transactions  No access to intermediate results/states  Free from interference by other operations But…  Transactions could run concurrently  Transactions may be distributed

Transaction: 1. savings.deduct(100) 2. checking.add(100) 3. mnymkt.deduct(200) 4. checking.add(200) 5. checking.deduct(400) 6. dispense(400) 7. commit Transaction Failure Modes A failure at these points means the customer loses money; we need to restore A failure at these points does not cause lost money, but the transaction cannot be repeated This is the point of no return A failure after the commit point (ATM crashes) needs corrective action; no undoing possible.

Properties of Transactions (ACID)  Atomicity: All or nothing  Consistency: starting in a consistent state, the transaction ends in a consistent state.  Isolation: Each transaction must be performed without interference from other transactions, i.e., the non-final effects of a transaction must not be visible to other transactions.  Durability: After a transaction has completed successfully, all its effects are saved in permanent storage.  Data saved in a file will survive if the server process crashes. “ To support failure atomicity and durability, objects must be recoverable”  Atomicity: store tentative object updates (for later undo/redo)  Durability: store entire results of transactions (all updated objects) to recover from permanent server crashes.

Bank Server: Coordinator Interface  Transactions are managed by a coordinator: openTransaction() -> trans; starts a new transaction and delivers a unique transaction identifier (TID) trans. This TID will be used in the other operations in the transaction. closeTransaction(trans) -> (commit, abort); ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. abortTransaction(trans); aborts the transaction.  TID can be passed implicitly (for other operations between open and close) with CORBA  Transactions are achieved by cooperation between client process, the server, the coordinator, and recoverable objects. Transactions can be implemented using RPCs/RMIs!

Bank Server: Account, Branch interfaces deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account getBalance() -> amount return the balance of the account setBalance(amount) set the balance of the account to amount create(name) -> account create a new account with a given name lookup(name) -> account return a reference to the account with the given name branchTotal() -> amount return the total of all the balances at the branch Operations of the Branch interface Operations of the Account interface

ACID - Isolation

Concurrent Transactions: Lost Update Problem  One transaction causes loss of info. for another: consider three account objects Transaction T1Transaction T2 balance = b.getBalance() b.setBalance(balance*1.1) b.setBalance = (balance*1.1) a.withdraw(balance* 0.1) c.withdraw(balance*0.1) T1/T2’s update on the shared object, “b”, is lost a: b:c: 280 c: 80 a: 220 b: 220 b:

Conc. Trans.: Inconsistent Retrieval Prob.  Partial, incomplete results of one transaction are retrieved by another transaction. Transaction T1Transaction T2 a.withdraw(100) total = a.getBalance() total = total + b.getBalance b.deposit(100) total = total + c.getBalance T1’s partial result is used by T2, giving the wrong result a: b: 00 a: c: total 300 b:

 An interleaving of the operations of 2 or more transactions is said to be serially equivalent if the combined effect is the same as if these transactions had been performed sequentially (in some order). Transaction T1 Transaction T2 balance = b.getBalance() b.setBalance = (balance*1.1) balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance* 0.1) c.withdraw(balance*0.1) Concurrency Control: “Serial Equivalence” a: b:c: 278 c: a: 242 b: == T1 (complete) followed by T2 (complete)

 An interleaving of the operations of 2 or more transactions is said to be serially equivalent if the combined effect is the same as if these transactions had been performed sequentially (in some order). Transaction T1 Transaction T2 balance = b.getBalance() b.setBalance = (balance*1.1) balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance* 0.1) c.withdraw(balance*0.1) Concurrency Control: “Serial Equivalence” a: b:c: 278 c: a: 242 b: == T1 (complete) followed by T2 (complete) Pairs of Conflicting Operations

 Two operations are in conflict, if their combined effect depends on the order they are executed, e.g., read-write, write-read, write-write (NOT read-read)  The effect of an operation refers to  The value of an object set by a write operation  The result returned by a read operation.  Two transactions are serially equivalent if and only if all pairs of conflicting operations (pair containing one operation from each transaction) are executed in the same order (transaction order) for all objects (data) they both access.  Why? Can start from original operation sequence and swap the order of non-conflicting operations to obtain a series of operations where one transaction finishes completely before the second transaction starts  Why is the above result important? Because: Serial equivalence is the basis for concurrency control protocols for transactions. Conflicting Operations

Read and Write Operation Conflict Rules Operations of different transactions ConflictReason read NoBecause the effect of a pair ofread operations does not depend on the order in which they are executed readwriteYesBecause the effect of aread and awrite operation depends on the order of their execution write YesBecause the effect of a pair ofwrite operations depends on the order of their execution

Conflicting Operators Example Transaction T1 Transaction T2 x= a.read() a.write(20) y = b.read() b.write(30) b.write(x) z = a.read() x= a.read() a.write(20) z = a.read() b.write(x) y = b.read() b.write(30) Serially equivalent interleaving of operations (why?) Conflicting Ops. Non- serially equivalent interleaving of operations

Inconsistent Retrievals Problem TransactionV : a.withdraw(100) b.deposit(100) TransactionW : aBranch.branchTotal() a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() b.deposit(100) $300 Both withdraw and deposit contain a write operation

A Serially Equivalent Interleaving of V and W TransactionV: a.withdraw(100); b.deposit(100) TransactionW: aBranch.branchTotal() a.withdraw(100); $100 b.deposit(100) $300 total = a.getBalance() $100 total = total+b.getBalance() $400 total = total+c.getBalance()...

ACID – Atomic All or Nothing ACID – Atomic All or Nothing

A Dirty Read When Transaction T Aborts TransactionT: a.getBalance() a.setBalance(balance + 10) TransactionU: a.getBalance() a.setBalance(balance + 20) balance = a.getBalance()$100 a.setBalance(balance + 10)$110 balance = a.getBalance()$110 a.setBalance(balance + 20) $130 commit transaction abort transaction Transaction U here encounters a dirty read from another transaction that aborts.

How to avoid dirty reads Two ways to avoid dirty reads (at run-time): 1.U could delay running the conflicting operation (e.g., a.getBalance()) until T commits or aborts 2.U delays its commit until after T commits. In that case, if T aborts, then U aborts as well. Rule (2) allows more concurrency than rule (1). However, rule (2) above could lead to cascading aborts (T aborts, then U aborts, then another transaction V that dirty read from U aborts, and so on…) To avoid cascading aborts, restrict transactions to read only objects that were written by committed transactions, i.e., rule (1).

Premature Writes TransactionT: a.setBalance(105) TransactionU: a.setBalance(110) $100 a.setBalance(105)$105 a.setBalance(110)$110 Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction.

Premature Writes TransactionT: a.setBalance(105) TransactionU: a.setBalance(110) $100 a.setBalance(105)$105 a.setBalance(110)$110 Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction.  The before image of T’s write is $100.  The before image of U’s write is $105.  If T commits and U aborts  $105 (ok)  If U commits then T aborts  $100 (not ok - $110 would be the correct value)  If T aborts then U aborts  $105 (not ok - $100 would be the correct value)  If U aborts then T aborts  $100 (ok) Write operations must be delayed until other transactions that updated the same objects earlier have either committed or aborted, i.e., U delays a.setBalance() until T has committed or aborted

Banking transaction for a customer (ATM) Transfer $100 from saving to checking account; Transfer $200 from money-market to checking account; Withdraw $400 from checking account. Transaction: 1. savings.deduct(100) /* includes verification */ 2. checking.add(100) /* depends on success of 1 */ 3. mnymkt.deduct(200) /* includes verification */ 4. checking.add(200) /* depends on success of 3 */ 5. checking.deduct(400) /* includes verification */ 6. dispense(400) 7. commit Example Transaction – Need Concurrency Control

Transaction Processing Systems Client Trans. Manager Object Manager Scheduler Trans. Manager Object Manager Scheduler Concurrency Control Transaction Workspace locking / unlocking req. Protocol management Subtrans Management Object Creation, lock recovery, destruction Objects Network

Summary Transactions an important concept ACID properties Serial Equivalence and Conflicting Operations Ensuring the aborts do not violate ACID