Advanced Database Systems

1. Sekolah Tinggi Ilmu Statistik (STIS) Advanced Database Systems Dr. Said Mirza Pahlevi, M.Eng.

2. Transaction Management 2 Lecture 3 Dr. Said Mirza Pahlevi, M.Eng.

3. Today’s Lecture Last time lecture • Concurrency Control • Meaning of serializability • Conflict serializability • View serializability • Locking Methods Dr. Said Mirza Pahlevi, M.Eng.

4. View Serializability Second Subtopic (from previous lecture) Dr. Said Mirza Pahlevi, M.Eng.

5. View Serializability • Conflict equivalent ----- View equivalent • Conflict serializable ----- View serializable Dr. Said Mirza Pahlevi, M.Eng.

6. Motivating example Schedule Q T1T2T3 Read(A) Write(A) Write(A) Write(A) t1: t2: t3: t4: Dr. Said Mirza Pahlevi, M.Eng.

7. P(Q): T1 T2 T3 Motivating Example Same as Q = r1(A) w2(A) w1(A) w3(A)  Not conflict serializable! Dr. Said Mirza Pahlevi, M.Eng.

8. Compare Q to Serial Schedule (S) Q T1T2T3 Read(A) Write(A) Write(A) Write(A) ST1T2T3 Read(A) Write(A) Write(A) Write(A) • T1reads same thing in QdanS • T2,T3 read same thing (nothing?) • After Q or S, DB is left in same state  So what is wrong with Q? Dr. Said Mirza Pahlevi, M.Eng.

9. View Equivalent  means “reads value produced by” • Two schedules S1 and S2 are view equivalent: • IF in S1: wj(A) ri(A), THEN in S2: wj(A) ri(A) • IF in S1: ri(A) reads initial DB value, THEN in S2: ri(A) also reads initial DB value • IF in S1: Ti does last write on A, THEN in S2: Ti also does last write on A Dr. Said Mirza Pahlevi, M.Eng.

10. View Serializability Schedule is view serializable if it is view equivalent to a serial schedule. Offers less stringent definition of schedule equivalence than conflict serializability. Every conflict serializable schedule is view serializable, although converse is not true. It can be shown that any view serializable schedule that is not conflict serializable contains one or more blind writes. Dr. Said Mirza Pahlevi, M.Eng.

11. View Serializable Test 1. Add final transaction Tf that reads all DB • e.g.: S = …..W1(A)…….. W2(A)… Rf(A) last A write add Dr. Said Mirza Pahlevi, M.Eng.

12. View Serializable Test 2. Add initial transaction Tbthat writes all DB • e.g.: S = wb(A) ... r1(A) … w2(A) … add Dr. Said Mirza Pahlevi, M.Eng.

13. View Serializable Test 3. Create labeled precedence (LP) graph of S: (a) If wi(A) rj(A) in S, add TiTj 0  means “reads value produced by” Dr. Said Mirza Pahlevi, M.Eng.

14. View Serializable Test (b) For each wi(A) rj(A) do consider eachwk(A): [TkTb] (i) IF TiTb TjTfTHEN insert TkTi some new p TjTk (ii) IF Ti=Tb TjTfTHEN insert TjTk (iii) IF TiTb Tj=TfTHEN insert TkTi p p 0 0 Dr. Said Mirza Pahlevi, M.Eng.

15. View Serializable Test 4. Check if LP(S) is acyclic;if so, then S is view serializable - For each pair of “p” arcs (p  0), choose one Dr. Said Mirza Pahlevi, M.Eng.

16. Example 1: View Serializable (VS) Check if Q is viewserializable: Q = r1(A) w2(A) w1(A) w3(A) Q’ = wb(A) r1(A) w2(A) w1(A) w3(A) rf(A)   T1 rule 3a rule 3b (ii) 0 0 rule 3b (iii) 0 Tb T2 Tf 0 0 0 Acyclic graph!! Q is VS T3 Dr. Said Mirza Pahlevi, M.Eng.

17. Example 2: View Serializable (VS)    Z=wb(A) r1(A) w2(A) r3(A) w1(A) w3(A) rf(A) T1 rule 3a 0 rule 3b (i) 0 1 rule 3b (ii) 0 T2 Tf Tb rule 3b (iii) 0 0 1 0 0 do not pick this one of “1” pair T3 Acyclic graph, so Z is VS (equivalent to Tb T1 T2 T3 Tf) Dr. Said Mirza Pahlevi, M.Eng.

