Locking Based Concurrency Control. for Integrated Real-Time Database Systems. D. Hong y. S. Chakravarthy. T. Johnson

Transcription

1 Locking Based Concurrency Control for Integrated Real-Time Database Systems D. Hong y S. Chakravarthy T. Johnson Database Systems Research and Development Center Computer and Information Science and Engineering Department University of Florida, Gainesville, FL fsharma, tedg@cis.ufl.edu Abstract In many base applications, incoming transactions are a mixed load of conventional (non real-time) and real-time (typically soft and rm) transactions. In this environment, transactions can even be changed dynamically from non realtime to soft or rm, or from soft to rm deadline transactions according to their execution paths. In this paper we show how lock based approach can handle these situation better than Optimistic Concurrency Control and how we can extend Alternative Version Concurrency Control (AVCC [Hon95]) to handle the mixed load ef- ciently for integrated real-time bases systems. 1 Introduction In many applications such as Network Service Databases [PSS + 94], incoming transactions are usually a mixed load of non real-time, soft, and rm types. Transactions that query the Network Trac Management (NTM) that are maintained to support selfadaptive capability and fault-tolerance of Network Ser- This work is supported by the Oce of Naval Research and the Navy Command, Control and Ocean Surveillance Center RDT&E Division, and by the Rome Laboratory. y Author's current address: Computer Technology Division, Database Section, Electronics and Telecommunication Research Institute (ETRI), 161 Kajong-Dong Yusong-Gu, Taejon, South Korea. dkhong@dbserver.etri.re.kr vice Databases have time constraints. They have soft or rm deadlines according to their semantics. Meanwhile transactions that only access non-dynamic such as customer service records, and account information are typically treated as non real-time transactions. Some of the transactions can even be changed from non real-time status to soft or rm deadline transactions, or from soft to rm deadline transactions dynamically during their execution (based on their execution paths). Consider a soft deadline (or non real-time) transaction which can be changed to a rm transaction by accessing a rm real-time on its future execution paths. Classifying the transaction as rm when it arrives and discarding it when it misses its deadline is not a good approach because the transaction may be nished as a soft (non real-time) transaction if the transaction does not access the real-time that eectively causes its transition from soft to rm. Thus many transactions could be executed with weakened time constraints before they actually access real-time which have stronger constraints. Weakening time constraints as much as possible help us to design real-time systems more eciently [Ram95]. The relative proportions of non real-time, soft, and rm deadline transactions are not known a priori as they are likely to change with time and application. By considering these mixed load situations, the transaction scheduler of RTDBS has to process a combination of non real-time, soft, and rm deadline transactions eciently. To the best of our knowledge, no single concurrency control algorithm can eciently handle non real-time, soft, and rm deadline transaction together. In non real-time (conventional) base systems all transactions have the same priorities and blockings and s are the usual approaches to resolve access conicts. Two phase locking (2PL) and Optimistic Concurrency Control (OCC) are representative techniques used for blocking and to resolve conicts, respectively. Under most operating circumstances, however, locking algorithms outperform OCC for non real-time transac-

