1. Introduction to Database Systems1 Concurrency Control CC.Lecture 1

2. Introduction to Database Systems2 Why Have Concurrent Processes? v Better transaction throughput, response time v Done via better utilization of resources: –while one processes is doing a disk read, another can be using the CPU or reading another disk  DANGER!  DANGER! Concurrency could lead to incorrectness! –Must carefully manage concurrent data access –There’s (much!) more here than the usual OS tricks!

3. Introduction to Database Systems3 Transactions v Basic concurrency/recovery concept: a Transaction (Xact) –a sequence of many actions (hence the name) which are considered to be one atomic unit of work v DBMS “actions”: –reads, writes –special actions: commit, abort –for now, assume reads and writes are on tuples; we’ll revisit this assumption later.

4. Introduction to Database Systems4 ACID The ACID Properties v A v A tomicity: all actions in the Xact happen, or none happen v C v C onsistency: if each Xact is consistent, and the DB starts consistent, it ends up consistent v I v I solation: execution of one Xact is isolated from that of other Xacts v D v D urability: if a Xact commits, its effects persist

5. Introduction to Database Systems5 Passing the ACID Test v Concurrency Control –guarantees Consistency and Isolation v Logging and Recovery –guarantees Atomicity and Durability v We’ll do C. C. first: –what problems could arise? –what is acceptable behavior? –how do we guarantee acceptable behavior?

6. Introduction to Database Systems6 Schedules v Schedule: An interleaving of actions from a set of Xacts, where the actions of any 1 Xact are in the original order. –represents some actual sequence of database actions –example: R 1 (A), W 1 (A), R 2 (B), W 2 (B), R 1 (C), W 1 (C) –in a complete schedule, each Xact ends in Commit or Abort  Initial State + Schedule  Final State

7. Introduction to Database Systems7 Acceptable Schedules v One sensible “isolated, consistent” schedule: –run Xacts one at a time, in a series. –this is called a serial schedule –NOTE: different serial schedules can have different final states; why? all are “OK”. v Serializable schedules: –final state is what some serial schedule would have produced –aborted Xacts are not part of schedule, ignore them for now.

8. Introduction to Database Systems8 Serializability Violations v Two actions conflict when 2 xacts access the same item: –W-R conflict: T2 reads something T1 wrote –R-W and W-W are similar v WR conflict (dirty read) –result is not equal to any serial execution! transfer $100 from A to B add 6% interest to A & B Database is inconsistent!

9. Introduction to Database Systems9 More Conflicts v RW Conflicts (Unrepeatable Read) –T2 overwrites what T1 read –If T1 reads it again, it will see something new! u Example when this would happen? u The increment/decrement example –Again, not equivalent to a serial execution v WW Conflicts (Overwriting Uncommited Data) –T2 overwrites what T1 wrote u Example: 2 Xacts to update items to be kept equal –Usually occurs in conjunction w/other anomalies u unless you have “blind writes”

10. Introduction to Database Systems10 Now, Aborted Transactions v Serializable schedule: equivalent to a serial schedule of committed Xacts –as if aborted Xacts never happened v Two Issues: –How does one undo the effects of an xact? u we’ll cover this in logging/recovery –What if another Xact sees these effects??

11. Introduction to Database Systems11 Cascading Aborts v Abort of T1 requires abort of T2! –Cascading Abort v A Recoverable Schedule is one in which cascading abort cannot happen. –i.e. a Xact commits only after all the Xacts it “depends on” (i.e. it reads from) commit v What about WW & aborts? –T2 overwrites a value that T1 writes –T1 aborts: its “remembered” values are restored –lose T2’s write! We will see how to solve this, too.

12. Introduction to Database Systems12 Degrees of Consistency v 3 distinct notions of consistency v Defn 1: Absence of anomalies –purely logical definition (thou shalt not steal!) v Defn 2: Analysis of conflicts in schedules –post-priori detection (did something get stolen?) v Defn 3: Using locking –one evaluation procedure (install burglar alarm)

13. Introduction to Database Systems13 Consistency: Defn 1 v Degree 3 (serializable, recoverable schedule) –No overwrites of uncommitted updates (W-W) –No cascading aborts (I.e. recoverable schedules) –No dirty reads (W-R) –No unrepeatable reads (R-W) v Degree 2 : Degree 3, but unrepeatable reads –Also called “Cursor Stability” v Degree 1 : Degree 2, but dirty reads v Degree 0 : Degree 1, but unrecoverable

14. Introduction to Database Systems14 Precedence Graph v A Precedence (or Serializability) graph: –node for each commited Xact –arc from Ti to Tj if an action of Ti precedes and conflicts with an action of Tj v T1 transfers $100 from A to B, T2 adds 6% –R 1 (A), W 1 (A), R 2 (A), W 2 (A), R 2 (B), W 2 (B), R 1 (B), W 1 (B) T1T2

15. Introduction to Database Systems15 Conflict Serializability v 2 schedules are conflict equivalent if: –they have the same sets of actions –each pair of conflicting actions is ordered in the same way v A schedule is conflict serializable if it is conflict equivalent to a serial schedule –note: some serializable schedules are not conflict serializable!

16. Introduction to Database Systems16 Defn 2 (ignore Recoverability) v Based on analysis of complete schedules. v Actions a1(T1) and a2(T2) on same data object. v T1 <<< T2 if (a1,a2) = (W,W),(W,R) or (R,W) v T1 << T2 if (a1,a2) = (W,W) or (W,R) v T1 < T2 if (a1,a2) = (W,W) v Degree 3 : <<< graph is acyclic v Degree 2 : << graph is acyclic v Degree 1 : < graph is acyclic

