How Serializability Is Used for Concurrency Control

21.5.3 How Serializability Is Used for Concurrency Control

As we discussed earlier, saying that a schedule S is (conflict) serializable—that is, S is (conflict) equivalent to a serial schedule—is tantamount to saying that S is correct. Being serializable is distinct from being serial, however. A serial schedule represents

inefficient processing because no interleaving of operations from different transac- tions is permitted. This can lead to low CPU utilization while a transaction waits for disk I/O, or for another transaction to terminate, thus slowing down processing considerably. A serializable schedule gives the benefits of concurrent execution without giving up any correctness. In practice, it is quite difficult to test for the seri- alizability of a schedule. The interleaving of operations from concurrent transac- tions—which are usually executed as processes by the operating system—is

766 Chapter 21 Introduction to Transaction Processing Concepts and Theory

(a)

Transaction T 1 Transaction T 2 Transaction T 3

read_item(X );

read_item(Z );

read_item(Y );

write_item(X );

read_item(Y );

read_item(Z );

read_item(Y );

write_item(Y );

write_item(Y );

write_item(Y );

read_item(X );

write_item(Z );

write_item(X );

(b)

Transaction T 1 Transaction T 2 Transaction T 3

read_item(Z ); read_item(Y ); write_item(Y );

read_item(Y );

Time

read_item(Z );

read_item(X ); write_item(X );

write_item(Y); write_item(Z );

read_item(X ); read_item(Y );

write_item(Y );

write_item(X );

Schedule E

(c)

Transaction T 1 Transaction T 2 Transaction T 3

read_item(Y ); read_item(Z );

read_item(X ); write_item(X );

write_item(Y );

Time

write_item(Z );

Figure 21.8

read_item(Z );

Another example of

read_item(Y );

serializability testing.

write_item(Y );

read_item(Y );

(a) The read and write

write_item(Y );

operations of three

read_item(X );

transactions T 1 ,T 2 ,

write_item(X );

and T 3 . (b) Schedule E. (c) Schedule F.

Schedule F

all processes. Factors such as system load, time of transaction submission, and pri- orities of processes contribute to the ordering of operations in a schedule. Hence, it is difficult to determine how the operations of a schedule will be interleaved before-

21.5 Characterizing Schedules Based on Serializability 767

(d)

Equivalent serial schedules T 1 T 2 None

Reason

XY

Cycle X (T 1 T 2 ),Y(T 2 T 1 )

Y, Z

T 3 Cycle X (T 1 T 2 ),YZ (T 2 T 3 ),Y(T 3 T 1 )

(e)

X,Y

Equivalent serial schedules

Y, Z

(f)

Equivalent serial schedules

T 3 T 2 T 1 Figure 21.8 (continued)

Another example of serializability testing. T 3 (d) Precedence graph for schedule E.

(e) Precedence graph for schedule F. (f) Precedence graph with two equivalent serial schedules.

If transactions are executed at will and then the resulting schedule is tested for seri- alizability, we must cancel the effect of the schedule if it turns out not to be serializ- able. This is a serious problem that makes this approach impractical. Hence, the approach taken in most practical systems is to determine methods or protocols that ensure serializability, without having to test the schedules themselves. The approach taken in most commercial DBMSs is to design protocols (sets of rules) that—if fol-

lowed by every individual transaction or if enforced by a DBMS concurrency con- trol subsystem—will ensure serializability of all schedules in which the transactions participate.

Another problem appears here: When transactions are submitted continuously to the system, it is difficult to determine when a schedule begins and when it ends. Serializability theory can be adapted to deal with this problem by considering only the committed projection of a schedule S. Recall from Section 21.4.1 that the

committed projection C(S) of a schedule S includes only the operations in S that belong to committed transactions. We can theoretically define a schedule S to be serializable if its committed projection C(S) is equivalent to some serial schedule,

768 Chapter 21 Introduction to Transaction Processing Concepts and Theory

In Chapter 22, we discuss a number of different concurrency control protocols that guarantee serializability. The most common technique, called two-phase locking, is based on locking data items to prevent concurrent transactions from interfering with one another, and enforcing an additional condition that guarantees serializ- ability. This is used in the majority of commercial DBMSs. Other protocols have

been proposed; 14 these include timestamp ordering, where each transaction is assigned a unique timestamp and the protocol ensures that any conflicting opera- tions are executed in the order of the transaction timestamps; multiversion protocols, which are based on maintaining multiple versions of data items; and optimistic (also called certification or validation) protocols, which check for possible serializability violations after the transactions terminate but before they are permitted to commit.