OCC and Its Variants. Jan Lindström. Helsinki 7. November Seminar on real-time systems UNIVERSITY OF HELSINKI. Department of Computer Science

Transcription

1 OCC and Its Variants Jan Lindström Helsinki 7. November 1997 Seminar on real-time systems UNIVERSITY OF HELSINKI Department o Computer Science

2 Contents 1 Introduction 1 2 Optimistic Concurrency Control Backward Validation Forward Validation Unnecessary restarts Optimistic Concurrency Control protocols WAIT OCC-TI OCC-DA Conclusions 13 Reerences 14

3 1 1 Introduction Real-time database systems (RTDBS) are database systems which must process transactions within deinite time bounds usually deined in the orm o a deadline. Failure to complete transactions beore their deadlines reatly derades the useulness o the transactions. The applications o RTDBS can be ound in prorams tradin in the stock market, computer interated manuacturin, military command and control manaement, and network manaement systems. In RTDBS, the primary perormance criterion is timeliness level and not averae response time or throuhput. Schedulin o transactions is driven by priority considerations rather than airness considerations. Perormance oals o RTDBSs is dierent rom those or conventional database systems. Thereore RTDBSs require new transaction manaement methods to satisy the perormance oals. Considerable research has recently been devoted to desinin concurrency control alorithms or RTDBSs and to evaluatin their perormance. Most o these studies use the serializability [EGLT76] or maintainin data consistency. Because at present there is no eneral-purpose consistency criterion available that is less strinent than serializability. New consistency criterion should be as obviously correct and easily implementable as serializability. Most o the proposed alorithms are based on one o the two basic mechanisms: two-phase lockin (2PL) [EGLT76] and optimistic protocols (OPT) [KR81]. Conventional concurrency control protocols are oten unsatisactory or real-time databases, because they do not observe transaction priorities. In this paper we concertrate on optimistic protocols. The remainder o this paper is oranized in the ollowin ashion: Section 2 reviews principles o optimistic concurrency control. In Section 3, we present classical optimistic protocols and two new OCC protocols in detail. Finally, Section 3 summarizes the main conclusions o this study.

4 2 2 Optimistic Concurrency Control In Optimistic Concurrency Control (OCC) [KR81], transactions are allowed to execute unhindered until they reach their commit point, at which time they are validated. The execution o a transaction consists o three phases, read phase, validation phase, and write phase. The read phase is the normal execution o the transaction. Write operations are perormed on the private data copies in the local workspace o the transaction. This kind o operation is called pre-write. Identiication o all read data items are stored in a readset. Identiication o all pre-written data items are stored in a writeset. Readset and writeset are used to check conlicts aainst other active transactions. The validation phase ensures that all the committed transactions have executed in a serializable ashion. Every validation scheme is based on the ollowin principles to ensure serializability. I a transaction T i is serialized beore transaction T j, the ollowin two conditions must be satisied: 1. No overwritin. The writes o T i should not overwrite the writes o T j. 2. No read dependency. The writes o T i should not aect the read phase o T j. Generally, condition 1 is automatically ensured in most optimistic alorithms because I/O operations in the write phase are required to be done sequentially in critical section. Thus most validation schemes consider only condition 2. Durin the write phase, all chanes made by the transaction are permanently installed into the database. To desin eicient real-time OCC protocol, three issues have to be considered: 1. which validation scheme should be used to detect data conlicts amonst transactions; 2. how to minimize the number o transaction restarts; and 3. how to select a transaction to restart when there are conlicts. 2.1 Backward Validation In Backward Validation [Här84], the validatin transaction is checked or conlicts aainst (recently) committed transactions. Data conlicts are detected by comparin the read set o

5 3 the validatin transaction and the write set o the committed transactions. I the validatin transaction has a data conlict with any committed transactions, it will be restarted. The classical optimistic alorithm in [KR81] is based on this validation process. Let T v be the validatin transaction and T c (c = 1; 2; :::; n; c 6= v) be the transactions recently committed with respect to T v. Let RS(T ) and W S(T ) denote the read set and the write set o the transaction T, respectively. Backward Validation protocol is presented in iure 1. validate(t v ) valid = true; or T c (c = 1; 2; :::; n) i W S(T c ) \ RS(T v ) 6= ; then valid = alse; i not valid then break; i valid then commit W S(T v ) else restart(t v ); to database; Fiure 1: Backward Validation alorithm. 2.2 Forward Validation In Forward Validation [Här84], the validatin transaction is checked or conlicts aainst other active transactions. Data conlicts are detected by comparin the write set o validatin transaction and the read set o the active transactions. I active transaction has read an object that has been concurrently written by the validatin transaction, the values o the object used by the transactions are not consistent. Such data conlict can be resolved by restartin either the validatin transaction or the conlictin transactions in the read phase. Optimistic alorithms based on this validation process are studied in [Här84]. Let T a (a = 1; 2; :::; n; a 6= v) be the conlictin transactions in their read phase. Forward Validation protocol is presented in iure 2.

