1. Concurrency Control

2. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Transaction Processing and CC Physical Design Indexing Query Processing and Optimization

3. Transaction Concept A transaction is a unit of program execution that accesses and possibly updates various data items. A transaction must see a consistent database. During transaction execution the database may be inconsistent. When the transaction is committed, the database must be consistent. State 1State 2

4. ACID Properties Atomicity. Either all operations of the transaction are properly reflected in the database or none are. Consistency. Execution of a transaction in isolation preserves the consistency of the database. Isolation. Each transaction must be unaware of other concurrently executing transactions. Durability. After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. To preserve integrity of data, the database system must ensure:

5. AC[I]D Isolation  Concurrent xctions unaware of each other How?  Serial execution of transactions  Poor Throughput and response time  Ensure concurrency  Prevent “bad” concurrency (pessimistic)  Recognize “bad” concurrency, fix (optimistic)  Qualify concurrency through analysis of “schedules”

6. Review - Schedules An interleaving of xction operations T1 1 2 3 T2 A B C D T1 1 2 3 T2 A B C D A schedule for T1,T2 Inter ops: may interleave Intra ops: remain in order

7. Review - Schedules Serial Schedule - All operations of each xction executed together, xtions executed in succesion Serializable schedule - Any schedule whose final effect matches that of any serial schedule T1 1 2 3 T2 A B C T1 1 2 3 T2 A B C

8. Example Schedules Constraint: The sum of A+B must be the same Before: 100+50 After: 45+105 T1 read(A) A <- A -50 write(A) read(B) B<-B+50 write(B) T2 read(A) tmp <- A*0.1 A <- A – tmp write(A) read(B) B <- B+ tmp write(B) Transactions: T1: transfers $50 from A to B T2: transfers 10% of A to B =150, consistent Example 1: a “serial” schedule

9. Example Schedule Another “serial” schedule: T1 read(A) A <- A -50 write(A) read(B) B<-B+50 write(B) T2 read(A) tmp <- A*0.1 A <- A – tmp write(A) read(B) B <- B+ tmp write(B) Before: 100+50 After: 40+110 Consistent but not the same as previous schedule.. Either is OK! =150, consistent

10. Example Schedule (Cont.) Another “good” schedule: T1 read(A) A <- A -50 write(A) read(B) B<-B+50 write(B) T2 read(A) tmp <- A*0.1 A <- A – tmp write(A) read(B) B <- B+ tmp write(B) Effect: Before After A 100 45 B 50 105 Same as one of the serial schedules Serializable

11. Example Schedules (Cont.) A “bad” schedule Before: 100+50 = 150 After: 50+60 = 110 !! Not consistent T1 read(A) A <- A -50 write(A) read(B) B<-B+50 write(B) T2 read(A) tmp <- A*0.1 A <- A – tmp write(A) read(B) B <- B+ tmp write(B) Non Serializable

12. Concurrency Control  Ensures interleaving of operations amongst concurrent xctions result in serializable schedules How?  Xction operations interleaved following a protocol

13. Prevent P(S) cycles from occurring using a concurrency control manager: ensures interleaving of operations amongst concurrent xctions only result in serializable schedules. T 1 T 2 ….. T n CC Scheduler DB How to enforce serializable schedules?

14. Concurrency Via Locks Idea:  Data items modified by one xction at a time Locks  Control access to a resource  Can block a xction until lock granted  Two modes:  Shared (read only)  eXclusive (read & write) Xction, txn : short for transaction

15. Granting Locks Requesting locks  Must request before accessing a data item Granting Locks  No lock on data item? Grant  Existing lock on data item?  Check compatibility: –Compatible? Grant –Not? Block xction sharedexclusive sharedYesNo exclusiveNo

16. Lock instructions New instructions - lock-S: shared lock request - lock-X: exclusive lock request - unlock: release previously held lock Example: lock-X(B) read(B) B  B-50 write(B) unlock(B) lock-X(A) read(A) A  A + 50 write(A) unlock(A) lock-S(A) read(A) unlock(A) lock-S(B) read(B) unlock(B) display(A+B) T1 T2

17. Locks Shared locks  SELECT statements (w/o any updates)  Exception In Oracle: select statements do not obtain any shared locks: They read from a committed version (read-consistency protocol). High throughput for analysis-tread-only queries Exclusive locks  Update, delete, insert, and select-for-update  Lock individual rows  Lock Table …

18. Locking Issues Starvation  T1 holds shared lock on Q  T2 requests exclusive lock on Q: blocks  T3, T4,..., Tn request shared locks: granted  T2 is starved! Solution? Do not grant locks if other xction (with incompatible lock) is waiting

19. Locking Issues No xction proceeds: Deadlock - T1 waits for T2 to unlock A - T2 waits for T1 to unlock B T1T2 lock-X(B) read(B) B  B-50 write(B) lock-X(A) lock-S(A) read(A) lock-S(B) Rollback transactions Can be costly... After timeout, one of them is rolled back.

