1. Distributed Database Management Systems
Lecture 29

2. In the previous lecture
Serializability Theory
Serializability Theory in DDBS.

3. In this Lecture
Locking based CC
Timestamp ordering based CC.

4. TM sends ops and other information to LM
LM checks the status of data item
Already Locked or not.

5. x = x+1 x = x*2 Write(x) Write(x) Commit Commit y = y-1 y = y*2
T1: Read(x) T2: Read(x)
x = x+1 x = x*2
Write(x) Write(x)
Commit Commit
Read(y) Read(y)
y = y-1 y = y*2
Write(y) Write(y)
S={wl1(x), R1(x), W1(x), lr1(x), wl2(x), R2(x), W2(x), lr2(x), wl2(y), R2(y), W2(y), lr2(y), C2,wl1(y), R1(y), W1(y), lr1(y), C1)

6. Problem: Locks released immediately-
S={wl1(x), R1(x), W1(x), lr1(x), wl2(x), R2(x), W2(x), lr2(x), wl2(y), R2(y), W2(y), lr2(y), C2,wl1(y), R1(y), W1(y), lr1(y), C1)
Not a serial schedule
Problem: Locks released immediately-

7. Two-Phase Locking

8. A transaction must not attain a lock once it releases a lock
Or, it should not release any lock until it is sure it won’t need any lock

9. It creates growing phase, shrinking phase and a lock point
Lock point determines end of growing phase and start of shrinking phase

10. Any transaction that follows 2-PL is serializable.

12. This 2-PL is difficult to implement
LM has to know that a Tr has attained all locks
Its not going to need a released item again
So we have strict 2-PL

14. Centralized 2PL The locking job is designated to a single site
So only one site has the Lock Manager

16. Central site may become a bottleneck in case of too many accesses
Primary Copy 2-PL is one solution

17. Coordinating TM
Primary Site LM
Data Processor
Partic Site

18. Distributed 2-PL

19. That was it about locking approach
Next we see timestamp-based concurrency control.

20. Serializabiltiy implemented by assigning a serialization order to transactions
Unique timestamps are issued by TM at the initiation of a transaction

21. Timestamps should be unique and monotonically increasing
Maintaining system wide monotonically increasing counter is difficult in DDBS environment

22. Timestamp then could be a two tuple consisting a counter value and the site id.
System clock can also be used in stead.

23. Timestamp Ordering Rule
Given two conflicting operations Oij, Okl of Ti and Tk, Oij is executed first iff ts(Ti) < ts(Tk)
Younger and older transactions.

24. TO scheduler checks each operation against conflicting operations
Younger ones are allowed, older refused-

25. A TO scheduler is guaranteed to generate serial order
However, needs to know all operations in advance

26. Practically, operations come one at a time
To detect the sequence of operations, a R/W timestamp is allocated to data items as well

27. Data items assigned rts(x) or wts(x), largest timestamp that has read or written a data item.

28. For a write request, if an older transaction has read or written the data item, then operation is rejected.

29. For a read request, if an older transaction has written the data item, then operation is rejected
TO does not generate deadlocks

30. Conservative TO Basic TO generates too many restarts
Like, if a site is relatively calm, then its transactions will be restarted again and again

31. Synchronizing timestamps may be very costly
System clocks can used if they are at comparable speeds

32. In con-TO, operations are not executed immediately, but they are buffered
Scheduler maintains queue for each TM.

33. Operations from a TM are placed in relevant queue, ordered and executed later
Reduces but does not eliminate restarts

34. Multiversion TO Another attempt to reduce the restarts
Multiple versions of data items with largest r/w stamps are maintained.

35. Read operation is performed from appropriate version
Write is rejected if any older has read or written a data item

36. That was all about Pessimistic CC algorithms, now we move to Optimistic approaches.

37. Pessimistic assume that conflicts are likely to happen so they are careful and follow….
Validate
Read
Compute
Write

38. Optimistic assumes less chances of conflict, so validation is done at the last stage…
Read
Compute
Validate
Write

39. Each transaction is divided into sub-transactions that execute independently
Tij = Tr i that executes at site j
Transactions run independently at each site until they reach end of read phases.

40. All sub-transactions are assigned timestamps at the end of read phases
After that Validation test is performed

41. VT1: If all transactions Tk, where ts(Tk)<ts(Tij) have completed their write phase before Tij started its read, validation succeeds

42. VT2: If there is any Tk, where ts(Tk)<ts(Tij) which completes its write while Tij is in its read phase then validation succeeds if WS(Tk) ∩ RS(Tij) = Ø

43. VT3: If Tk completes its read phase before Tij completes its read phase, then validation succeeds if
WS(Tk) ∩ RS(Tij) = Ø and
WS(Tk) ∩ WS(Tij) = Ø
Read
Validate
Write Tk
Tij

44. Optimistic techniques allow more concurrency.
Need more storage for the validation tests
Repeated failure for longer transactions.

45. Here we have finalized our discussion on CC techniques.
Next topic is Deadlock Management

46. Locking based CC generates deadlock
T1 waits for data item being held by T2, and other way round
Wait-for Graph.

47. A WFG represents the relationship between transactions waiting for each other to release data items

48. We can have local and global WFGT1 T2 T3 T4
Site 1
Site 2

49. Deadlock Management
Ignore
Prevention
Avoidance
Detect and Recovery