Chapter 9 Concurrency Control Interactions among transactions can cause the database state to become inconsistent, even when the transactions individually preserve correctness of the state, and there is no system failure. Thus, the order in which the individual steps of different transactions occur needs to be regulated in some manner. The function of controlling these steps is given to the scheduler component of the DBMS, and the general process of assuiing that transactions preserve consis-
468 CHAPTER 9. CONCURRENCY CONTROL
9.1. SERIAL AND SERIALIZABLE SCHEDULES 469 TJ 72 READ(A,t)READClTs) t := t+100 s := s*2 WRITE(A,t) WRITE(A,s) READ(B.t) READ(B,s) t := t+100 s := s*2 WRITE(B,t) WRITE(B,s) Figure 9.2: Two transactions
470 CHAPTER 9. CONCURRENCY CONTROL
474 CHAPTER 9. CONCURRENCY CONTROL T 2 : r- 2 (A)- wz(a); r 2 (B); w 2 (B); Notice that there is no mention of the local variables t and s anywhere, and no indication of what has happened to A and B after they were read. Intuitively, we shall "assume the worst," regarding the ways in which these database elements change.
9.2. CONFLICT-SERIALIZABILITY 475
476 CHAPTER 9. CONCURRENCY CONTROL T t. Our assumption of "no coincidences" tells us that the values written
9.2. CONFLICT-SERIALIZABILITY 477 ri(a); Wl(A); r 2 (A); w 2 (A); n(fl); Wl(B); r 2 (B); w 2 (B); ri (A); Wl (A); r 2 (A); n(b); w 2 (A); Wl (B); r 2 (B); iv 2 (B); n(a); Wl (A)- ri (B); r 2 (A); w 2 (A); Wl (B); r 2 (B); w 2 (B); ri(a); wi(a); n(b); r 2 (A); Wl (B); w 2 (A); r 2 (B); w 2 (B); n(a); Wl(A); n(b); Wl(B); r 2 (A); w 2 (A); r 2 (B); w 2 (B);
9.2. CONFLICT-SERIALIZADILITY 479 Figure 9.9: The precedence graph for the schedule 5 of Example 9.7 Example 9.8: Figure 9.9 is acyclic, so the schedule 5 of Example 9.7 is conflict-serializable. There is only one order of the nodes or transactions consistent with the arcs of that graph: (Ti,T
9.2. CONFLICT-SERIALIZABILITY 481 9.2.4 Exercises for Section 9.2 Exercise 9.2.1: Below are two transactions, described in terms of their effect
9.3. ENFORCING SERIALIZABILITY BY LOCKS 483 9.3 Enforcing Serializability by Locks
484 CHAPTER 9. CONCURRENCY CONTROL than serializability. When a scheduler uses locks, transactions must request and release locks, in addition to reading and writing database elements. The use of locks must
486 CHAPTER 9. CONCURRENCY CONTROL Example 9.10, with simple (but important, as we shall see in Section 9.3.3)
9.3. ENFORCING SERIALIZABILITY BY LOCKS 487 locking is a condition, like consistency, on the order of actions in a transaction. A transaction that obeys the 2PL condition is said to be a two-phase-locked transaction, 01 2PL transaction. Example 9.12 : In Example 9.10, the transactions do not obey the two-phase locking rule. Foi instance, T\ unlocks A before it locks B. However, the versions of the transactions found in Example 9.11 do obey the 2PL condition. Notice that TI locks both A and B within the first five actions and unlocks them within
488 CHAPTER 9. CONCURRENCY CONTROL
9.4. LOCKING SYSTEMS WITH SEVERAL LOCK MODES 491 "shared lock" or "read lock"), and one for writing (called an "exclusive lock" or "write lock"). We then examine an improved scheme where transactions are allowed to take a shared lock and "upgrade" it to an exclusive lock later. We also consider "increment locks," which treat specially write actions that increment a database element; the important distinction is that increment operations commute, while general writes do not. These examples lead us to the general
9.4. LOCKING SYSTEMS WITH SEVERAL LOCK MODES 493 we do not prove it here, the argument we gave in Section 9.3.4 to show that
494 CHAPTER 9. CONCURRENCY CONTROL
9.4. LOCKING SYSTEMS WITH SEVERAL LOCK MODES 495 Notice that had Ti asked for an exclusive lock on B initially, before reading B, then the request would have been denied, because T^ already had a shared lock on B. TI could not perform its computation without reading B, and so TI would have more to do after T^ releases its locks. As a result, T\ finishes later using only an exclusive lock on B than it would if it used the upgrading strategy. D Example 9.16: Unfortunately, indiscriminate use of upgrading introduces a new and potentially serious source of deadlocks. Suppose, that T\ and T% each read database element A and write a new value for A. If both transactions use an upgrading approach, first getting a shared lock on A and then upgrading it to exclusive, the sequence of events suggested in Fig. 9.18 will happen whenever TI and T<2 initiate at approximately the same time. J\ TZ sh(a) sl*(a) xli(a) Denied xl 2 (A) Denied Figure 9.18: Upgrading by two transactions can cause a deadlock TI and T 2 are both able to get shared locks on A. Then, they each try to upgrade to exclusive, but the scheduler forces each to wait because the other has a shared lock on A. Thus, neither can make progress, and they will each wait forever, or until the system discovers that there is a deadlock, aborts one of the two transactions, and gives the other the exclusive lock on A. D 9.4.4 Update Locks There is a way to avoid the deadlock problem of Example 9.16 by using a third lock mode, called update locks. An update lock ul^x) gives transaction T z only the privilege to read X, not to write X. However, only the update lock can be upgraded to a write lock later; a read lock cannot be upgraded. We can grant an update lock on X when there are already shared locks on X, but once there is an update lock on X we prevent additional locks of any kind shared, update, or exclusive from being taken on X. The reason is that if we don't deny such locks, then the updater might never get a chance to upgrade to exclusive, since there would always be other locks on X. This rule leads to an asymmetric compatibility matrix, because the update (U) lock looks like a shared lock when we are requesting it and looks like an exclusive lock when we already have it. Thus, the columns for U and S locks are the same, and the rows for U and X locks are the same. The matrix is
498 CHAPTER 9. CONCURRENCY CONTROL a) A consistent transaction can only have an increment action on X if it
500 CHAPTER 9. CONCURRENCY CONTROL iv. Tell what happens when each schedule from (Hi) is run by a scheduler
9.5. AN ARCHITECTURE FOR A LOCKING SCHEDULER 503
9.5. AN ARCHITECTURE FOR A LOCKING SCHEDULER 505
506 CHAPTER 9. CONCURRENCY CONTROL element, we can simplify the grant/deny decision by comparing the request
9.5. AN ARCHITECTURE FOR A LOCKING SCHEDULER 507
510 CHAPTER 9. CONCURRENCY CONTROL Figure 9.27: Database elements organized in a hierarchy
9.6. MANAGING HIERARCHIES OF DATABASE ELEMENTS 511
9.6. MANAGING HIERARCHIES OF DATABASE ELEMENTS 513 Figure 9.29: Locks granted to two transactions accessing Movie tuples T 3 needs to read the tuples of all the Disney movies, so it might start by getting an IS lock on the relation and S locks on each of the tuples for Disney movies. 8 Now, a transaction T 4 comes along and inserts a new Disney movie. It seems that T 4 needs no locks, but it has made the result of TS incorrect. That fact by itself is not a concurrency problem, since the serial order (Ts,T 4 ) is
514 СНАРТЕК9. СОМС11КВЖСУ СОНТК01 9.6.4 Ехегс18ез йог 8ес1юп 9.6 Ехегс18е 9.6.1: СопзЫег, Гог уапеъу, ап оъ]е<л-опеглес! йаъаьазе. ТЬе оь- ]ес1з ог с!азз С аге з^огес! оп 1тэ Ыо<±з, В\ апс! В 2. В1скЖ В\ соп^ашз оь]ес(;8 Ох апс! 02, туы1е Ыос1с 1?2 соглатз оь]ес!;8 Оз, 04- апс1 0*>. С1азз ех4еп1,8, Ыос!с8, апс! оь]ес18 Гогт
9.7. THE TREE PROTOCOL 515 impossible. The reason is that every transaction using the index must begin by
516 CHAPTER 9. CONCURRENCY CONTROL
9.7. THE TREE PROTOCOL 517 Figure 9.31: Three transactions following the tree protocol schedule, all nodes are touched in the same order as they are in the original schedule. To understand why the precedence graph described above must always be acyclic, let us first obseive the following: If two transactions lock several elements in common, then they are all
9.7. THE TREE PROTOCOL 519 subtree. Note that transactions locking the root may belong to more than one subtree, but a transaction that does not lock the root will belong to only one of
520 CHAPTER 9. CONCURRENCY CONTROL
9.8. CONCURRENCY CONTROL BY TIMESTAMPS 521 9.8 Concurrency Control by Timestamps Next, we shall consider two methods other than locking that are used in some systems to assure serializability of transactions: 1. Timestampmg. We assign a "timestamp" to each transaction, record the timestamps of the transactions that last read arid write each database element, and compare these values to assure that the serial schedule accord-
9.8. CONCURRENCY CONTROL BY TIMESTAMPS 525 However, we already skipped the write by T and it is too late to repair the damage. While there are many ways to deal with the problems just described, we shall adopt a relatively simple policy based on the following assumed capability
9.8. CONCURRENCY CONTROL BY TIMESTAMPS 527
528 CHAPTER 9. CONCURRENCY CONTROL Figure 9.40: TS must abort because it cannot access an old value of A 2. When a read rj (X) occurs, the scheduler finds the version X t of X such that t < TS(T), but there is no other version X
9.8. CONCURRENCY CONTROL BY TIMESTAMPS 529 Figure 9.41: A transaction tries to write a version of X that would make events physically unrealizable Figure 9.42: Execution of transactions using multiversion concurrency control
530 CHAPTER 9. CONCURRENCY CONTROL versions are managed as in Section 9.8.5. A read-only transaction is allowed to read whatever version of a database element is appropriate for its timestamp. A
9.9. CONCURRENCY CONTROL BY VALIDATION 531
532 CHAPTER 9. CONCURRENCY CONTROL 9.9.2 The Validation Rules If maintained by the scheduler, the information of Section 9.9.1 is enough for it to detect any potential violation of the assumed serial order of the transac-
9.9. CONCURRENCY CONTROL BY VALIDATION 533
534 CHAPTER 9. CONCURRENCY CONTROL Figure 9.45: Four transactions and their validation 3. Validation of V: When V validates, U is validated and finished, and T is validated but not finished. Also, V started before U finished. Thus, we must compare both RS(V) and WS(V) against WS(T), but only RS(V)
536 CHAPTER 9. CONCURRENCY CONTROL is that the write set for a transaction must be known before the writes occur
9.10. SUMMARY OF CHAPTER 9 537 4 Consistency of Concurrent Transactions: It is normal for several transactions to have access to a database at the same time. Transactions, run
538 CHAPTER 9. CONCURRENCY CONTROL 4- Compatibility Matrices: A compatibility matrix is a useful summary of when it is legal to grant a lock in a certain lock mode, given that there may be other locks, in the same or other modes, on the same element. 4- Update Locks: A scheduler can allow a transaction that plans to read and then write an element first to take an update lock, and later to upgrade the lock to exclusive. Update locks can be granted when there are already
9.11. REFERENCES FOR CHAPTER 9 539
540 CHAPTER 9. CONCURRENCY CONTROL 10. A. Silberschatz and Z. Kedem, "Consistency in hierarchical database systems," J. ACM 27:1 (1980), pp. 72-80. 11. A. Thompson, "Concurrency control: methods, performance, and analy-