1. Carnegie Mellon Carnegie Mellon Univ. Dept. of Computer Science 15-415 - Database Applications C. Faloutsos Concurrency control

2. Carnegie Mellon 15-415 - C. Faloutsos2 General Overview Relational model - SQL Functional Dependencies & Normalization Physical Design &Indexing Query optimization Transaction processing –concurrency control –recovery

3. Carnegie Mellon 15-415 - C. Faloutsos3 Transactions - dfn = unit of work, eg. move $10 from savings to checking Atomicity (all or none) Consistency Isolation (as if alone) Durability recovery concurrency control

4. Carnegie Mellon 15-415 - C. Faloutsos4 Concurrency – overview why we want it? what does it mean ‘correct’ interleaving? –precedence graph how to achieve correct interleavings automatically? –concurrency control

5. Carnegie Mellon 15-415 - C. Faloutsos5 Problem concurrent access to data (consider ‘lost update’ problem) how to solve it?

6. Carnegie Mellon 15-415 - C. Faloutsos6 Read(N) Lost update problem – no locks time

7. Carnegie Mellon 15-415 - C. Faloutsos7 Solution – part 1 locks! (most popular solution) lock manager: grants/denies lock requests

8. Carnegie Mellon 15-415 - C. Faloutsos8 Lost update problem – with locks time T1 lock(N) Read(N) N=N-1 Write(N) Unlock(N) T2 lock(N) lock manager grants lock denies lock T2: waits grants lock to T2 Read(N)...

9. Carnegie Mellon 15-415 - C. Faloutsos9 Locks but, what if we all just want to read ‘N’?

10. Carnegie Mellon 15-415 - C. Faloutsos10 Solution – part 1 Locks and their flavors –exclusive (or write-) locks –shared (or read-) locks – compatibility matrix T2 wants T1 has SX S X

11. Carnegie Mellon 15-415 - C. Faloutsos11 Solution – part 1 transactions request locks (or upgrades) lock manager grants or blocks requests transactions release locks lock manager updates lock-table

12. Carnegie Mellon 15-415 - C. Faloutsos12 Solution – part 2 locks are not enough – eg., ‘inconsistent analysis’

13. Carnegie Mellon 15-415 - C. Faloutsos13 ‘Inconsistent analysis’ Precedence graph? time

14. Carnegie Mellon 15-415 - C. Faloutsos14 ‘Inconsistent analysis’ – w/ locks time T1 L(A) Read(A)... U(A) T2 L(A).... L(B).... the problem remains! Solution??

15. Carnegie Mellon 15-415 - C. Faloutsos15 General solution: Protocol(s) Most popular protocol: 2 Phase Locking (2PL)

16. Carnegie Mellon 15-415 - C. Faloutsos16 2PL X-lock version: transactions issue no lock requests, after the first ‘unlock’ THEOREM: if all transactions obey 2PL -> all schedules are serializable

17. Carnegie Mellon 15-415 - C. Faloutsos17 2PL – example ‘inconsistent analysis’ – why not 2PL? how would it be under 2PL?

18. Carnegie Mellon 15-415 - C. Faloutsos18 2PL – X/S lock version transactions issue no lock/upgrade request, after the first unlock/downgrade In general: ‘growing’ and ‘shrinking’ phase

19. Carnegie Mellon 15-415 - C. Faloutsos19 2PL – observations -limits concurrency -may lead to deadlocks -2PLC (keep locks until ‘commit’)

20. Carnegie Mellon 15-415 - C. Faloutsos20 Concurrency – overview what does it mean ‘correct’ interleaving? –precedence graph how to achieve correct interleavings automatically? concurrency control –locks + protocols 2PL, 2PLC graph protocols multiple granularity locks –

21. Carnegie Mellon 15-415 - C. Faloutsos21 Other protocols than 2-PL – graph -assumption: there is a (hierarchical) ordering on the data items, like, eg., pages of a B-tree A B C

22. Carnegie Mellon 15-415 - C. Faloutsos22 Eg., tree protocol (X-lock version) -a xact can request any item, on its first lock request -from then on, it can only request items for which it holds the parent lock -it can release locks at any time -it can NOT request an item twice

23. Carnegie Mellon 15-415 - C. Faloutsos23 Tree protocol - example T1 T2 L(B) L(D) L(H) U(D) L(E) U(E) L(D) U(B) U(H) L(G) U(D) U(G) GIH FED CB A -2PL? -‘correct’?

24. Carnegie Mellon 15-415 - C. Faloutsos24 Tree protocol -equivalent to 2PL? -deadlocks?

25. Carnegie Mellon 15-415 - C. Faloutsos25 More protocols -lock granularity – field? record? page? table? -Pros and cons? -(Ideally, each transaction should obtain a few locks)

26. Carnegie Mellon 15-415 - C. Faloutsos26 Multiple granularity Eg: attr1 attr2 record-nrecord2record1 Table2 Table1 DB

27. Carnegie Mellon 15-415 - C. Faloutsos27 what types of locks? X/S locks for leaf level + ‘intent’ locks, for higher levels IS: intent to obtain S-lock underneath IX: intent.... X-lock... S: shared lock for this level X: ex- lock for this level SIX: shared lock here; + IX

28. Carnegie Mellon 15-415 - C. Faloutsos28 Protocol -each xact obtains appropriate lock at highest level -proceeds to desirable lower levels

29. Carnegie Mellon 15-415 - C. Faloutsos29 Compatibility matrix T2 wants T1 has ISIXSSIXX IS IX S SIX X

30. Carnegie Mellon 15-415 - C. Faloutsos30 Conclusions -‘ACID’ for transactions -concurrency: -serializability (precedence graph) -one (popular) solution: locks + -2PL(C) protocol -graph protocols; multiple gran.