20. Locking Issues Locking itself does not ensure serializability by itself: lock-X(B) read(B) B  B-50 write(B) unlock(B) lock-X(A) read(A) A  A + 50 write(A) unlock(A) lock-S(A) read(A) unlock(A) lock-S(B) read(B) unlock(B) display(A+B) T1 T2 T2 displays 50 less!! Not same as or

21. The Two-Phase Locking Protocol This is a protocol which ensures conflict-serializable schedules. Phase 1: Growing Phase  transaction may obtain locks  transaction may not release locks Phase 2: Shrinking Phase  transaction may release locks  transaction may not obtain locks The protocol assures serializability. It can be proved that the transactions can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock).

22. 2PL Example: T1 in 2PL T1 lock-X(B) read(B) B  B - 50 write(B) lock-X(A) read(A) A  A - 50 write(A) unlock(B) unlock(A) Growing phase Shrinking phase Lock point (final lock in txn) The order of the “lock points” of txns determines the serializability order.

23. 2PL & Serializability Recall: Precedence Graph T1T2T3 read(Q) write(Q) read(R) write(R) read(S) T1 T2 T3 R/W(Q) R/W(R)

24. 2PL & Serializability Recall: Precedence Graph T1T2T3 read(Q) write(S) write(Q) read(R) write(R) read(S) T1 T2 T3 R/W(Q) R/W(R) R/W(S) Cycle  Non-serializable

25. 2PL & Serializability Relation between Growing & Shrinking phase: T 1 G < T 1 S T 2 G < T 2 S T 3 G < T 3 S T1 T2 T3 T1 must release locks for other to proceed T 1 S < T 2 G T 2 S < T 3 G T 3 S < T 1 G T 1 G < T 1 S< T 2 G <T 2 S<T 3 G<T 3 S<T 1 G Not Possible under 2PL! It can be generalized for any set of transactions...

26. 2PL Issues 2PL does not prevent deadlock > 2 xctions involved? - Rollbacks expensive T1T2 lock-X(B) read(B) B  B-50 write(B) lock-X(A) lock-S(A) read(A) lock-S(B)

27. 2PL Issues: Cascading Rollbacks T1T2T3 lock-X(A) read(A) lock-S(B) read(B) write(A) unlock(A) lock-X(A) read(A) write(A) unlock(A) lock-S(A) read(A) T2, T3 need to be rolled back because T1 failed

28. The Two-Phase Locking Protocol (Cont.) Two-phase locking does not ensure freedom from  deadlocks,  cascading rollbacks Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol called strict two-phase locking. Here a transaction must hold all its exclusive locks till it commits/aborts. Rigorous two-phase locking is even stricter: here all locks are held till commit/abort. In this protocol transactions can be serialized in the order in which they commit.

29. 2PL Variants Strict two phase locking  Exclusive locks must be held until xction commits Ensures data written by xction can’t be read by others Prevents cascading rollbacks

30. Strict 2PL & No Cascading Rollbacks T1T2T3 lock-X(A) read(A) lock-S(B) read(B) write(A) unlock(A) lock-X(A) read(A) write(A) unlock(A) lock-S(A) read(A) Strict 2PL Does not Allow that (need to Unlock at Commit time)

31. Strict 2PL Ensures any data written by uncommited xction not read by another Strict 2PL would prevent T2 and T3 from reading A  T1 & T2 wouldn’t rollback if T1 does

32. 2PL Variants Strict 2PL  Only Exclusive locks are held till txn commits Rigorous two-phase locking  Exclusive and shared locks too must be held until xction commits  Order the txns commit is serializability order Both variants often used in DB systems  Strict 2PL

33. Lock Conversions Two-phase locking with lock conversions: – First Phase:  can acquire a lock-S on item  can acquire a lock-X on item  can convert a lock-S to a lock-X (upgrade) – Second Phase:  can release a lock-S  can release a lock-X  can convert a lock-X to a lock-S (downgrade) This protocol assures serializability. But still relies on the programmer to insert the various locking instructions.

34. Automatic Acquisition of Locks A transaction T i issues the standard read/write instruction, without explicit locking calls. The operation read(D) is processed as: if T i has a lock on D then read(D) else begin if necessary wait until no other transaction has a lock-X on D grant T i a lock-S on D; read(D) end

35. Automatic Acquisition of Locks (Cont.) write(D) is processed as: if T i has a lock-X on D then write(D) else begin if necessary wait until no other trans. has any lock on D, if T i has a lock-S on D then upgrade lock on D to lock-X else grant T i a lock-X on D write(D) end; All locks are released after commit or abort

36. Implementation of Locking A lock manager can be implemented as a separate process to which transactions send lock and unlock requests The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock) The requesting transaction waits until its request is answered The lock manager maintains a data-structure called a lock table to record granted locks and pending requests The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked

37. Lock Table Black rectangles indicate granted locks, white ones indicate waiting requests Lock table also records the type of lock granted or requested New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted If transaction aborts, all waiting or granted requests of the transaction are deleted  lock manager may keep a list of locks held by each transaction, to implement this efficiently Granted Waiting