Distributed Database Systems

Autumn, 2007 Chapter 11 Part 2 of 3

Distributed Concurrency Control

Distributed Database Systems 1

Section 11.2

Taxonomy Of Concurrency Control Algorithms

Distributed Database Systems

For locking-based methods, locking granularity, i.e. the size of the portion of database that a lock is applied, is an important issue. This portion is called locking unit (lu).
Distributed Database Systems 3

Section 11.3

Locking-based Concurrency Control Algorithms

Distributed Database Systems

11.3 Locking-based Concurrency Control Algorithms

Lock modes read lock (rl), and write lock (wl). Compatibility of lock modes

In a locking-based system, the SC is a lock manager (LM).

Distributed Database Systems 5

Basic LM Algorithm
1.

LM receives DB operations and associated information (transaction ID etc.) from the TM, or a message from the data processor.

Distributed Database Systems

Basic LM Algorithm
2.

For a message from the TM, LM checks if the lu which contains the required data item is locked:
If so, and the locking mode is incompatible, then put the current operation on queue; Otherwise I. the lock is set in an appropriate mode, and II. database operation is passed onto the data processor, and then III. wait for messages from the data processor.

Distributed Database Systems

Basic LM Algorithm
3.

Upon the receive of a message from the data processor:

I. Release the lock on lu; II. check if there are more locks on lu and operations in the waiting queue and take proper actions.

For detailed algorithm, read algorithm 11.1 on p310-p311.

Distributed Database Systems 8

Basic LM Algorithm
Problem

Early release of data

Example (next page):

Distributed Database Systems

Example Early release of data

Initial: x = 50 y = 20 Result of above scheduling: x = 102 y = 39 Result of schedule {T1,T2}: x = 102 y = 38 Result of schedule {T2,T1}: x = 101 y = 39

Basic LM algorithm may generate non-serializable schedule!

Distributed Database Systems 10

Two-Phase Locking (2PL)

Note: (1). 2PL is serializable; (2) 2PL can cause cascading aborts!
Distributed Database Systems 11

Strict 2PL (S2PL)

S2PL provides degree 3 consistency! S2PL requires minimal modification to 2PL algorithm.
Distributed Database Systems 12

Details
The TM algorithm and cooperative S2PL algorithm, algorithm 11.2 and 11.3, are presented on p314-316. Read them for details.

Distributed Database Systems

13

Section 11.3

Locking-based Concurrency Control Algorithms

Subsection 11.3.1

Centralized 2PL for Distributed Databases

Distributed Database Systems

14

11.3.1 Centralized 2PL for Distributed Databases

A method to delegate lock management responsibility to a single site only, known as primary 2PL algorithm.
Coordinating TM The TM at the site where the transaction is initiated. Participating site Those at which database operations to be carried out.
Distributed Database Systems 15

Communication structure of centralized 2PL

Messages: Lock request Lock granted Database operation End of database operation Release locks

Distributed Database Systems

16

Communication structure of centralized 2PL

Algorithms for Centralized 2PL TM and LM see algorithm 11.4 and 11.5 on p319, 321. Problems: poor performance and reliability.

Distributed Database Systems

17

Section 11.3

Locking-based Concurrency Control Algorithms

Subsection 11.3.2

Primary Copy 2PL

Distributed Database Systems

18

11.3.2 Primary Copy 2PL

Implement lock management at a number of sites and make each lock manager responsible for a set of lock units. A dictionary is needed to keep the allocation of lock managers information. Changes from centralized 2PL to primary copy 2PL are minimal.

Distributed Database Systems

19

Section 11.3

Locking-based Concurrency Control Algorithms

Subsection 11.3.3

Distributed 2PL

Distributed Database Systems

20

11.3.3 Distributed 2PL

There is a lock manager at every site. Concurrency control is accomplished by the cooperation of lock manager at the sites where data are involved in the set of transactions. If database is not replicated, distributed 2PL becomes primary copy 2PL. For replicated database, a Read One Write All protocol is needed.
Distributed Database Systems 21

Communication structure
Messages: Lock request Lock granted End of database operation Release Lock

Differences between centralized 2PL and distributed 2PL can be observed by looking at the communication structures.
Distributed Database Systems 22

Differences between centralized 2PL and distributed 2PL

Centralized 2PL Distributed 2PL

Lock request Lock granted Database operation End of database operation Release locks

Lock request Lock granted End of database operation Release Lock

Distributed Database Systems

23

Section 11.4

Timestamp-based Concurrency Control Algorithms

Distributed Database Systems

24

11.4 Timestamp-based Concurrency Control Algorithms

Lock method maintains serializability by mutual exclusion. Timestamp method maintains serializability by assigning a unique timestamp to every transaction and executing transactions accordingly.

Distributed Database Systems

25

What is a timestamp?
An identifier for transaction Used to permit ordering Monotonicity timestamps generated by the same TM are monotonically increased in values.

Distributed Database Systems

26

How to assign a timestamp value

Use a monotonically increasing counter, but this is difficult in distributed environment. Use a two-tuple form:
<local-counter-value, site-identifier>