17. Introduction to Database Systems17 Locking: A Technique for C. C. v Concurrency control usually done via locking v Lock info maintained by a “lock manager” –stores (XID, RID, Mode) triples u (this is a simplistic view for now) –Mode  {S,X} –Lock compatibility table v If a Xact can’t get a lock, it is suspended until it can be granted -- SX S X     

18. Introduction to Database Systems18 Two-Phase Locking (2PL) v 2PL: –if T wants to read an object, first obtains an S lock –if T wants to modify an object, first obtains X lock –If T releases any lock, it can acquire no new locks! v Locks are automatically obtained by DBMS v Guarantees Serializability!! –why? Time # of locks lock point growing phase shrinking phase

19. Introduction to Database Systems19 Strict 2PL v Strict 2PL: –if T wants to read an object, first obtains an S lock –if T wants to modify an object, first obtains X lock –Hold all locks until end of transaction v Guarantees recoverable schedule, too! –also avoids WW problems! Time # of locks

20. Introduction to Database Systems20 Defn 3: based on locking v Degree 3 –long X lock on data written –long S lock on data read v Degree 2 : –long X lock on data written –short S lock on data read v Degree 1 : –long X lock on data written v Degree 0 : –short X lock on data written

21. Introduction to Database Systems21 Conflict Serializability & Graphs v Theorem: A schedule is conflict serializable iff its precedence graph is acyclic. v Theorem: 2PL ensures that the precedence graph will be acyclic! v Strict 2PL improves on this by avoiding cascading aborts, problems with undoing WW conflicts v Strict 2PL: The Magic Bullet for C. C.! –All we need is to enforce Strict 2PL, and life is good. Right?

22. Introduction to Database Systems22 Lock Manager Implementation v Question 1: what are we locking? –tuples, pages, tables? –finer granularity increases concurrency, but also increases locking overhead v Question 2: How do you “lock” something?? v Lock Table: a hash table of Lock Entries: –Lock Entry u OID u Lock Mode u List: Xacts holding lock u List: Wait Queue

23. Introduction to Database Systems23 Handling a Lock Request Lock Request (XID, OID, Mode) Currently Locked? Grant Lock Empty Wait Queue? Currently X? Mode==X Mode==S No Yes No Yes Put on Queue Yes No

24. Introduction to Database Systems24 More Lock Manager Logic v On lock release (OID, XID): –update list of Xacts holding lock –examine head of wait queue –if Xact there can run, add it to list of Xacts holding lock (change mode as needed) –repeat until head of wait queue cannot be run v Think about this scenario: –T1 locks A in S mode, T2 request X lock on A, T3 requests S lock on A v Note: lock request handled atomically! –via latches (i.e. semaphore/mutex; OS stuff)

25. Introduction to Database Systems25 Deadlock v Deadlocks : T1 waits for T2 and vice versa. –X1(A), X2(B), S1(B), S2(A) v Cycle of lock dependencies v Two basic strategies –Prevention : preempt the possibility of deadlock –Detection: handle it when it happens v Simple prevention strategy: –always access data items in a specific order

26. Introduction to Database Systems26 Deadlock Prevention v Assign a timestamp to each Xact as it enters the system. “Older” Xacts have priority. v Assume Ti requests a lock, but Tj holds a conflicting lock –Wait-Die: If Ti has higher priority, it waits; else Ti aborts –Wound-Wait: If Ti has higher priority, abort Tj; else Ti waits –both guarantee deadlock-free behavior! why? –too much wasted work X1(A), X2(B), S1(B), S2(A)

27. Introduction to Database Systems27 An Alternative to Prevention v In theory, deadlock can involve many transactions –T1 waits-for T2 waits-for T3...waits-for T1 v Fact: in practice, most “deadlock cycles” involve only 2 transactions v Don’t need to prevent deadlock! –what’s the problem with prevention? v Allow it to happen, then notice it and fix it –deadlock detection

28. Introduction to Database Systems28 Deadlock Detection v Lock Mgr maintains a “Waits-for” graph –node for each Xact –arc from Ti to Tj if Tj holds a lock and Ti is waiting for it v Periodically check graph for cycles –How often? Every request? v Kill some “victim” Xact to break the cycle –Choice of victim: Least work? Fewest locks? –Furthest from completion? Fewest restarts?

29. Introduction to Database Systems29 Prevention vs. Detection v Prevention might abort too many Xacts v Detection might tie up resources for a while v The usual answer: –detection is the winner –deadlocks are pretty rare –if you get a lot of deadlocks, reconsider your schema/workload! v Simple detection hack: time-outs –T1 made no progress for a while? Kill it.

30. Introduction to Database Systems30 Multiple-Granularity Locks v Hard to decide what granularity to lock (tuples vs. pages vs. tables) v Shouldn’t have to decide! v Data “containers” are nested Tables Pages Tuples Database contains

31. Introduction to Database Systems31 Solution: New Lock Modes, Protocol v Allow people to lock at each level, but with a special protocol using new “intention” locks: -- ISIX -- IS IX      SX   S X      v Before locking an item, you must set “intention locks” on all its ancestors v For unlock, go from specific to general (i.e. bottom-up) 

32. Introduction to Database Systems32 Summary of C.C. v Concurrency control key to a DBMS –more than mutexes v Transactions and the ACID properties –C & I are handled by concurrency control –A & D coming soon with logging & recovery v Conflicts arise when two Xacts access the same object, and one of the Xacts is modifying it v Serial execution is our model of correctness

33. Introduction to Database Systems33 Summary, cont. v Serializability allows us to “simulate” serial execution with better performance v 2PL: a simple mechanism to get serializability –Strict 2PL also gives us recoverability v Lock manager module automates 2PL so that only the access methods worry about it –lock table is a big main-memory hash table v Deadlocks are possible, and typically a deadlock detector is used.