Computer Science 425 Distributed Systems Lecture 21 Transaction

Computer Science 425 Distributed Systems Lecture 21 Transaction Processing and Concurrency Control Reading: Sections 13. 1 -13. 2

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 • MP 2 posted October 5, 2009, on the course website, – Deadline November 6 (Friday) – Demonstration, 4 -6 pm, 11/6/2009 – Sign Up for demonstrations – Friday 4 -6 pm in 216 SC

Example Transaction Client Transaction Server 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

Transaction v Sequence of operations that forms a single step, transforming the server data from one consistent state to another. q 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) v. Transactions’ operations are indivisible (atomic) from the point of view of other transactions v No access to intermediate results/states v Free from interference by other operations But… v. Transactions could run concurrently v Transactions may be distributed

Transaction Failure Modes Transaction: 1. savings. deduct(100) A failure at these points means the customer loses money; we need to restore 2. checking. add(100) 3. mnymkt. deduct(200) 4. checking. add(200) 5. checking. deduct(400) A failure at these points does not cause lost money, but the transaction cannot be repeated 6. dispense(400) 7. commit 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) v Atomicity: All or nothing v Consistency: starting in a consistent state, the transaction ends in a consistent state. v 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. v. Durability: After a transaction has completed successfully, all its effects are saved in permanent storage. v. Data saved in a file will survive if the server process crashes. “To support failure atomicity and durability, objects must be recoverable” v. Atomicity: store tentative object updates (for later undo/redo) v. Durability: store entire results of transactions (all updated objects) to recover from permanent server crashes.

Transactions can be implemented using RPCs/RMIs! Bank Server: Coordinator Interface v. Transactions are managed by a coordinator: open. Transaction() -> 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. close. Transaction(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. abort. Transaction(trans); aborts the transaction. v TID can be passed implicitly (for other operations between open and close) with CORBA v. Transactions are achieved by cooperation between client process, the server, the coordinator, and recoverable objects.

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

ACID - Isolation

Concurrent Transactions: Lost Update Problem v One transaction causes loss of info. for another: consider three account objects 100 a: Transaction T 1 b: 200 c: 300 Transaction T 2 balance = b. get. Balance() b. set. Balance(balance*1. 1) b: 220 b. set. Balance = (balance*1. 1) b: 220 a. withdraw(balance* 0. 1) a: 80 c. withdraw(balance*0. 1) c: 280 T 1/T 2’s update on the shared object, “b”, is lost

Conc. Trans. : Inconsistent Retrieval Prob. v Partial, incomplete results of one transaction are retrieved by another transaction. a: 100 b: 200 Transaction T 1 a. withdraw(100) c: 300 Transaction T 2 a: 00 total = a. get. Balance() total 0. 00 total = total + b. get. Balance 200 b. deposit(100) b: 300 total = total + c. get. Balance 500 T 1’s partial result is used by T 2, giving the wrong result

Concurrency Control: “Serial Equivalence” v 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). a: Transaction T 1 100 c: 300 Transaction T 2 balance = b. get. Balance() b. set. Balance = (balance*1. 1) b: 200 == T 1 (complete) followed by T 2 (complete) b: 220 balance = b. get. Balance() b. set. Balance(balance*1. 1) a. withdraw(balance* 0. 1) b: 242 a: 80 c. withdraw(balance*0. 1) c: 278

Concurrency Control: “Serial Equivalence” v 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). a: Transaction T 1 100 c: 300 Transaction T 2 balance = b. get. Balance() b. set. Balance = (balance*1. 1) b: 200 == T 1 (complete) followed by T 2 (complete) b: 220 balance = b. get. Balance() b. set. Balance(balance*1. 1) a. withdraw(balance* 0. 1) b: 242 a: 80 c. withdraw(balance*0. 1) Pairs of Conflicting Operations c: 278

Conflicting Operations q 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) q. The effect of an operation refers to q. The value of an object set by a write operation q. The result returned by a read operation. q. 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. q. 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 q Why is the above result important? Because: Serial equivalence is the basis for concurrency control protocols for transactions.

Read and Write Operation Conflict Rules Operations of different Conflict transactions read No read write Yes Reason Because the effect of a pair of read operations does not depend on the order in which they are executed Because the effect of a read and a write operation depends on the order of their execution Because the effect of a pair of write operations depends on the order of their execution

Conflicting Operators Example Transaction T 1 Transaction T 2 x= a. read() a. write(20) Conflicting Ops. y = b. read() b. write(30) b. write(x) Nonserially equivalent interleaving of operations 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? )

Inconsistent Retrievals Problem Transaction : V a. withdraw(100) b. deposit(100) a. withdraw(100); Transaction : W a. Branch. branch. Total() $100 total = a. get. Balance() $100 total = total+b. get. Balance() $300 total = total+c. get. Balance() b. deposit(100) $300 Both withdraw and deposit contain a write operation

A Serially Equivalent Interleaving of V and W Transaction V : a. withdraw(100); b. deposit(100) a. withdraw(100); b. deposit(100) Transaction W : a. Branch. branch. Total() $100 total = a. get. Balance() $100 total = total+b. get. Balance() $400 $300 total. . . = total+c. get. Balance()

ACID – Atomic All or Nothing

A Dirty Read When Transaction T Aborts Transaction. T: Transaction. U: a. get. Balance() a. set. Balance(balance + 10) a. get. Balance() a. set. Balance(balance + 20) balance = a. get. Balance() $100 a. set. Balance(balance + 10) $110 balance = a. get. Balance() $110 a. set. Balance(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. get. Balance()) 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 Transaction T: Transaction U: a. set. Balance(105) a. set. Balance(110) a. set. Balance(105) $100 $105 a. set. Balance(110) $110 • Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction.

Premature Writes Transaction T: Transaction U: a. set. Balance(105) a. set. Balance(110) a. set. Balance(105) $100 $105 a. set. Balance(110) $110 • Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction. q The before image of T’s write is $100. q The before image of U’s write is $105. q If T commits and U aborts $105 (ok) q If U commits then T aborts $100 (not ok - $110 would be the correct value) q If T aborts then U aborts $105 (not ok - $100 would be the correct value) q 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. set. Balance() until T has committed or aborted

Example Transaction – Need Concurrency Control 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

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

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