6 4 validate(t v ) valid = true; or T a (a = 1; 2; :::n) i RS(T a ) \ W S(T v ) 6= ; then valid = alse; i not valid then break; i valid then commit W S(T v ) to database; else conlict resolution(t v ); Fiure 2: Forward Validation alorithm. In the real-time database systems, data conlicts should be resolved in avor o the hiher priority transactions. Forward Validation provides lexibility or conlict resolution. Either the validatin transaction or the conlictin active transactions may be chosen to restart. Thereore it is preerable or the real-time database systems. In addition to this lexibility, Forward Validation has the advantae o early detection and resolution o data conlicts. 2.3 Unnecessary restarts The major perormance problem with OCC protocols is the heavy restart overheads, wastin lare amount o resources. Forward Validation is based on the assumption that the serialization order o transactions is determined by the arrivin order o transactions at vali dation phase. Thus the validatin transaction, i not restarted, always precedes concurrently runnin active transactions in serialization order. Validation process based on previous assumption can incur restarts not necessary to ensure data consistency. These restarts should be avoided. Let r i [x] and w i [x] denote a read and write operation, respectively, on the data object x by transaction T i, and let v i and c i denote the validation and commit o transaction T i, respectively. Consider transactions T 1 and T 2 : T 1 : r 1 [x]w 1 [x]v 1 c 1

7 5 T 2 : r 2 [x]w 2 [y]v 2 c 2 and suppose they execute as ollows: H 1 = r 2 [x]w 2 [y]r 1 [x]w 1 [x]v 1 Based on the traditional OCC, T 2 has to be restarted. However, it is not necessary. Because i T 2 is allowed to commit such as: H 1 = r 2 [x]w 2 [y]r 1 [x]w 1 [x]v 1 c 1 v 2 c 2, the history, H 1, is equivalent to the serialization order o T 2! T 1. There is no cycle in the history H 1. Thereore execution is serializable 2. 3 Optimistic Concurrency Control protocols In recent years, the use o optimistic schemes or concurrency control in real-time optimistic protocols has received more and more attention. Dierent real-time optimistic protocols have been proposed. They incorporate dierent priority conlict resolution methods in the validation phase o a transaction. In this paper we briewly present ew popular optimistic protocols and three optimistic protocols in detail. OPT-BC [HCL90b] extends classical optimistic protocol with Broadcast Commit [MN82, Rob87] protocol. In Broadcast Commit protocol the transaction notiies other runnin transactions that conlict with it. The conlictin transactions are restarted. OPT-SACRIFICE [HCL90a] is an optimistic protocol which uses a priority-driven abort or conlict resolution. When a transaction reaches its validation phase, alorithm checks or conlicts with currently executin transactions. I conlicts are detected and at least one o the transactions in the conlict set is a hiher priority transaction, then the validatin transaction is restarted. It is sacriiced in an eort to help the hiher priority transactions make their deadlines. OPT-WAIT [HCL90a] alorithm incorporates a priority wait mechanism. When transaction reaches its validation phase, i its priority is not the hihest amon the conlictin transactions, it waits or the conlictin transactions with hiher priority to complete. This ives the hiher

8 6 priority transactions a chane to make their deadlines irst. I transaction inally commits ater waitin or some time, it causes all its conlictin transactions with lower priority to be restarted. This problem becomes worse with the possibility o chained blockin, which may cause cascaded aborts. 3.1 WAIT-50 The WAIT-50 [HCL90a] alorithm is an extension o the OPT-WAIT. It incorporates a wait control mechanism. This mechanism monitors transaction conlict states and dynamically decides when, and or how lon, a low priority transaction should be made to wait or its conlictin hiher priority transactions. In WAIT-50 scheme, a validatin transaction is made to wait as lon as more than hal the transactions that conlict with it have hiher priorities. Otherwise it commits and all the conlictin transactions are restarted. The basic idea o WAIT-50 scheme is to maximize the beneicial eects o blockin, while reducin the eects o its drawbacks. A transaction s conlict state is assumed to be characterized by the index HPpercent. HPpercent is the percentae o the conlictin hiher priority transactions. The validation alorithm is presented in iure 3. validate(t v ) while conlictin hiher priority transactions and HPpercent 50 wait; or 8 T a 2 conlict set(t v ) restart(t a ); commit W S(T v ) to database; Fiure 3: Validation alorithm or WAIT-50. Perormance studies in [HCL90a] has shown WAIT-50 to provide siniicant perormance ains over OPT-BC, OPT-SACRIFICE and OPT-WAIT.