Use another two-tuple form:

<local-system-clock, site-identifier>

site ID is put in the least significant position

to avoid the situation that timestamps from a site will always be larger/smaller than timestamps from another site.
Distributed Database Systems 27

TO (Timestamps Ordering) Rule

Given two conflicting operations Oij(x) and Okl(x) belonging to transaction Ti and Tk respectively, Oij(x) is executed before Okl(x) iff ts(Ti) < ts(Tk),

i.e. the older transaction gets executed first.

ts(Ti) - the timestamp value of transaction Ti.

Distributed Database Systems 28

Schedule by the TO Rule

Basic procedure: 1. Check each new operation against conflicting operations that have been scheduled; 2. IF the new operation belongs to a younger (later) transaction than all conflicting ones THEN
accept it;

ELSE
reject it; restart the entire transaction with a new timestamp.

This means the system maintains the execution order according to the timestamps order.
Distributed Database Systems 29

Section 11.4

Tiemstamp-based Concurrency Control Algorithms

Subsection 11.4.1

Basic TO Algorithm

Distributed Database Systems

30

11.4.1 Basic TO Algorithm

TM is responsible for assigning a timestamp to each transaction and attaching it to each database operation. Two timestamps maintained by DBMS for each data item x for scheduling:
rts(x): the largest (youngest) of timestamps of transactions that have read x. wts(x): the largest (youngest) of timestamps of transactions that have written x.
Distributed Database Systems 31

11.4.1 Basic TO Algorithm

ts(T) - the timestamp for a new transaction accessing x

For read
IF ts(T) > rts(x) THEN send read(x) to DP; rts(x) ts(T). END IF

Distributed Database Systems

32

11.4.1 Basic TO Algorithm

For write
IF ts(T) > rts(x) AND ts(T) > wts(x) THEN send write(x) to DP; rts(x) ts(T); wts(x) ts(T). END IF
For basic timestamp algorithms for the TM and scheduler, read p319 to p322.
Distributed Database Systems 33

Maintain timestamps among sites

When ts(T) < rts(x), the read is rejected. Site 2 adjusts its timestamp by making it larger than rts(x) and restart. Why? Avoid ts(site 1) >> ts(site 2) which may make operations from site 2 never get executed.
Distributed Database Systems 34

Section 11.4

Tiemstamp-based Concurrency Control Algorithms

Subsection 11.4.2

Conservative TO Algorithm

Distributed Database Systems

35

11.4.2 Conservative TO Algorithm

Basic TO algorithm: dead lock free but too many restarts. Conservative TO algorithm: delays each operation until there is an assurance that no operation with smaller timestamps can arrive at that scheduler.

Distributed Database Systems

36

Basic technique
At site i, each scheduler i has one queue Qij for each TM at site j in the system. An operation from TMj is placed in Qij in increasing timestamp order. Scheduler i executes operation from all queues in this order also.
This reduces the number of restarts. But restart may occur when a queue is empty.

Distributed Database Systems

37

Basic technique
Suppose Q23 is empty and scheduler 2 chooses an operation op from Q21 and Q22. But later a conflicting operation with smaller timestamp than ts(op) from site 3 arrives, then this operation must be rejected and restarted!
Distributed Database Systems 38

Improvement 1
Use extremely conservative algorithm complemented by
In each queue there is at least one operation, or if a TM does not have a transaction to process, it has to send a message periodically to inform that in the future it will send timestamp larger than that of the message. Extremely conservative algorithm actually executes transaction serially at each site too conservative! An operation may have to wait for the coming of a younger operation of an empty queue a delay problem!
Distributed Database Systems 39

Improvement 2
Define transaction classes and set a queue for each class instead of each TM.
Transaction classes are defined by their read set and write set: If a transactions read set and write set are subset of a class, then the transaction belongs to that class.

It is difficult to define transaction classes!

Distributed Database Systems 40

Section 11.4

Tiemstamp-based Concurrency Control Algorithms

Subsection 11.4.3

Multiversion TO Algorithm

Distributed Database Systems

41

11.4.3 Multiversion TO Algorithm

Each write creates a new version of the data item to be updated. Versions are transparent to users. Transactions are processed on a state of database that it would have seen if they were executed serially.

Distributed Database Systems

42

Work of the scheduler

For a read from transaction Ti , i.e. Ri(x) : 1. Find a version of x, say xv , s.t. ts(xv) is the largest timestamp less than ts(Ti); 2. Send Ri(xv) to the data processor.

Distributed Database Systems

43

Work of the scheduler

For Wi(x) from transaction Ti : IF the scheduler has already processed a Rj(xr) such that ts(Ti)<ts(xr)<ts(Tj) THEN
reject Wi(x);

ELSE
translate Wi(x) into Wi(xw); ts(xw) ts(Ti).

Distributed Database Systems

44

Work of the scheduler

This scheduler generates serializable schedule. Versions may be purged when they are not accessed by any transactions.

Distributed Database Systems

45

To be continued

Distributed Database Systems

46