2 tions [AD85, ACL87, CS84]. For soft deadline transactions, most of the research work has focused on priority assignment policy using locking based concurrency control. Several priority assignment policies have been proposed [AGM88, HJC93]. However, extending 2PL with priority introduced priority inversion which is undesirable. This led to several priority based conict resolution policies, such as Wait, Wait Promote (WP), and High Priority (HP) [AGM88] schemes. In terms of performance, 2PL-HP showed better performance than OCC for soft RTDBS with nite resources [HCL90a]. By denition, rm real-time transactions are discarded when they miss their deadlines, as there is no value to completing them after they miss their deadlines. Unlike soft RTDBS which typically use 2PL-HP as their concurrency control, most of the approaches for rm RTDBS have tried to develop a new concurrency control algorithm based on OCC which uses deferred policy based on local update scheme [HCL90a]. For rm RTDBS, OCC always outperforms 2PL-HP in the simulation studies conducted by [HCL90a, LS93] while OCC performs better than 2PL-HP only when contention is low as shown in a dierent study [HSRT91]. In our recent study [Hon95], AVCC (Alternate Version Concurrency Control which uses 2PL based approach) always outperform 2PL-HP in simulations for rm deadlines. It is clear that 2PL-HP has wasted and wasted wait due to the semantics of the rm deadline while OCC has wasted execution problem. Various approaches have tried to overcome the above limitations based on their eect on the load under consideration. wasted A wasted happens if a HPT (higher priority transaction) s a LPT (lower priority transaction) and then the HPT is discarded as it misses its deadline. In other words a transaction which is later discarded can cause s. wasted wait A wasted wait happens if a LPT waits for the of a HPT and later the HPT is discarded as it misses its deadline. In other words a transaction which is later discarded can cause wait of a conicting LPT. wasted execution A wasted execution happens when a LPT in time validation phase is ed due to a conicting HPT which has not nished yet. According to earlier studies [HCL90a, LLH95, LS93] OCC seems good for rm but not for non real-time or soft transactions. In addition, it is not easy to devise a validation algorithm for mixed load. In contrast, extending 2PL-HP and AVCC for mixed load situations is quite simple and AVCC works better than 2PL-HP for rm deadline transactions. Thus AVCC which has all the characteristics of 2PL-HP but do not have the wasted of 2PL-HP appears to be a good candidate for the mixed load. In this paper we explain our concurrency control algorithm (AVCC) briey and show how AVCC can be extended to handle the mixed load problem eectively. 2 Alternative Version Concurrency Control 2.1 Motivation of AVCC It has been shown that OCC and its variants are potential concurrency control mechanisms for rm RTDBS [HCL90b, HLC91, HSRT91, LS93, LLH95]. According to these papers 2PL-HP loses some of its advantages over OCC because of wasted and wasted wait problems even though OCC has wasted executions by delaying its validation. If a lock requesting transaction has a higher priority than conicting transactions, 2PL-HP s the con- icting LPT immediately (immediate ). Immediate is useful when a HPT has a high possibility of successful (i.e., transactions in soft RTDBS) by ing LPTs as early as possible. In rm RT- DBS, however, immediate might cause wasted s, which aects the performance adversely. Our observation on the executions of rm deadline transactions is that a HPT can proceed without ing con- icting LPTs if needed when we use deferred update policy which updates on local copies of item and makes them global at time. We only need to the LPT until the completion ( or ) of the conicting HPT. If a HPT is discarded by missing its deadline we can execute the ped LPT by resuming it. This is what we refer to as the /resume deferred policy. In order to dierentiate the cause of transaction blocking, we dene transaction ping as follows: Denition 2.1 (Transaction ping) Transaction ping is the blocking of a LPT and happens when a HPT tries to access a item which is accessed by the LPT. This is in contrast to the term blocking which describes the situation when a LPT tries to access a item accessed by a HPT and is waiting for the completion of that HPT. 2.2 Comparison of conict resolution policies In order to demonstrate the advantages and disadvantages of immediate and deferred policies, we study 4 cases that can arise when a HPT and a LPT conict with each other. These cases are depicted in Figures 1, 2, 3, and 4. For each case we evaluate 3 dierent methods, namely, OCC style deferred