18. Recoverability Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine recoverability of transactions within schedule. If transaction fails, atomicity requires effects of transaction to be undone Durability states that once transaction commits, its changes cannot be undone (without running another, compensating, transaction). Dr. Said Mirza Pahlevi, M.Eng.

19. If T9 Rollback Instead of Commit Dr. Said Mirza Pahlevi, M.Eng. We should undo T10 but T10 has committed the transaction (durability does not allow it). This is a non-recoverable schedule

20. Recoverable Schedule A schedule where, for each pair of transactions Ti and Tj, if Tj reads a data item previously written by Ti, then the commit operation of Ti precedes the commit operation of Tj. If commit operation of Tj precedes the commit operation of Ti then it is unrecoverable, because of the durability. Dr. Said Mirza Pahlevi, M.Eng.

21. Locking Methods Third Topic Dr. Said Mirza Pahlevi, M.Eng.

22. Concurrency Control Techniques • Two basic concurrency control techniques: • Locking, • Timestamping. • Both are conservative approaches: delay transactions in case they conflict with other transactions. • Optimistic methods assume conflict is rare and only check for conflicts at commit. Dr. Said Mirza Pahlevi, M.Eng.

23. Locking Transaction uses locks to deny access to other transactions and so prevent incorrect updates. Most widely used approach to ensure serializability. Generally, a transaction must claim a shared (read) or exclusive (write) lock on a data item before read or write. Lock prevents another transaction from modifying item or even reading it, in the case of a write lock. Dr. Said Mirza Pahlevi, M.Eng.

24. Locking - Basic Rules If transaction has shared lock on item, it can read but not update item. If transaction has exclusive lock on item, it can both read and update item. Reads cannot conflict, so more than one transaction can hold shared locks simultaneously on same item. Exclusive lock gives transaction exclusive access to that item. Dr. Said Mirza Pahlevi, M.Eng.

25. Locking - Basic Rules Some systems allow transaction to upgrade read lock to an exclusive lock, or downgrade exclusive lock to a shared lock. But this basic rules does not guarantee serializability of schedules by themselves Dr. Said Mirza Pahlevi, M.Eng.

26. Incorrect Locking Schedule Dr. Said Mirza Pahlevi, M.Eng. Valid schedule using basic rules: S = {write_lock(T9, balx), read(T9, balx), write(T9, balx), unlock(T9, balx), write_lock(T10, balx), read(T10, balx), write(T10, balx), unlock(T10, balx), write_lock(T10, baly), read(T10, baly), write(T10, baly), unlock(T10, baly), commit(T10), write_lock(T9, baly), read(T9, baly), write(T9, baly), unlock(T9, baly), commit(T9) }

27. Example - Incorrect Locking Schedule • If at start, balx = 100, baly = 400, result should be: • balx = 220, baly = 330, if T9 executes before T10, or • balx = 210, baly = 340, if T10 executes before T9. • However, result gives balx = 220 and baly = 340. • S is not a serializable schedule. • Problem is that transactions release locks too soon, resulting in loss of total isolation and atomicity. • To guarantee serializability, need an additional protocol concerning the positioning of lock and unlock operations in every transaction. Dr. Said Mirza Pahlevi, M.Eng.

28. Two-Phase Locking (2PL) • Transaction follows 2PL protocol if all locking operations precede first unlock operation in the transaction. • Two phases for transaction: • Growing phase - acquires all locks but cannot release any locks. • Shrinking phase - releases locks but cannot acquire any new locks. Dr. Said Mirza Pahlevi, M.Eng.

29. Preventing Lost Update Problem using 2PL Dr. Said Mirza Pahlevi, M.Eng.

30. Preventing Uncommitted Dependency Problem using 2PL Dr. Said Mirza Pahlevi, M.Eng.

31. Apply 2PL! Dr. Said Mirza Pahlevi, M.Eng.

32. Preventing Inconsistent Analysis Problem using 2PL Dr. Said Mirza Pahlevi, M.Eng.

33. Apply 2PL! Dr. Said Mirza Pahlevi, M.Eng.

34. Cascading Rollback If every transaction in a schedule follows 2PL, schedule is serializable. However, problems can occur with interpretation of when locks can be released. Dr. Said Mirza Pahlevi, M.Eng.

