Database systems for real-time applications must satisfy timing constraints associated with ... Recently, interest in this new application domain is growing in.
A Priority-Based Scheduling Algorithm for Real-Time Databases
Sang H. Son Department of Computer Science University of Virginia Charlottesville, Virginia 22903, USA Seog Park Department of Computer Science Sogang University Seoul, Korea
ABSTRACT
Database systems for real-time applications must satisfy timing constraints associated with transactions, in addition to maintaining the consistency of data. In this paper we propose a priority-based scheduling algorithm for real-time database systems. We show that this algorithm is deadlock-free, and in addition, a high priority transaction is not blocked by uncommitted lower priority transactions. The algorithm does not assume any knowledge about the data requirements or the execution time of each transaction. This makes the algorithm widely applicable, since in many actual environments such information may not be readily available.
Key Words: real-time, scheduling, concurrency, deadline, transaction
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh This work was supported in part by ONR, by Loral Federal Systems, and by VCIT.
1. Introduction A real-time database system is a transaction processing system where transactions have explicit timing constraints. Typically, a timing constraint is expressed in the form of a deadline, a certain time in the future by which a transaction needs to be completed. In real-time database systems, the correctness of transaction processing depends not only on maintaining consistency constraints and producing correct results but also on the time at which a transaction is completed [1]. Transactions must be scheduled in such a way that they can be completed before their corresponding deadlines expire. For example, both the update and query operations on the tracking data for a missile must be processed within a given deadline: otherwise, the information provided could be of little value. Real-time database systems are becoming increasingly important in a wide range of applications, such as computer integrated manufacturing, aerospace, traffic control systems, nuclear power plants, robotics, military command and control applications, and in the stock market trading. Conventional data models and databases are not adequate for time-critical applications, since they are not designed to provide features required to support real-time transactions. They are designed to provide good average performance, while possibly yielding unacceptable worst-case response times. Very few of them allow users to specify or ensure timing constraints. Recently, interest in this new application domain is growing in database community [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]. Transactions in a real-time database system can be categorized as hard and soft transactions [11]. We define hard real-time transactions as those transactions whose timing constraints must be guaranteed. Missing deadlines of this type of transaction may result in catastrophic consequences. In contrast, soft real-time transactions have timing constraints, but there may still be good justification in completing the transactions after their deadlines. Catastrophic consequences do not result if soft real-time transactions miss their deadlines. Soft real-time transactions are scheduled taking into account their timing requirements, but they are not guaranteed to make their deadlines. In this paper, we only consider soft real-time transactions which have benefits to the system to finish even after the deadline is passed. The benefits
may be reduced once the transactions pass the deadline. While the theories of concurrency control in database systems and real-time task scheduling have both advanced, little attention has been paid to the interaction between concurrency control protocols and real-time scheduling algorithms [15]. In database concurrency control, meeting the deadline is typically not addressed. The objective is to provide a high degree of concurrency and thus faster average response time without violating data consistency. In real-time task scheduling, on the other hand, it is customary to assume that tasks are independent, or that the time spent synchronizing their access to shared data is negligible compared with execution time. The objective here is to maximize resources, such as CPU utilization, subject to meeting timing constraints. Data consistency is not a consideration in real-time task scheduling, and hence the problem of guaranteeing the consistency of shared data is ignored. In addition, conventional real-time systems assume advance knowledge of the resource and data requirements of programs. Scheduling in real-time database systems is a combination of the two scheduling mechanisms. Concurrency control protocols induce a serialization order among conflicting transactions. In nonreal-time concurrency control protocols, timing constraints are not a factor in the construction of this order. This is obviously a drawback for real-time database systems. For example, with the 2PL protocol, the serialization order is dynamically constructed and corresponds to the order in which conflicting transactions access shared data. In other words, the serialization order is bound to the past execution history with no flexibility. When a transaction TH with a higher priority requests an exclusive lock which is being held by another transaction, TL , with a lower priority, the only choices are either aborting TL or letting TH wait for TL . Neither choice is satisfactory. The conservative 2PL uses blocking, but in real-time database systems, blocking may cause priority inversion. Priority inversion is said to occur when a high priority transaction is blocked by lower priority transactions [17]. The alternative is to abort low priority transactions when priority inversion occurs. This wastes the work done by the aborted transactions and in turn also has a negative effect on time-critical scheduling.
-2-
Satisfying the timing constraints while preserving data consistency requires the concurrency control algorithms to accommodate timeliness of transactions as well as to maintain data consistency. This is the very goal of our work. In real-time database systems, timeliness of a transaction is usually combined with its criticality to take the form of the priority of that transaction. Therefore, proper management of priorities and conflict resolution in real-time transaction scheduling are essential for predictability and responsiveness of real-time database systems. For a concurrency control algorithm to accommodate the timeliness of transactions, the serialization order it produces should reflect the priority of transactions [12]. However, this is often hindered by the past execution history of transactions. For example, a higher priority transaction may have no way to precede a lower priority transaction in the serialization order due to previous conflicts. The result is that either the lower priority transaction has to be aborted or the high priority transaction suffers blocking. If the information about data requirements and execution time of each transaction is available beforehand, off-line preanalysis can be performed to avoid conflicts [10]. This is exactly what is done in many realtime task scheduling algorithms. However, such approaches may delay the starting of some transactions, even if they have high priorities, and may reduce the concurrency level in the system. This, in return, may lead to the violation of the timing constraints and degrade system performance. In this paper we propose a priority-based locking algorithm, based on the idea of adjusting the serialization order of active transactions dynamically. To our best knowledge, this is the first attempt to integrate benefits of the pessimistic and optimistic approaches for real-time transaction scheduling. We show that the algorithm is free of deadlock, and in addition a high priority transaction is not blocked by uncommitted lower priority transactions. The algorithm is similar to optimistic concurrency control protocols [16] in the sense that each transaction has three phases, but unlike the optimistic method, there is no validation phase. The three phases of this algorithm are read, wait, and write phases. The read phase is similar to that of optimistic concurrency control wherein a transaction reads from the database and writes to its local workspace. In this phase, however, conflicts are also detected and resolved by using transaction priority. While other optimistic concurrency control protocols resolve conflicts in the validation -3-
phase, this algorithm resolves them in the read phase. In the wait phase, a transaction waits for its chance to commit. Finally, in the write phase, updates are made permanent to the database. The remainder of this paper is organized as follows. Some of the related work is reviewed in Section 2. The details of the proposed algorithm are described in Section 3, and its properties are discussed in Section 4. Section 5 presents an example to show how the algorithm works. The transaction scheduling aspect is described in Section 6. Finally concluding remarks appear in Section 7. 2. Related Work The goal of scheduling in real-time database systems is twofold: to meet timing constraints and to enforce data consistency. Real-time task scheduling methods can be extended for real-time transaction scheduling, yet concurrency control protocols are still needed for operation scheduling to maintain data consistency. The general approach is to utilize existing concurrency control protocols, especially 2PL, and to apply time-critical transaction scheduling methods that favor more urgent transactions [1, 2, 4, 10]. Such approaches have the inherent disadvantage of being limited by the concurrency control protocol upon which they depend, since all existing concurrency control methods synchronize concurrent data access of transactions by the combination of two measures: blocking and roll-backs of transactions. Both are barriers to meeting time-critical schedules. Abbott and Garcia-Molina have proposed a restart-based 2PL [2]. It incorporates priority information in lock setting so that transactions with higher priority will be given a preference. Whenever a higher priority transaction is in conflict with a lower priority transaction, the lower priority transaction will be aborted and restarted later on. One of the weaknesses of this scheme is the impact of restarts on scheduling other transactions to meet their timing constraints. Restarting a transaction could be very costly in terms of wasted resources, and a large number of restarts will increase the workload of the system and may cause other transactions to miss their deadlines. To reduce the number of restarts, the conditional restart protocol is proposed, in which the lower priority transaction will have to be restarted only if the slack time of the higher priority transaction is smaller than the remaining execution time of the lower
-4-
priority transaction that holds the lock [2]. There are few problems with this protocol. First, the effectiveness of the checking is greatly affected by the probability of blocking of the lower priority transaction. Second, the scheduler should have the information such as the execution time and slack time. In real-time database systems, such information is hard to get due to the dynamic nature of resource demands and data-dependent execution path of transactions. Furthermore, priority inversion and deadlock is still possible, although they have a lesser degree of impact. For conventional database systems, it has been shown that optimal performance may be achieved by compromising blocking and roll-back [18]. For real-time database systems, we may expect similar results. Aborting a few low priority transactions and restarting them later may allow high priority transactions to meet their deadlines, resulting in improved system performance. To improve the timeliness of real-time database systems, it is highly desirable to take timing requirements of transactions into consideration for scheduling decisions. An optimistic approach [16] is a possible way to achieve this goal. Due to its validation phase conflict resolution, it can be ensured that eventually discarded transactions do not abort other transactions and timing requirements of transaction are considered. The key component of optimistic concurrency control protocols is the validation phase where a transaction’s destiny is determined. In the optimistic approach, write requests issued by transactions are not immediately processed on data objects but are deferred until the transaction submits a commit request, at which time the transaction must go through the validation phase. Because write operations effectively occur at commit time, the serialization order selected by an optimistic concurrency control protocol is the order in which the transactions actually commit through validation phase. Transaction validation can be performed in one of the two ways: forward validation and backward validation. In optimistic concurrency control protocols that perform backward validation, the validating transaction either commits or aborts depending on whether it has conflicts with transactions that have already committed. Thus, backward validation scheme does not allow us to take transaction characteristics into
-5-
account. In forward validation, however, either the validating transaction or conflicting ongoing transactions can be aborted to resolve conflicts. The forward validation scheme is advantageous in real-time database systems, because it may be preferable not to commit the validating transaction, depending on the timing characteristics of the validating transaction and the conflicting ongoing transactions. A number of real-time concurrency control methods based on the optimistic approach using forward validation have been studied [5, 6, 12]. Few of them (e.g., OPT-WAIT protocol in [5]) incorporate priority-based conflict resolution mechanisms, such as priority wait, that make low priority transactions wait for conflicting high priority transactions to complete. However, this approach of detecting conflicts during validation phase degrades system predictability, since it may be too late to restart the transaction and meet the deadline. A scheduling algorithm can solve the problem mentioned above, if a lock-based concurrency control protocol supports a mechanism to adjust dynamically the serialization order of active transactions. The integrated scheduler presented in the next section integrates a priority-based locking with an optimistic approach. Another important issue that needs further study is a notion of "correct execution" in transaction processing, different from serializability. As observed by Bernstein [19], serializability may be too strong as a correctness criterion for concurrency control in database systems with timing constraints, because of the limitation on concurrency. Based on the argument that timing constraints may be more important than data consistency in real-time database systems, attempts have been made to satisfy timing constraints by sacrificing database consistency temporarily to some degree [8, 20]. It is based on a new consistency model of real-time databases, in which maintaining external data consistency (values of data objects represent correct values of external world outside the database) has priority over maintaining internal data consistency (no data that violates consistency constraints). Although in some applications weaker consistency is acceptable, a general-purpose consistency criterion that is less stringent than serializability has not yet been proposed. The problem is that temporary inconsistencies may affect active transactions and so the commitment of
-6-
these transactions may still need to be delayed until the inconsistencies are removed; otherwise even committed transactions may need to be rolled back. However, in real-time systems, some actions are irreversible. The use of semantic information in transaction scheduling and multiversion data is often proposed for real-time database applications [8, 11, 21]. Multiple versions are useful in situations that require the monitoring of data as values are changing with time. In such situations, the trends exhibited by the values of the data can be used to initiate proper actions [7]. Examples include falling values in stock-market trading and rising temperature of a furnace in a nuclear reactor. Another objective of using multiple versions is to increase the degree of concurrency and to reduce the possibility of transaction rejection by providing a succession of views of data. There are several problems that must be solved in order to use multiple versions effectively. For example, the selection of old versions for a transaction must ensure the required consistency of the state seen by the transaction. 3. The Priority-Based Scheduling Algorithm 3.1. Basic Concepts A real-time database is often used by applications such as tracking. Since we cannot predict how many objects need to be tracked and when they appear, we assume randomly arriving transactions. Each transaction is assigned an initial priority and a start-timestamp when it is submitted to the system. The initial priority can be based on the deadline and the criticalness of the transaction. The start-timestamp is appended to the initial priority to form the actual priority that is used in scheduling. When we refer to the priority of a transaction, we always mean the actual priority with the start-timestamp appended. Since the start-timestamp is unique, so is the priority of each transaction. The priority of transactions with the same initial priority is distinguished by their start-timestamps. Note that the start-timestamp is only used to distinguish transactions with the same initial priority. Most likely, the transaction which started earlier than other transactions with the same initial priority should be treated favorably by comparing their starttimestamps. However, depending on the application semantics, it can be decided which transaction has -7-
the higher priority, based on their start-timestamp. With two-phase locking and priority assignment, we can encounter the problem of priority inversion. What we need is a concurrency control algorithm that allows transactions to meet the timing constraints as much as possible without reducing the concurrency level of the system in the absence of any a priori information. The priority-based scheduling algorithm presented in this paper meets these goals. It has the flavor of both locking and optimistic methods. Transactions write into the database only after they are committed. By using a priority-based locking protocol, the serialization order of active transactions is adjusted dynamically, making it possible for transactions with higher priorities to be executed first so that higher priority transactions are not blocked by uncommitted lower priority transactions, while lower priority transactions may not have to be aborted even in face of conflicting operations. The adjustment of the serialization order can be viewed as a mechanism to support time-critical scheduling. All transactions that can be scheduled are placed in a ready queue, R_Q. Only transactions in R_Q are scheduled for execution. When a transaction is blocked, it is removed from R_Q. When a transaction is unblocked, it is inserted into R_Q again, but may still be waiting to be assigned the CPU. A transaction is said to be suspended when it is not executing, but still in R_Q. When a transaction is doing I/O operations, it is blocked. Once it completes, it is usually unblocked. The execution of each transaction is divided into three phases: the read phase, the wait phase and the write phase. During the read phase, a transaction reads from the database and writes to its local workspace. After it completes, it waits for its chance to commit in the wait phase. If it is committed, it switches into the write phase during which all its updates are made permanent in the database. A transaction in any of the three phases is called active. We take an approach of integrated schedulers in that it uses 2PL for read-write conflicts and the Thomas’ Write Rule (TWR) for write-write conflicts. The TWR ignores a write request that has arrived late, rather than rejects it [19].
-8-
In the algorithm, there are various data structures that need to be read and updated in a consistent manner. Therefore we assume the existence of critical sections to guarantee that only one process at a time updates these data structures. We assume critical sections of various classes to group the various data structures and allow maximum concurrency. We also assume that each assignment statement of global data is executed atomically. 3.2. Read Phase The read phase is the normal execution of a transaction except that write operations are performed on private data copies in the local workspace of the transaction instead of on data objects in the database. We call such write operations prewrites, denoted by pwT [x ]. A write request from a transaction is performed by a prewrite operation. Since each transaction has its own local workspace, a prewrite operation does not write into the database, and if a transaction previously wrote a data object, subsequent read operations to the same data object retrieve the value from the local workspace. The read-prewrite or prewrite-read conflicts between active transactions are synchronized during this phase by a priority-based locking protocol. Before a transaction can perform a read (resp. prewrite) operation on a data object, it must obtain the read (resp. write) lock on that data object first. A read (resp. write) lock on x by transaction T is denoted by rlock(T,x) (resp. wlock(T,x)). If a conflict is resolved to allow the read operation to read the value not yet changed by the prewrite operation (i.e., before-image of the data object), it is called immediate reading. If the read operation is blocked and delayed until the prewrite is completed to read the after-image, it is called delayed reading. If a transaction reads a data object that has been written by itself, it gets the private copy in its own workspace and no read lock is needed. In the rest of the paper, when we refer to read operations, we exclude such read operations because they do not induce any dependencies among transactions. The locking protocol is based on the principle that higher priority transactions should complete before lower priority transactions. That is, if two transactions conflict, the higher priority transaction should precede the lower priority transaction in the serialization order. Using an appropriate CPU
-9-
scheduling policy for real-time database systems, a high priority transaction can be scheduled to commit before a low priority transaction in most cases. If a low priority transaction does complete before a high priority transaction, it is required to wait until it is sure that its commitment will not lead to the higher priority transaction being aborted. Suppose active transaction T 1 has higher priority than active transaction T 2 . We have four possible conflicts and the transaction dependencies they require in the serialization order as follows: (1) rT 1 [x ] , pwT 2 [x ] The resulting serialization order is T 1 → T 2 , which satisfies the priority order, and hence it is not necessary to adjust the serialization order. (2) pwT 1 [x ] , rT 2 [x ] Two different serialization orders can be induced with this conflict; T 2 → T 1 with immediate reading, and T 1 → T 2 with delayed reading. Certainly, the latter should be chosen for priority scheduling. The delayed reading means that rT 2 [x ] is blocked by the write lock of T 1 on x. (3) rT 2 [x ] , pwT 1 [x ] The resulting serialization order is T 2 → T 1 , which violates the priority order. If T 2 is in the read phase, it is aborted because otherwise T 2 must commit before T 1 and thus block T 1 . If T 2 is in its wait phase, avoid aborting T 2 until T 1 commits, in the hope that T 2 gets a chance to commit before T 1 commits. If T 1 commits, T 2 is aborted. But if T 1 is aborted by some other conflicting transaction, then T 2 is committed. With this policy, we can avoid unnecessary and useless aborts, while satisfying priority scheduling. (4) pwT 2 [x ] , rT 1 [x ] Two different serialization orders can be induced with this conflict; T 1 → T 2 with immediate reading, and T 2 → T 1 with delayed reading. If T 2 is in its write phase, delaying T 1 is the only choice. This blocking is not a serious problem for T 1 because T 2 is expected to finish writing x soon. T 1 can read x as soon as T 2 finishes writing x in the database, not necessarily after T 2 completes the whole write phase. If T 2 is in its read or wait phase, choose immediate reading. As transactions are being executed and conflicting operations occur, all the information about the induced dependencies in the serialization order needs to be retained. To do this, we retain two sets for each transaction, before-trans-set and after-trans-set, and a count, before-count. The set before-trans-set (resp. after-trans-set) contains all the active lower priority transactions that must precede (resp. follow) this transaction in the serialization order. The before-count is the number of the higher priority transactions that precede this transaction in the serialization order. When a conflict occurs between two transactions, their dependency is set and their values of before-trans-set, after-trans-set, and before-count will be
-10-
changed accordingly. By summarizing what we discussed above, we define the priority-based locking protocol as follows:
LP1.
Transaction T requests a read lock on data object x. for all transactions t with wlock(t,x) do if (priority (t) > priority (T) or t is in write phase) /* Case 2, 4 */ then deny the lock and exit; endif enddo for all transactions t with wlock(t,x) do /* Case 4 */ if t is in before −trans −setT then abort t; else if (t is not in after −trans −setT ) then include t in after −trans −setT ; before −countt := before −countt + 1; endif endif enddo grant the lock;
LP2.
Transaction T requests a write lock on data object x. for all transactions t with rlock(t,x) do if priority (t) > priority (T) then /* Case 1 */ if (T is not in after −trans −sett ) then include t in after −trans −sett ; before −countT := before −countT + 1; endif else if t is in wait phase /* Case 3 */ then if (t is in after −trans −setT ) then abort t; else include t in before −trans −setT ; endif else if t is in read phase then abort t; endif endif endif enddo
-11-
grant the lock; LP1 and LP2 are actually two procedures of the lock manager that are executed when a lock is requested. When a lock is denied due to a conflicting lock, the request is suspended until that conflicting lock is released. Then the locking protocol is invoked once again from the very beginning to decided whether the lock can be granted now. With our locking protocol, a data object may be both read locked and write locked by several transactions simultaneously. 3.3. Wait and Write Phases The wait phase allows a transaction to wait until it can commit. A transaction can commit only if all transactions with higher priorities that must precede it in the serialization order are either committed or aborted. Since before-count is the number of such transactions, the transaction can commit only if its before-count becomes zero. A transaction in the wait phase may be aborted due to two reasons; if a higher priority transaction requests a conflicting lock, or if a higher priority transaction that must follow this transaction in the serialization order commits first. Once a transaction in the wait phase gets its chance to commit, i.e. its before-count goes to zero, it switches to the write phase and release all its read locks. The transaction is assigned a final-timestamp, which is the absolute serialization order. Once a transaction is in the write phase, it is considered to be committed. All committed transactions are serialized by the final-timestamp order. Updates are made permanent to the database while applying Thomas’ Write Rule for write-write conflicts [19]. After each operation the corresponding write lock is released. 4. Properties and Correctness Having described the basic concepts and the algorithm, we now present some properties and prove the correctness of the algorithm. First, we give the simple definitions of history and serialization graph (SG). For the formal definitions, readers are referred to [19]. A history is a partial order of operations that represents the execution of a set of transactions. Any two conflicting operations must be comparable. Let
-12-
H be a history. The serialization graph for H, denoted by SG(H), is a directed graph whose nodes are committed transactions in H and whose edges are all Ti → T j (i≠j) such that one of Ti ’s operations precedes and conflicts with one of T j ’s operations in H. To prove a history H serializable, we only have to prove that SG(H) is acyclic [19].
Theorem 1: Every history H produced by the algorithm is serializable. Proof: Let T 1 and T 2 be two committed transactions in a history H produced by the algorithm. We argue that if there is an edge T 1 → T 2 in SG(H), then ts (T 1 ) < ts (T 2 ). Since T 1 → T 2 , The two must have conflicting operations. There are three cases. Case 1: w 1 [x ] → w 2 [x ] Suppose ts (T 2 ) < ts (T 1 ). Therefore T 2 enters into the write phase before T 1 . If w 1 [x ] is sent to the data manager first, T 2 ’s write lock on x must be released before w 1 [x ] is sent to the data manager. If w 2 [x ] is sent to the data manager first, it will either be processed before w 1 [x ] is sent to the data manager, or be discarded when the data manager receives w 1 [x ], because w 2 [x ] has a smaller timestamp. Therefore w 1 [x ] is never processed before w 2 [x ]. Such conflict is impossible. A contradiction. Case 2: r 1 [x ] → w 2 [x ] If T 2 holds the write lock on x when T 1 requests the read lock, we must have priority (T 1 ) > priority (T 2 ) and T 2 is not in the write phase, because otherwise T 1 would have been blocked by LP1. By LP1, T 2 is in after −trans −setT 1 . T 2 will not switch into the write phase before T 1 does, because before_cntT 2 cannot be zero with T 1 still in the read or wait phase. Therefore ts (T 1 ) < ts (T 2 ). If T 1 holds read lock on x when T 2 requests the write lock, by LP2, we have either T 2 is in after −trans −setT 1 or T 1 is in before −trans −setT 2 , depending on the priorities of the two transactions. In either case, T 1 must commit before T 2 . Hence we also have ts (T 1 ) < ts (T 2 ). Case 3: w 1 [x ] → r 2 [x ]
-13-
Since T 1 is already in the write phase before T 2 reads x, we must have ts (T 1 ) < ts (T 2 ). Suppose there is a cycle T 1 → T 2 → . . . → Tn → T 1 in SG(H). By the above argument, we have ts (T 1 ) < ts (T 2 ) < . . . < ts (Tn ) < ts (T 1 ). This is impossible. Therefore no cycle can exist in SG(H) and the algorithm only produces serializable histories. `
Theorem 2: There is no mutual deadlock under the priority-based locking protocol. Proof: In the algorithm, a high priority transaction can be blocked by a low priority transaction only if the low priority transaction is in the write phase. Suppose there is a cycle in the wait-for graph (WFG), T 1 → T 2 → . . . → Tn → T 1 . For any edge Ti → T j in the cycle, if priority (Ti ) > priority (T j ), T j must be in the write phase, thus it cannot be blocked by any other transactions and cannot appear in the cycle. Therefore
we
must
have
priority (Ti ) < priority (T j )
and
thus
priority (T 1 )
< priority (T 2 ) < . . . < priority (Tn ) < priority (T 1 ). This is impossible. Hence a deadlock cannot exist.
` We now discuss some properties of the algorithm. First, the algorithm provides a desirable property beyond the serializability, namely the strictness. From a practical viewpoint, serializability of transactions is not always enough. To ensure the correctness in the presence of failures, the concurrency control protocol must produce execution histories that are not only serializable but also recoverable. A history H is called recoverable if, whenever Ti reads from T j in H and Ti commits, T j must commit before Ti . A history H is called strict if, whenever wi [x ] precedes o j [x ] where o j [x ] is either w j [x ] or r j [x ], Ti must either commit or abort before o j [x ]. It is known that strictness is a stronger condition than recoverability, i.e., a set of strict histories is a proper subset of recoverable histories, and it is more desirable for practical reasons [19]. The strictness of the histories produced by the algorithm follows obviously from the fact that a transaction applies the results of its write operations from its local workspace into the database only after it commits. This property makes the transaction recovery procedure simpler than other concurrency control
-14-
protocols that do not support strictness. Another property to be discussed is the degree of concurrency provided by the algorithm. The compatibility depends on the priorities of the transactions holding and requesting the lock and the phase of the lock holder as well as the lock types. Unlike 2PL, locks are not classified simply as shared locks and exclusive locks. Even with the same lock types, different actions may be taken, depending on the priorities of the lock holder and the lock requester. With the priority-based locking protocol, a data object may be both read locked and write locked by several transactions simultaneously, and hence it is less restrictive than 2PL, and can provide higher degree of concurrency by incurring less blocking and fewer aborts. In the priority-based locking protocol, a high priority transaction is never blocked or aborted due to conflict with an uncommitted lower priority transaction. The probability of aborting a lower priority transaction should be less than that in 2PL under the same conditions. An analytical model may be used to estimate the exact probability, but that is beyond the scope of this paper. 5. An Example In this section, we give a simple example to show how the algorithm works. The example is depicted in Figure 1. A solid line at a low level indicates that the corresponding transaction is doing I/O operation due to a page fault or in the write phase. A dotted line at a low level indicates that the corresponding transaction is either suspended or blocked, and not doing any I/O operation either. A line raised to a higher level indicates that the transaction is executing. The absence of a line indicates that the transaction has not yet arrived or has already completed. There are three transactions in the example. T 1 has the highest priority and T 3 has the lowest. T 3 arrives at time t 0 and reads data object a. This causes a page fault. After the I/O operation, it pre-writes b. Then T 2 comes in at time t 1 and preempts T 3 . At time t 2 it reads c and causes another page fault. So it is blocked for the I/O operation and T 3 executes. After T 3 pre-writes d, T 2 finishes I/O and preempts T 3 again. It pre-writes d which is only write locked by T 3 . At time t 3 , T 1 arrives and preempts T 2 . T 1 first reads d, which is write locked by both T 2 and T 3 . Therefore, before_trsetT 1 becomes {T 2 , T 3 } and both
-15-
T1 r[d] r[b] pw[b] pw[d] T2 r[c] T
pw[d]
r[b]
pw[b]
3 r[a]
t
0
pw[b]
t
1
r[c]
pw[d]
t
2
t
pw[c]
t 4 t5
3
Figure 1. An Example
before_cntT 2 and before_cntT 3 become 1. Then T 1 reads b, which is write locked by T 3 . Since T 3 is already in before_trsetT 1 , nothing is changed. Then T 1 pre-writes b and pre-writes d. Since these two data objects are not read locked by any other transactions, the write locks are granted to T 1 directly. At time t 4 , T 1 switches into the write phase. Both before_cntT 2 and before_cntT 3 go back to 0. Now T 2 should be executed, but it needs to read b, which is being write locked by T 1 ; hence T 3 is executed instead. It reads c, which is read locked by T 2 . At time t 5 , T 1 finishes writing b and releases the write lock so that T 2 can preempt T 3 to continue its work. It reads b, which is write locked by T 3 . Now before_trsetT 2 becomes {T 3 } and before_cntT 3 becomes 1. After T 2 pre-writes b, it switches into the write phase and before_cntT 3 becomes 0 again. Then T 3 executes and also switches into write phase after prewriting c. In the above example, T 1 , which is supposed to be the most urgent transaction, finishes first although it is the last to arrive. T 3 , which is supposed to be the least urgent one, is the last one to commit. None of the three transactions need to be aborted. Assume we use 2PL in the above example. When a
-16-
high priority transaction requests a lock which is held by a low priority transaction, we either let the high priority transaction to wait or abort the low priority transaction. Suppose we choose the first alternative, both T 1 and T 2 would be blocked by T 3 because T 3 holds a write lock on d. If we choose the second alternative, T 3 will be aborted by T 2 when T 2 pre-writes d and then T 2 will be aborted by T 1 when T 1 reads d. This example illustrates the advantage of the proposed method over 2PL. 6. CPU Scheduling Although the focal point of this paper is on concurrency control, i.e. operation level scheduling, we still need to discuss transaction scheduling, or CPU scheduling, aspect of our algorithm. In non-real-time database systems, CPU scheduling is usually done by the underlying operating system, because there are no timing constraints. Data consistency is the only concern. In real-time database systems, however, CPU scheduling should take into account the timeliness of transactions. In our algorithm, R_Q contains all transactions that can be scheduled. These transactions can be in any phase. We need a policy to determine the CPU scheduling priority for transactions in different phases. Transactions in their wait phase are those that have finished their work and are waiting for their chances to commit. We would like to avoid aborting such transactions as much as possible. Therefore transactions in this phase are given higher CPU scheduling priority than those in the read phase so that they can commit as soon as they get the chance. Transactions in the read phase are scheduled according to their assigned priority. If there are several read phase transactions in the R_Q, the one with the highest priority is always selected to execute. For transactions in the wait phase, the lower the priority, the higher the CPU scheduling priority. Since low priority transactions are more vulnerable to conflicts, if there is a chance, they should be committed as soon as possible to avoid being aborted later. Moreover, when a high priority transaction TH is committed, it may have to abort a low priority transaction TL if TL is in TH ’s before −trans −set. If TL is also ready to commit and we allow it to commit before TH , both TL and TH can be committed. It is because that when a low priority transaction TL is included in the before −trans −set of TH , the
-17-
serialization order requires that TL must be either committed before TH , or it must be aborted (when TH commits before TL does). 7. Conclusions In this paper, we have presented a priority-based scheduling algorithm for real-time database systems. It works under the condition that no information about transaction’s data requirements or execution time is available. In this scheduling algorithm, the execution of a transaction is divided into read, wait, and write phases, in a way similar to optimistic concurrency control mechanisms. By delaying write operations of each transaction, the restraint of past transaction execution on the serialization order is relaxed, allowing the serialization order among transactions to be adjusted dynamically in compliance with transaction timeliness and criticality. The new algorithm features the ability that allows transactions to meet the timing constraints as much as possible without reducing the concurrency level of the system or increasing the restart rate significantly. Using the algorithm, high priority transaction is not blocked by an uncommitted lower priority transaction, while the low priority transaction may not have to be aborted even in the face of conflicts with high priority transactions.
REFERENCES 1.
2. 3. 4. 5. 6. 7.
Son, S. H., "Schedulingl-Time Database Systems: A New Challenge," Data Engineering, vol. 13, no. 4, Special Issue on Directions for Future Database Research and Development, December 1990, pp 51-57. Abbott, R. and H. Garcia-Molina, "Scheduling Real-Time Transactions: A Performance Evaluation," ACM Trans. on Database Systems, vol. 17, no. 3, pp 513-560, Sept. 1992. Buchmann, A. et al., "Time-Critical Database Scheduling: A Framework for Integrating Real-Time Scheduling and Concurrency Control," 5th Data Engineering Conference, Feb. 1989. Graham, M., "Issues in Real-Time Data Management," Journal of Real-Time Systems, vol. 4, Sept. 1992, pp 185-202. Haritsa, J., M. Carey, and M. Livny, "Data Access Scheduling in Firm Real-Time Database Systems," Journal of Real-Time Systems, vol. 4, Sept. 1992. Huang, J., J. Stankovic, K. Ramamritham, and D. Towsley, "Experimental Evaluation of Real-Time Optimistic Concurrency Control Schemes," VLDB Conference, Barcelona, Spain, Sept. 1991. H. Korth, "Triggered Real-Time Databases with Consistency Constraints," 16th VLDB Conference, Brisbane, Australia, Aug. 1990.
-18-
8. 9.
10. 11. 12.
13. 14.
15. 16. 17. 18. 19. 20. 21.
Lin, K., "Consistency issues in real-time database systems," Proc. 22nd Hawaii Intl. Conf. System Sciences, Hawaii, Jan. 1989. J. Lee and S. H. Son, "Using Dynamic Adjustment of Serialization Order for Real-Time Database Systems," 14th IEEE Real-Time Systems Symposium, Raleigh-Durham, North Carolina, December 1993, pp 66-75. Sha, L., R. Rajkumar, S. H. Son, and C. Chang, "A Real-Time Locking Protocol," IEEE Transactions on Computers, vol. 40, no. 7, July 1991, pp 793-800. Son, S. H., guest editor, ACM SIGMOD Record 17, 1, Special Issue on Real-Time Database Systems, March 1988. Son, S. H. and S. Park, "Scheduling and Concurrency Control in Real-Time Database Systems," The Third International Symposium on Database Systems for Advanced Applications (DASFAA ’93), Taejon, Korea, April 1993, pp 219-226. S. H. Son and S. Koloumbis, "A Token-Based Synchronization Scheme for Distributed Real-Time Databases," Information Systems, vol. 18, no. 6, December 1993, pp 375-389. Kim, Y., M. Lehr, D. George, and S. H. Son, "A Database Server for Distributed Real-Time Systems: Issues and Experiences," 2nd Workshop on Parallel and Distributed Real-Time Systems, Cancun, Mexico, April 1994, pp 66-75. P. Yu, K. Wu, K. Lin, and S. H. Son, "On Real-Time Databases: Concurrency Control and Scheduling," Proceedings of IEEE, vol. 82, no. 1, January 1994, pp 140-157. Kung, H. and J. Robinson, "On Optimistic Methods for Concurrency Control," ACM Trans. on Database Syst., vol. 6, no. 2, pp 213-226, June 1981. L. Sha, R. Rajkumar, and J. Lehoczky, "Concurrency Control for Distributed Real-Time Databases," ACM SIGMOD Record, vol. 17, no. 1, Mar. 1988. P. Yu and D. Dias, "Concurrency Control using Locking with Deferred Blocking," Data Engineering Conference, Los Angeles, California, Feb. 1990, pp 30-36. Bernstein, P., V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987. S. Vrbsky and K. Lin, "Recovering Imprecise Transactions with Real-Time Constraints," Symposium on Reliable Distributed Systems, Oct. 1988, pp 185-193. Song, X. and J. Liu, "Performance of Multiversion Concurrency Control Algorithms in Maintaining Temporal Consistency", COMPSAC ’90, October 1990, pp 132-139.
-19-
