1 / 16

Computer Science 425 Distributed Systems

Computer Science 425 Distributed Systems. Lecture 17 Transaction Processing (II) Reading: Sections 13.1-13.3. Concurrency Control: “Serial Equivalence”.

sofia
Download Presentation

Computer Science 425 Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Science 425Distributed Systems Lecture 17 Transaction Processing (II) Reading: Sections 13.1-13.3

  2. Concurrency Control: “Serial Equivalence” • 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) 200 300 100 b: c: a: == T1 (complete) followed by T2 (complete) 220 b: 242 b: 80 a: 278 c: Pairs of Conflicting Operations

  3. 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.

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

  5. Non-serially equivalent interleaving of operations Conflicting Ops. 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?)

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

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

  8. Effect of Transaction Aborts on Serializability

  9. Transaction T : Transaction U : a.getBalance() a.getBalance() a.setBalance(balance + 10) 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 A Dirty Read When Transaction T Aborts • Transaction U here encounters a dirty read from another transaction that aborts.

  10. How to avoid dirty reads • Two ways to avoid dirty reads (at run-time): • U could delay running the conflicting operation (e.g., a.getBalance()) until T commits or aborts • 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).

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

  12. Transaction T : Transaction U : a.setBalance(105) a.setBalance(110) $100 a.setBalance(105) $105 a.setBalance(110) $110 Premature Writes • 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

  13. Nested Transactions T: top-level Trans T2: Subtrans. T1: Subtrans. • For performance reasons, a transaction can be composed of other component subtransactions • Subtransactions : transaction is somewhat like thread : process, except that there is a hierarchy and dependencies among subtransactions. • A subtransaction appears atomic to its parent, w.r.t. failure and concurrent access. • Subtransaction : transaction is similar to procedure : program. • Subtransactions on the same level can run concurrently. • Subtransactions can commit or abort independently. T21: Subtrans. T12: Subtrans. T11: Subtrans.

  14. Nested Transactions Commitment Rules • A transaction can commit/abort only after all its children subtransactions have completed. • A subtransaction decides to provisionally commit (PROV) or abort (latter always final). • When a subtransaction aborts, all its children are also aborted. • When a subtransaction aborts, the parent can decide whether to abort or commit itself. • When the top-level trans. commits, all subtrans that have PROVed also commit.

  15. T : top-level transaction T = openSubTransaction T = openSubTransaction 1 2 commit T : T : 1 2 openSubTransaction openSubTransaction openSubTransaction prov. commit prov. commit T T : T : : 21 11 12 openSubTransaction prov. commit prov. commit abort T : 211 prov.commit Nested transactions Transfer $100 from account B  A:: b.withdraw(100); a.deposit(100); a.deposit(100); b.withdraw(100); CORBA supports both flat and nested transactions

  16. Summary • Transactions an important concept • ACID properties • Serial Equivalence and Conflicting Operations • Ensuring the aborts do not violate ACID • Nested Transactions • MP1 due on Sunday Oct 21 • HW4 out today due at month-end • Reading for next lecture: Sections 13.4 – 13.7

More Related