35. Cascading Rollback Dr. Said Mirza Pahlevi, M.Eng. Transactions conform to 2PL. T14 aborts. Since T15 is dependent on T14, T15 must also be rolled back. Since T16 is dependent on T15, it too must be rolled back. This is called cascading rollback. To prevent this with 2PL, leave release of all locks until end of transaction.

36. Deadlock An impasse (kebuntuan) that may result when two (or more) transactions are each waiting for locks held by the other to be released. Dr. Said Mirza Pahlevi, M.Eng.

37. Deadlock • Only one way to break deadlock: abort one or more of the transactions. • Deadlock should be transparent to user, so DBMS should restart transaction(s). • Three general techniques for handling deadlock: • Timeouts. • Deadlock prevention. • Deadlock detection and recovery. Dr. Said Mirza Pahlevi, M.Eng.

38. Timeouts Transaction that requests lock will only wait for a system-defined period of time. If lock has not been granted within this period, lock request times out. In this case, DBMS assumes transaction may be deadlocked, even though it may not be, and it aborts and automatically restarts the transaction. Dr. Said Mirza Pahlevi, M.Eng.

39. Deadlock Prevention • DBMS looks ahead to see if transaction would cause deadlock and never allows deadlock to occur. • Could order transactions using transaction timestamps: • Wait-Die - only an older transaction can wait for younger one, otherwise transaction is aborted (dies) and restarted with same timestamp. • Wound-Wait - only a younger transaction can wait for an older one. If older transaction requests lock held by younger one, younger one is aborted (wounded). Dr. Said Mirza Pahlevi, M.Eng.

40. Wait-Die Transactions given a timestamp when they arrive …. ts(T1) T1 can only wait for T2 if ts(T1)< ts(T2) ...else die Dr. Said Mirza Pahlevi, M.Eng.

41. Wound-Wait Transactions given a timestamp when they arrive … ts(T1) T1 wounds T2 if ts(T1)< ts(T2) else T1 waits “Wound”: T2 rolls back (if it cannot finish in small interval of time) and gives lock to T1 Dr. Said Mirza Pahlevi, M.Eng.

42. Deadlock Detection and Recovery • DBMS allows deadlock to occur but recognizes it and breaks it. • Usually handled by construction of wait-for graph (WFG) showing transaction dependencies: • Create a node for each transaction. • Create edge TiTj, if Ti waiting to lock item locked by Tj. • Deadlock exists if and only if WFG contains cycle. • WFG is created at regular intervals. Dr. Said Mirza Pahlevi, M.Eng.

43. Example - Wait-For-Graph (WFG) Dr. Said Mirza Pahlevi, M.Eng.

44. Granularity of Data Items • Size of data items chosen as unit of protection by concurrency control protocol. • Ranging from coarse to fine: • The entire database • A file • A page (or area or database spaced) • A record • A field value of a record Dr. Said Mirza Pahlevi, M.Eng.

45. Granularity of Data Items • Tradeoff: • Coarser, the lower the degree of concurrency; • Finer, more locking information that is needed to be stored. • Best item size depends on the types of transactions. • What will happen if we use database lock for transaction updating a single record/tuple? • What will happen if we use tuple lock for transaction updating 95% of tuple? Dr. Said Mirza Pahlevi, M.Eng.

46. Hierarchy of Granularity Could represent granularity of locks in a hierarchical structure. Root node represents entire database, level 1s represent files, etc. When node is locked, all its descendants are also locked. DBMS should check hierarchical path before granting lock. Dr. Said Mirza Pahlevi, M.Eng.

47. Levels of Locking If page2 is locked, the record1, record2, field1 and field2 are locked If lock request on record1, check page2, file2 and database Dr. Said Mirza Pahlevi, M.Eng.

48. Intension Lock Intention lock could be used to lock all ancestors of a locked node. Intention locks can be read or write. Applied top-down, released bottom-up.

49. Intention Lock If another transaction requests a lock on any of descendants of the locked node, the DBMS checks the hierachical path from the root to the requested node. A transaction may request a lock on a node and a descendant of the node is already locked. Dr. Said Mirza Pahlevi, M.Eng.

50. Locking Level + 2PL No lock can be granted once any node has been locked. No node may be locked until its parent is locked by an intention lock. No node may be unlocked until all its descendants are unlocked Dr. Said Mirza Pahlevi, M.Eng.