9 7 3.2 OCC-TI OCC-TI [LS93, Lee94] protocol resolves conlicts usin time intervals o the transactions. Every transaction must be executed in a speciic time slot. When an access conlict occurs, it is resolved usin the read and write sets o the transaction toether with the allocated time slot. Time slots are adjusted when a transaction commits. In this protocol, every transaction in the read phase is assined an timestamp interval. This timestamp interval is used to record temporary serialization order induced durin the execution o the transaction. At the start o execution, the timestamp interval o the transaction is initialized as [0; 1[, i.e., the entire rane o timestamp space. Whenever serialization order o the transaction is induced by its data operation or the validation o other transactions, its timestamp interval is adjusted to represent the dependencies. In the read phase when a read operation is executed, write timestamp o the object accessed is veriied aainst the time interval allocated to the transaction. I another transaction has written the object outside the time interval, the transaction must be restarted. In the read alorithm (iure 4) D i is the object to be read, T i is the transaction readin the object, T I(T i ) is the time interval allocated to the transaction, W T S(D i ) is the write timestamp o the object, and RT S(D i ) is the read timestamp o the object. read(t i ; D i ) T I(T i ) = T I(T i ) \ [W T S(D i ); 1[ ; i T I(T i ) = [] then restart(t i ); read(d i ); Fiure 4: Read alorithm or OCC-TI. In the read phase when a write operation is executed, the modiication is made to local copy o the object. A pre-write operation is used to veriy read and write timestamps o the written object aainst the time interval allocated to the transaction (iure 5). I another transaction has read or written the object outside the time interval, the transaction must be restarted.

10 8 pre-write(t i ; D i ) T I(T i ) = T I(T i ) \ [W T S(D i ); 1[ \ [RT S(D i ); 1[ ; i T I(T i ) = [] then restart(t i ); Fiure 5: Pre-write alorithm or OCC-TI. At the beinnin o the validation (iure 6) the inal timestamp o the validated transaction is determined rom the timestamp interval allocated to the transaction. In this alorithm, we always select the minimum value o T I(T v ) or T S(T v ). The timestamp intervals o all concurrently runnin and conlictin transactions must be adjusted to relect the serialization order. Any transaction which timestamp interval becomes empty must be restarted. validate(t v ) select T S(T v ) rom T I(T v ) ; or 8 T a 2 active transactions() adjust(t v ; T a ); or 8 D i 2 RS(T v ) update(rt S(D i )); or 8 D i 2 W S(T v ) update(w T S(D i )); commit W S(T v ) to database; Fiure 6: Validation alorithm or OCC-TI. The adjustment o timestamp intervals o a runnin transaction iterates throuh the readset and writeset (iure 7). When access has been made to the same objects both in validatin transaction and in the compared transaction, the time interval o the compared transaction is adjusted. I a compared transaction has made a conlictin operation in an adjusted time interval, the transaction must be restarted.

11 9 adjust(t v ; T a ) or 8 D i 2 RS(T v ) i D i 2 W S(T a ) then T I(T a ) = T I(T a ) \ [T S(T v ); 1[ ; i T I(T a ) = [] then restart(t a ); or 8 D i 2 W S(T v ) i D i 2 RS(T a ) then T I(T a ) = T I(T a ) \ [0; T S(T v )? 1]; i D i 2 W S(T a ) then T I(T a ) = T I(T a ) \ [T S(T v ); 1[ ; i T I(T a ) = [] then restart(t a ); Fiure 7: Adjust alorithm or OCC-TI. Perormance studies in [LS93] has shown that under the policy that discards tardy transactions rom the system, the optimistic alorithms outperorm 2PL-HP [AGM88]. OCC-TI does better than OPT-BC amon the optimistic alorithms. The perormance dierence between OPT-BC and OCC-TI becomes lare especially when the probability o a data object read bein updated is low, which is true in most actual database systems. 3.3 OCC-DA OCC-DA [LLH96] is based on the Forward Validation scheme. The number o transaction restarts is reduced by usin dynamic adjustment o serialization order. This is supported with the use o a dynamic timestamp assinment scheme. Conlict checkin is perormed at the validation phase o a transaction. No adjustment o the timestamps is necessary in case o data conlicts in the read phase. In OCC-DA serialization order o committed transactions may be dierent rom their commit order. Suppose we have a validatin transaction T v and a set o active transactions T j (j = 1; 2; :::; n; j 6=

12 10 v). There are three possible types o data conlicts which can induce serialization order between T v and T j. 1. RS(T v ) \ W S(T j ) 6= ; (write-read conlict) Write-read conlict between T j and T v can be resolved by adjustin the serialization order between T v and T j as T v! T j so that the read o T v cannot be aected by T j s write. This type o serialization adjustment is called orward adjustment. 2. W S(T v ) \ RS(T j ) 6= ; (read-write conlict) Read-write conlict between T j and T v can be resolved by adjustin the serialization order between T v and T j as T j! T v. It means that the read phase o T j is placed beore the write o T v. This type o serialization adjustment is called backward adjustment. 3. W S(T v ) \ W S(T j ) 6= ; (write-write conlict) Write-write conlict between T j and T v can be resolved by adjustin the serialization order between T v and T j as T v! T j such that write o T v cannot overwrite T j s write. This type o serialization adjustment is called orward adjustment. To support dynamic adjustment o serialization order in OCC-DA, a dynamic timestamp assinment method is used. For each transaction, T i, there is a timestamp called serialization order timestamp SOT (T i ) to indicate its serialization order relative to other transactions. Initially, the value o SOT (T i ) is set to be 1. I the value o SOT (T i ) is other than 1, it means that T i has been backward adjusted beore a committed transaction. I T i has been backward adjusted, SOT (T i ) will also be used to detect whether T i has accessed any invalid data item. This is done by comparin its timestamp with the timestamps o the committed transactions which have read or written the same data item. A data item in its read set and write set is invalidated i the data item has been updated by other committed transactions which have been deined ater the transaction in the serialization order. When T v comes to validation, the sets o active transactions, T i, whose serialization order timestamp, SOT (T v ) SOT (T i ) are collected to set AT S(T v ). The set o active transactions, T j, whose serialization order timestamp, SOT (T j ) < SOT (T v ) are collected to set BT S(T v ). In read phase T R(T v ; D p ) is set to be W T S(D p ) o read data item D p.

13 11 The irst part o the validation test is used only or those validatin transactions which have been backward adjusted (iure 8). It is to check whether: 1. all the read operations o T v have been read rom the committed transactions T c whose SOT (T c ) < SOT (T v ), and 2. whether T v s write is invalidated. This is done by comparin SOT (T v ) with W T S(D p ) and RT S(D p ) o the data item D p in T v s write set or read set. part one(t v ) i SOT (T v ) 6= 1 then or 8 D p 2 RS(T v ) i T R(T v ; D p ) > SOT (T v ) then restart( T v ); or 8 D p 2 W S(T v ) i SOT (T v ) < RT S(D p ) or SOT (T v ) < W T S(D p ) then restart( T v ); Fiure 8: First part o the validation alorithm or OCC-DA. The purpose o part two o the test is to detect read-write conlicts between the active transactions and the validatin transactions (iure 9). The write set o T v is compared with the read sets o the active transactions T j. The identity o the conlictin active transactions T j are added to BT list(t v ) to indicate that T j needs to be backward adjusted beore T v.

14 12 part two(t v ) BT list(t v ) = ; ; or 8 T j 2 AT S(T v ) or 8 D p 2 W S(T v ) i D p 2 RS(T j ) then BT list(t v ) = BT list(t v ) [ T j ; Fiure 9: Second part o the validation alorithm or OCC-DA. The third part o the test is to detect whether a backward-adjusted transaction T j also needs orward adjustment with respect to T v (iure 10). It compares the write set o T j which is in BT S(T v ) or in BT list(t v ) with the read set o T v, and the write set o T v with the write sets o T j. I either one o them is not empty, T j has serious conlict with T v. In conlict resolution we select transactions or restart based on priorities. part tree(t v ) or 8 T j 2 BT S(T v ) [ BT list(t v ) or 8 D p 2 RS(T v ) i D p 2 W S(T j ) then conlict resolution(t v ; T j ); or 8 D p 2 W S(T v ) i D p 2 W S(T j ) then conlict resolution(t v ; T j ); Fiure 10: Third part o the validation alorithm or OCC-DA. When the validatin transaction reaches part our o the test, it is uaranteed to commit. The purpose is to assin a inal commitment timestamp to the validatin transaction and to update the necessary timestamps o the data items (iure 11).

15 13 part our(t v ) i SOT (T v ) = 1 then SOT (T v ) = validation time ; or 8 T j 2 BT list(t v ) SOT (T j ) = SOT (T v )? ; //ininitesimal quantity or 8 D p 2 RS(T v ) RT S(D p ) = SOT (T v ) ; or 8 D p 2 W S(T v ) W T S(D p ) = SOT (T v ) ; commit W S(T v ) to database; 4 Conclusions Fiure 11: Fourth part o the validation alorithm or OCC-DA. Concurrency control is one o the main issues in the studies o real-time database systems. With a strict consistency requirements deined by serializability, many real-time concurrency control schemes considered in literature are based on two-phase lockin (2PL). This is not surprisin since 2PL has been well studied in traditional database systems and is bein widely used in commercial databases. But 2PL has some inherent problems such as the possibility o deadlocks and lon and unpredictable blockin times. These appear to be serious problems or real-time transaction processin. Since in a real-time environment, transactions need to meet their time constraints as well as consistency requirements. Thereore some alternatives to two-phase lockin or real-time systems have been proposed and studied. Amon them is a class o concurrency control schemes based on the well-know optimistic approach. Optimistic concurrency controll has the properties o non-blockin and deadlock reedom. These properties make the optimistic scheme especially attractive to realtime database system. Optimistic protocols can be based on Backward Validation or Forward Validation. Most o propoced alorithms are based on Forward Validation. OPT-BC extend optimistic concurrency control protocol with Broadcast Commit. OPT-SACRIFICE uses priority driven abort conlict resolution. OPT-WAIT incorporates priority wait mechanism. WAIT-50 is extension

16 14 o OPT-WAIT incorcorporatin wait control mechanism. OCC-TI resolves conlicts usin time intervals o transaction. OCC-DA reduces transaction restarts and resolves conlicts usin dynamic timestamp assinment. From presented protocols OCC-DA is shown to be most powerul alorithm. Reerences [AGM88] R. Abbott and H. Garcia-Molina. Schedulin real-time transactions: A perormance evaluation. In F. Bancilhon and D. J. DeWitt, editors, Proceedins o the 14th VLDB Conerence, paes 1 12, San Mateo, Cali., Moran Kaumann. [EGLT76] K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traier. The notions o consistency and predicate locks in a database system. Commun. ACM, 19(11): , November [Här84] T. Härder. Observations on optimistic concurrency control schemes. Inormation Systems, 9(2): , [HCL90a] J. R. Haritsa, M. J. Carey, and M. Livny. Dynamic real-time optimistic concurrency control. In Proceedins o the 11th Real-Time Symposium, paes , Los Alamitos, Cali., IEEE, IEEE Computer Society Press. [HCL90b] J. R. Haritsa, M. J. Carey, and M. Livny. On bein optimistic about real-time constraints. In Proceedins o the 9th ACM Symposium on Principles o Database Systems, paes ACM, ACM Press, [KR81] [Lee94] H. T. Kun and J. T. Robinson. On optimistic methods or concurrency control. ACM Transaction on Database Systems, 6(2): , June J. Lee. Concurrency Control Alorithms or Real-Time Database Systems. PhD thesis, Faculty o the School o Enineerin and Applied Science, University o Virinia, January [LLH96] K. Lam, K. Lam, and S. Hun. An eicient real-time optimistic concurrency control protocol. In Proceedins o the First International Workshop on Active

17 15 and Real-Time Database Systems, paes , Skövde, Sweden, June Spriner. [LS93] [MN82] [Rob87] J. Lee and S. H. Son. Usin dynamic adjustment o serialization order or real-time database systems. In Proceedins Real-Time Systems Symposium, paes 66 75, Los Alamitps, Cali., IEEE, IEEE Computer Society Press. D. Menasce and T. Nakanishi. Optimistic versus pessimistic concurrency control mechanisms in database manaement systems. Inormation Systems, 7(1):13 27, J. Robinson. Desin o Concurrency Controls or Transaction Processin Systems. PhD thesis, Carneie Mellon University, December 1987.