Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Databases: Concurrency Control


Published on

Databases: Concurrency Control

  1. 1. Concurrency Control
  2. 2. Concurrency Control <ul><li>Transaction </li></ul><ul><ul><li>the basic unit of work in a DBMS </li></ul></ul><ul><li>Properties of a transaction </li></ul><ul><ul><li>ATOMICITY </li></ul></ul><ul><ul><li>CONSISTENCY </li></ul></ul><ul><ul><li>INDEPENDENCE </li></ul></ul><ul><ul><li>DURABILITY </li></ul></ul>
  3. 3. A.C.I.D properties (1) <ul><li>Atomicity </li></ul><ul><ul><li>the is the “all or nothing” property ; a transaction is an indivisible unit of work </li></ul></ul>
  4. 4. A.C.I.D properties (1) <ul><li>Consistency </li></ul><ul><ul><li>transactions transform the DB from one consistent state to another consistence state </li></ul></ul>
  5. 5. A.C.I.D properties (2) <ul><li>Independence </li></ul><ul><ul><li>transactions execute independently of one another i.e. the partial effect of one transaction is not visible to other transactions. </li></ul></ul>
  6. 6. A.C.I.D properties (2) <ul><li>Durability (aka Persistence) </li></ul><ul><ul><li>the effect of a successfully completed (i.e. committed) transaction are permanently recorded in the DB and cannot be undone. </li></ul></ul>
  7. 7. Example Transaction <ul><li>Funds transfer : </li></ul><ul><li>begin transaction T1 </li></ul><ul><li>read balance1 </li></ul><ul><li>balance1 = balance1 - 100 </li></ul><ul><li>if balance1 < 0 </li></ul><ul><ul><li>then print “insufficient funds” </li></ul></ul><ul><ul><li>abort T1 </li></ul></ul><ul><li>end </li></ul><ul><li>write balance1 </li></ul><ul><li>read balance2 </li></ul><ul><li>balance2 = balance2 + 100 </li></ul><ul><li>write balance2 </li></ul><ul><li>commit T1 </li></ul>
  8. 8. Discussing the Example <ul><li>Effect of the abort is to rollback the transaction and undo changes it has made on the DB </li></ul><ul><li>in this example, transaction was not written to the DB prior to abort and so no undo is necessary </li></ul>
  9. 9. Problems with Concurrency <ul><li>Concurrent transaction can cause three kinds of database problems </li></ul><ul><ul><li>Lost Update </li></ul></ul><ul><ul><li>Violation of Integrity Constraints </li></ul></ul><ul><ul><li>Inconsistent Retrieval </li></ul></ul>
  10. 10. Lost Update <ul><li>Apparently successful updates can be overwritten be other transactions </li></ul>Begin transaction T1 read balance [ 100 ] balance = balance - 100 if balance < 0 print “insufficient funds” abort T1 end write balance [ 0 ] Initial Balance = 100 Begin transaction T2 read balance [ 100 ] balance = balance + 100 write balance [ 200 ] commit T2
  11. 11. Violation of Integrity Constraints
  12. 12. Violation of Integrity Constraints <ul><li>Begin transaction T3 </li></ul><ul><li>read schedule where date = 4/4/01 </li></ul><ul><li>read surgeon where = schedule.surgeon and surgeon.operation = “Appendectomy” </li></ul><ul><li>if not found then abort T3 </li></ul><ul><li>schedule.operation = “Appendectomy” </li></ul><ul><li>commit T3 </li></ul><ul><li>Begin transaction T4 </li></ul><ul><li>read schedule where date = 4/4/01 </li></ul><ul><li>read surgeon where = ‘Tom’ </li></ul><ul><li>if not found then abort T4 </li></ul><ul><li>surgeon.surgeon = ‘Tom’ </li></ul><ul><li>commit T4 </li></ul>
  13. 13. Violation of Integrity Constraints
  14. 14. Inconsistent Retrieval ( Dirty Reads ) <ul><li>Most concurrency control systems focus on the transaction which update the DB since they are the only ones which can corrupt the DB </li></ul><ul><li>If transaction are allowed to read the partial results of incomplete transactions, they can obtain an inconsistent view of the DB ( dirty or unrepeatable reads ) </li></ul>
  15. 15. Inconsistent Retrieval ( Dirty Reads ) <ul><li>T1 </li></ul><ul><li>begin transaction T1 </li></ul><ul><li>read BalanceX </li></ul><ul><li>BalanceX = BalanceX - 100 </li></ul><ul><li>if BalanceX < 0 then </li></ul><ul><li>begin </li></ul><ul><li>print ‘insufficient funds’ </li></ul><ul><li>abort T1 </li></ul><ul><li>end </li></ul><ul><li>write BalanceX </li></ul><ul><li>read BalanceY </li></ul><ul><li>BalanceY = BalanceY + 100 </li></ul><ul><li>write BalanceY </li></ul><ul><li>commit T1 </li></ul><ul><li>T2 </li></ul><ul><li>begin transaction T2 </li></ul><ul><li>read BalanceX </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>: </li></ul><ul><li>read BalanceY </li></ul><ul><li>commit T2 </li></ul>
  16. 16. Concurrency Control <ul><li>Schedules and Serialisation </li></ul><ul><li>Order in a schedule is VERY important </li></ul><ul><li>S = [R1(x), R2(x), W1(x), W2(x)] </li></ul><ul><li>so, is it O.K. to do reads before or after writes, e.g. Lost Update Problem </li></ul>
  17. 17. Conflicting Operations <ul><li>If two transactions only read a data item, they do not conflict and order is not important. </li></ul><ul><li>If two transactions either read or write completely separate data items, they do not conflict and order is not important. </li></ul><ul><li>If one transactions writes a data item and another transaction reads or writes the same data item, the order of execution is important. </li></ul>
  18. 18. Serial Schedule <ul><li>What is a serial schedule ? </li></ul><ul><li>S = [R1(X), W1(X), R2(X), W2(X), R3(X)] </li></ul>
  19. 19. Serialisable Schedule <ul><li>What is a serialisable schedule ? </li></ul><ul><li>S = [R1(x), R2(x),W1(x), R3(x), W2(x)] </li></ul><ul><li>Is this serialisable ? </li></ul>
  20. 20. General Solution <ul><li>Constrained Write Rule </li></ul><ul><li>Transaction should always Read before they Write </li></ul>
  21. 21. Rules for Equivalence of Schedules <ul><li>Each read operation must read the same values in both schedules; this effectively means that those values must have been produced by the same write operation the both schedules </li></ul><ul><li>The final state of the database must be the same in both schedules; thus the final write operation on each data item is the same in both schedules </li></ul>
  22. 22. Try these... <ul><li>[R1(x), W1(x), R2(x), W2(x)] </li></ul><ul><li>[R1(x), R2(x), W1(x), W2(x)] </li></ul><ul><li>[R1(x), R3(y), R2(x), W2(z), W2(y), W1(x), R2(y), W1(z)] </li></ul>
  23. 23. Conflicting Operations <ul><li>Read operations cannot conflict with one and other, thus the order of read operations does not matter. </li></ul><ul><li>i.e. [R1(x), R2(x)] = [R2(x), R1(x)] </li></ul><ul><li>but </li></ul><ul><li>[R1(x),W1(x),R2(x)] != [R1(x), R2(x), W1(x)] </li></ul>
  24. 24. Conflicting Operations <ul><li>In terms of schedule equivalence, it is the ordering of CONFLICTING operators which must be the same in both schedules </li></ul><ul><li>The conflict between read and write operations is called a read-write conflict and the conflict between two writes is called a write-write conflict . </li></ul>
  25. 25. Concurrency Control Techniques <ul><li>There are three basic concurrency control techniques : </li></ul><ul><li>Locking Methods </li></ul><ul><li>Timestamp Methods </li></ul><ul><li>Optimistic Methods </li></ul>