3 (DR-OCC), immediate (IR), and /resume deferred (DR-SR). DR-OCC This policy is exactly the one used by OCC [HCL90a]. The validation and happen at time. IR This policy is exactly the one used by 2PL-HP. The validation and are done when conict occurs. DR-SR This policy uses early stage validation but time. When a HPT conicts with a lock holding LPT we the LPT until the completion time of the HPT. If the HPT completes successfully () then we the LPT. Otherwise (i.e., if the HPT s) we resume the LPT. The following summarizes the alternative outcomes and their relationship to the conict resolution policies described above: Case 1: Both LPT and HPT complete successfully as shown in Figure 1. It is clear that immediate is the best for them in order to have the earliest nish time for the LPT. Case 2: In this case HPT completes successfully and LPT misses its deadline. DR-SR is better in terms of wasting the least amount of system resources (as shown in Figure 2), but the LPT's eective service time of the IR approach is the longest among them. This indicates that IR has a much better chance of changing Case 2 to Case 1. Case 3: This case explains wasted of 2PL-HP most clearly. In Figure 3, IR is the worst among them due to wasted. Both deferred approaches, DR-OCC and DR-SR, are preferable in this situation. Even though DR-OCC looks the best among them, DR-SR is equally good because during the LPT's ped period we can execute other transactions. Case 4: This case (shown in Figure 4) happens when both HPT and LPT miss their deadlines. If we consider the waste of system resources, DR-SR is the best as it wastes less resources. Saving valuable resources reduces transaction arrival blocking under heavily loaded situations by giving many chances of execution to other transactions. This is likely to happen often in heavily loaded situations. By analyzing the 4 alternative outcomes between HPT and LPT transactions, we notice that combining IR and DR-SR properly could be benecial to using a single conict resolution policy. Based on this observation, we propose the following new concurrency control algorithm. Our algorithm is named Alternative Version Concurrency Control (AVCC) because it combines IR and DR-SR policies together by maintaining IR version and DR-SR version of a transaction at the same time. Immediate Restart (OCC) Restart Restart (Stop-Resume) Start Figure 1: Case 1: Both transactions nished successfully within their deadlines Restart (OCC) Start Immediate Restart L H Restart (-resume) Figure 2: Case 2: HPT completed successfully, LPT missed In AVCC, priorities of transactions are assigned using Earliest Deadline First (EDF) and all transaction updates are done on local copies and are made global at time { a deferred update policy. 2.3 Basic idea of AVCC A method for obtaining the advantages of both DR-SR and IR policies is to use both versions together in a meaningful way. If a lock requesting HPT T r conicts with a lock holding LPT T h we T h and initiate an additional immediately ed version T i (as an alternative of T h ). This is the policy adopted by AVCC and is illustrated in Figure 5. Thus we have a ped version as well as a ed version of the LPT at the same time. Even though the ped version T h takes some space it does not consume any processing time until it resumes its execution again. Meanwhile, T i can proceed up to the point that caused the and work from there after T r s, instead of starting from the beginning when T r s. If T r misses its deadline, T i is removed from the system and T h resumes its work from the ped position. This approach also can be viewed as a method to implement partial roll-

4 Start Restart (OCC) Immediate Restart L H Restart (-resume) resume Figure 3: Case 3: HPT missed, LPT completed successfully During the execution of a transaction, the IR version of a transaction might be ped again by another HPT and changed to DR-SR version and initiate a new IR version. Thus, in AVCC, each transaction might have multiple DR versions and a single IR version which is the leaf of the family tree. Only the IR version of a transaction can be allowed to run while the other DR-SR versions are waiting for their resumption. In Figure 6 we illustrate a general view of transactions' execution with 3 transactions, T i, T j, and T k. For each transaction a rectangle represents a local space for each version and the dark area in each space shows how much of the required has been processed by a version of the transaction. For simplicity we assume that the left one is the space of right one's parent. The parent's processed space is always more than its child's. Start Restart (OCC) Immediate Restart Restart (-resume) Ti Tj Tk resume Figure 4: Case 4: Both LPT and HPT missed their deadlines backs without using the save point mechanism. T i is a partially rolled back version of T h when T r s. By maintaining the ped version and initiating the ed version, AVCC can reduce wasted and wasted execution. In AVCC the execution path of T h and T i is exactly the same when T r is still in the system because T r has locks on the shared and the value of input does not change within the deadline of T h. DR version T h and IR version T i has a parent/child relationship so that T i can inherit the deadline and priority of T h and can access the accessed by T h freely. LPT Ti Th Tr HPT : ped tr : not ped tr : relationship : parent/child relationship Figure 5: and immediate versions local area Global, Shared lock table Figure 6: Execution structure of AVCC More complete details and performance evaluation of AVCC can be found in [Hon95]. 3 Extension of AVCC In order to handle a mixed load of transactions (that have dierent time constraints) we extend the priority mechanism. First, we classify the incoming transactions into 3 classes according to their time constraints. The priority of a transaction consists of two elds, class and time-priority. For soft (class 2) and rm (class 3), we use EDF (earliest deadline rst) priority assignment for their time-priority and we assign 0 (zero) as timepriority for all non real-time transactions. Data conict resolutions are done as follows: If a LPT conicts with a HPT or a transaction with the same priority, we use blocking mechanism irrespective of its class. When a HPT of soft deadline conicts with a LPT, we use IR and if a HPT of rm deadline conicts with a LPT, we use IR and DR-SR together. Thus the

5 Class Transaction Conict resolution Priority class 1 non real-time Blocking only (1, -) class 2 soft deadline Blocking, IR (2, EDF) class 3 rm deadline Blocking, DR-SR and IR (3, EDF) Table 1: Classication and Priority assignment of extended AVCC extended AVCC works as 2PL for non real-time transactions, EDF-HP for soft deadline transactions, and AVCC for rm deadline transactions. Class specication of a transaction could be changed dynamically as mentioned earlier (when they access a real-time, for example). Class specication of a transaction could be upgraded from 1 to 2 or 3, or from 2 to 3 but class downgrading is not allowed as it does not make sense semantically. A blocked or ped transaction will not create any problem in our approach because class upgrading happens only when a transaction is running. As the proposed approach uses a blocking scheme for transactions with the same priority (all non real-time transactions have the same priority, soft and rm transactions might have the same priority), deadlocks can happen. Deadlocks are detected by maintaining a waitfor graph for each class (note that deadlocks cannot happen across classes) and searching for cycles whenever a new arc is added to the graph. When a deadlock is detected a victim is selected by choosing the transactions which correspond to the arc which completes the cycle in the graph (transactions in the cycle have the same priorities). 4 Conclusions In many applications incoming transactions are usually a mixed load of non real-time, soft, and rm deadline transactions and the mix (and whether it is a mix) is not known a priori. Thus concurrency control algorithm of RTDBS need to be able to handle non real-time, soft, rm, or any combinations thereof eciently. Early validation is good for non real-time and soft, but causes wasted for rm. Late validation is good by reducing wasted for rm but bad for non real-time, soft, and rm as they incur wasted execution. In this paper, we have shown a way to extend AVCC for mixed load environment. Extended AVCC works like 2PL for non real-time, 2PL-HP for soft, and AVCC for rm deadline transactions. As shown in the previous section, extending locking based algorithms for mixed load was not very dicult because early stage validation mechanism can use time constraints of transactions in the form of priority easier than late stage validation mechanism. Performance evaluation for the mixed load is not an easy task. There are a number of issues to be addressed here. For example, what is a proper performance metrics if incoming transactions are a mixed load of non real-time, soft, and rm transactions? Transaction miss percent and TPS (Transactions Per Second) are the most common performance metric for real-time and conventional base systems, respectively. A proper performance metric need to be developed for the mixed load environment. References [ACL87] Rakesh Agrawal, Michael J. Carey, and Miron Livny. Concurrency control performance modeling: Alternatives and implications. ACM Transactions on Database Systems, 12(4):609{654, [AD85] Rakesh Agrawal and D. DeWitt. Integrated concurrency control and recovery mechanism: Design and performance evaluation. ACM Transactions on Database Systems, 10(4):529{564, [AGM88] Robert Abbott and Hector Garcia-Molina. Scheduling real-time transactions: a performance evaluation. In Proceedings of the 14th VLDB, pages 1{12. ACM, [CS84] Michael J. Carey and Michael R. Stonebraker. The performance of concurrency control algorithms for base management systems. In Proceedings of the 10th VLDB, pages 107{118. ACM, [HCL90a] Jayant R. Haritsa, Michael J. Carey, and Miron Livny. Dynamic real-time optimistic concurrency control. In Proceedings of Real- Time System Symposium, pages 94{103, Lake Buena Vista, Florida, IEEE. [HCL90b] Jayant R. Haritsa, Michael J. Carey, and Miron Livny. On being optimistic about realtime constraints. In Symposium of Principles of Database systems, pages 331{343. ACM, [HJC93] D. Hong, T. Johnson, and S. Chakravarthy. Real-time transaction scheduling: A Cost- Conscious Approach. In Proceedings of the 1993 ACM SIGMOD Int'l Conference on Management of Data, pages 197{206. ACM, 1993.

6 [HLC91] Jayant R. Haritsa, Miron Livny, and Michael J. Carey. Earliest deadline scheduling for real-time base systems. In Proceedings of Real-Time System Symposium, pages 232{242, San Antonio, Texas, IEEE. [Hon95] D. Hong. Real-Time transaction scheduling for conventional and active base systems. PhD thesis, University of Florida, Dept. of CISE, [HSRT91] Jiandong Huang, John A. Stankovic, Krithi Ramamritham, and Don Towsley. Experimental evaluation of real-time optimistic concurrency control schemes. In Proceedings of the 17th VLDB, pages 35{46. ACM, [LLH95] Kwokwa Lam, Kamyiu Lam, and Sheunglun Hung. An ecient real-time optimistic concurrency control protocol. In Proceedings of ACM Workshop on Active and Real-Time base systems, pages 100{110. ACM, [LS93] Juhnyoung Lee and Sang H. Son. Using dynamic adjustment of serialization order for real-time base systems. In Proceedings of Real-Time Systems Symposium, pages 66{ 75. IEEE, [PSS + 94] B. Purimetla, R.M. Sivasankaran, J.A. Stankovic, K. Ramamritham, and D. Towsley. A priority assignment in real-time active bases. Technical Report UM-CS , University of Massachusetts at Amherst, [Ram95] Krithi Ramamritham. The Origin of TCs: Where do the Time Constraints come from? In Proceedings of ACM Workshop on Active and Real-Time base systems, pages 184{ 187. ACM, 1995.