transaction scheduling in distributed real-time systems

The International Journal of Time-Critical Computing Systems, 19, 169–193 (2000)c© 2000 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Transaction Scheduling in Distributed Real-TimeSystems

KWOK-WA LAMDepartment of Computer Science, City University of Hong Kong, 83 Tat Chee Avenue, Kowloon, Hong Kong

VICTOR C. S. LEE [email protected] of Computer Science, City University of Hong Kong, 83 Tat Chee Avenue, Kowloon, Hong Kong

SHEUNG-LUN HUNGDepartment of Computer Science, City University of Hong Kong, 83 Tat Chee Avenue, Kowloon, Hong Kong

Abstract. In this paper, we study the performance of using optimistic approach to concurrency control indistributed real-time database systems (RTDBS). The traditional optimistic approach suffers from the problem ofunnecessary restarts. Transaction restarts can significantly increase the system workload and intensify resourceand data contention. In distributed environments, the complexity of the system and the high communicationoverhead exacerbate the problem. Therefore, the number of unnecessary restarts is the determinant factor thataffects the performance of optimistic approach in distributed RTDBS. When optimistic approach is extended todistributed environments, a number of issues resulting from the increased complexity and communication overheadhave to be resolved. In this paper, a new real-time distributed optimistic concurrency control (DOCC) protocolwith dynamic adjustment of serialization order (DASO), called DOCC-DA is proposed. This protocol can avoidunnecessary transaction restarts by dynamically adjusting the serialization order of the conflicting transactions.Therefore, resources can be saved and more transactions can meet their deadlines. In the DOCC-DA protocol, a newdistributed circular validation scheme is included to facilitate transaction validation in distributed environments.The performance of the DOCC-DA protocol has been examined in detail by simulation. The results showed thatthe performance of the DOCC-DA protocol is consistently better than that of other protocols.

Keywords: distributed real-time databases, optimistic concurrency control, dynamic adjustment of serializationorder, distributed circular validation

1. Introduction

A real-time database system (RTDBS) is one whose basic specification and design criteriamust include the requirement of meeting the timing constraints of real-time transactions(Yu, 1994). The correctness of RTDBS depends on not only the logical correctness, butalso the timeliness of the results. That is, a transaction must be completed within a specifiedtime, called deadline. If the deadlines are missed, the consequence can be either loss ofthe transaction’s values or catastrophe, depending on the characteristics of the applications(Ramamritham, 1993). Common applications of RTDBS can be found in internationalfinancial market systems, air traffic controlling systems, nuclear power plant managementsystems and integrated manufacturing systems.

The goal of scheduling transactions in RTDBS is two-fold: to meet the timing constraintsand to ensure the data consistency. Priority-based scheduling in real-time systems can beadopted to enforce timing constraints of transactions while concurrency control in database

170 LAM, LEE AND HUNG

systems can be used to maintain data consistency. Unfortunately, the two mechanisms oftenoperate in an incompatible manner. For instance, many concurrency control protocols arebased on transaction blocking such as the two-phase locking (2PL) protocol (Bernstein,1987). However, transaction blocking may cause priority inversion in which a high prioritytransaction is blocked by lower priority transactions (Huang, 1992; Sha, 1990) and priorityinversion has a negative impact on real-time scheduling.

Optimistic concurrency control (OCC) protocols are another popular approach to concur-rency control for RTDBS. Some studies (Haritsa, 1990, 1992) showed that OCC protocolsoutperform 2PL protocols over a wide range of system loading and resource availabilityin firm RTDBS. The main reason is due to the nice properties of the OCC protocols thatare non-blocking, deadlock-free and fruitful restarts. In OCC protocols, conflict resolutionis performed at the end of a transaction execution. Therefore, restarting other conflictingtransactions must result in a transaction commitment. We called this fruitful restart. Onthe other hand, in 2PL protocols, a transaction which restarts other conflicting transactionsmay eventually be aborted and discarded (Abbott, 1992; Lam, 1994). Such restarts of theconflicting transactions are called fruitless restarts.

However, the restart-based conflict resolution policy adopted in OCC protocols incurs highwastage of resources (Kung, 1981). Transaction restarts have two negative implications inRTDBS. Firstly, since the number of restarts can be unbounded, if the restarted transactionsmiss their deadlines in the end, the time and resources spent on them will be wasted.Secondly, the time and resources needed to handle restarted transactions may seriouslyaffect active transactions to meet their deadlines. Thus, for RTDBS, it is particularlyimportant to reduce the number of transaction restarts such that the amount of the resourceswasted can be reduced and more transactions can meet their deadlines. In fact, the numberof restarts incurred by OCC protocols is the major factor deciding the performance ofconcurrency control in RTDBS (Datta, 1997).

Many real-time applications are inherently distributed such as advanced command andcontrol systems (Son, 1993; Ulusoy, 1994). Distributed database fits more naturally intheir decentralized structures. Distributed database systems allow transactions to accessshared data at remote sites. While transactions are scheduled under timing constraints in adistributed RTDBS, it should also be ensured that both the global consistency and the localconsistency of a distributed database are preserved. To this end, it is required to exchangemessages containing scheduling information between the sites where the transaction is beingexecuted. The communication delays caused by message exchanges constitute substantialoverheads to the response time of a distributed transaction. Thus, it becomes more difficultto satisfy the timing constraint of transactions in distributed RTDBS than in a centralizedone.

To reduce the number of unnecessary restarts in OCC protocols, Leeet al (Lee, 1993b)suggested the OCC-TI protocol which utilized the notion of dynamic adjustment of serial-ization order (DASO) and timestamp intervals (Konana, 1997). In the OCC-TI protocol,the serialization order between transactions is dynamically induced according to the typesof data conflicts. The temporary serialization order of a transaction relative to others isdefined by its timestamp interval. The timestamp interval of an active transaction may beadjusted at the validation of another transaction or when data conflict is detected during its

TRANSACTION SCHEDULING 171

read phase. Whenever the timestamp interval of a transaction shuts out, a non-serializableexecution is detected and the transaction will be restarted. Their performance study (Lee,1993b) showed that the OCC-TI outperformed other OCC protocols and claimed that themost determinant factor on the performance of OCC protocols is the number of transactionrestarts.

However, the OCC-TI protocol becomes ineffective if it is simply extended to distributedenvironments. The OCC-TI protocol requires updating the timestamp interval of a trans-action for each data access or when a conflicting transaction commits. Since the samecurrent timestamp interval of a transaction must be kept by all its sub-transactions, it willcause many message passings between sub-transactions. Consequently, data scheduling atone site is tightly coupled by data scheduling at other sites and transaction commits. Thiswill lead to a high degree of system inefficiency in terms of resource utilization and highoverheads. Another ineffectiveness of the OCC-TI protocol is its handicap in handling thewrite-write conflicts that are common in many RTDBS.

As suggested by Lee (1993b), the effective approach to enhancing the performance ofOCC protocols in RTDBS is to reduce the number of transaction restarts which can beachieved by using the notion of DASO. However, utilizing the notion of DASO in distributedenvironments poses different issues in designing the protocol. In this paper, we attempt toaddress the impact of transaction restarts on the performance of a distributed RTDBS. Wepresent a new distributed optimistic concurrency control (DOCC) protocol called DOCC-DA, which reduces the number of transaction restarts by using the notion of DASO. TheDOCC-DA protocol does not require many message passings in inducing the temporaryserialization order of a transaction. Hence, each site may have more autonomy in schedulingdata to transactions and the sites are not tightly coupled with each other. This is a desirablefeature for distributed applications such as industrial automation and banking where delaysassociated with inter-process communications and remote database accesses are of realconcern (Son, 1990). Another contribution of our work is that our new protocol can resolvewrite-write conflicts between transactions such that the number of restarts can be furtherreduced. The remainder of this paper is organized as follows. Section 2 describes thedesign issues of OCC protocol in distributed environments and our approach to solvingthese issues. The DOCC-DA protocol is presented in section 3. Section 4 describes theperformance model for evaluation of the DOCC-DA protocol. In section 5, we discuss theperformance results and conclude the study in section 6.

2. Design Issues of OCC in Distributed RTDBS

In this section, we discuss the issues to be resolved when the notion of DASO is utilizedin designing an OCC protocol in distributed environments. First, we will describe thedistributed real-time database model and the problem of unnecessary restarts. Then, weexplain the use of DASO to alleviate the problem of unnecessary restarts. We also discusshow to precisely adjust and record the temporary serialization order with few messagepassings and how to design an efficient validation scheme when the use of DASO bringsout the increased complexity in distributed environments.


2.1. Distributed Real-Time Database Model

In a distributed database system, information is stored across a number of sites intercon-nected through a reliable communication network. Each site has a system-wide uniqueidentifier, and sites communicate through messages. All messages sent arrive at their des-tinations in finite time and in the order of sending. Each site is equipped with a logicalclock, and clocks of all sites are loosely synchronized. The system provides a function,which upon being called generates a system-wide unique timestamp with the help of its siteidentifier and the local clock.

Each distributed transaction is a collection of sub-transactions that execute at various siteswhere the requested data objects reside. Each transaction is assigned a globally uniquepriority based on its real-time constraint. This priority is carried by all its sub-transactions.The operations of a transaction are executed in a sequential manner, one at a time. Asub-transaction accesses its data objects and performs its processing independent of thesub-transactions of other transactions.

A transaction is executed in three phases (Kung, 1981): a read phase, a validation phaseand a write phase if the validation is successful. In the read phase, the requested data objectsare read from the database and write operations are performed on a private workspace notaccessible to other transactions. At the end of transaction execution, the last two phases areinitiated. Validation phase ensures that the execution of a validating transaction preservesserializability. Conflict resolution relies on transaction restart. In the write phase, allupdates made by a transaction will be transferred to the database and are then made visibleto other transactions.

Transactions are scheduled to access resources such as CPU and data objects based on theirpriorities. The priorities of transactions may represent their urgency or criticality dependingon the assignment policy of priority to transactions. The priorities of transactions can bestatic and dynamic (Ramamritham, 1993). As reported in (Abbott, 1992), dynamic priorityassignment achieves better system performance than static one in most cases. One of thebest dynamic priority assignment schemes is based on the deadlines of transactions. Hence,we use earliest deadline first algorithm to assign priorities to transactions.

2.2. Problem of Unnecessary Restarts

There are two validation schemes commonly used in conventional OCC protocols, namelybackward validation and forward validation (Harder, 1984). In the backward validationscheme, the serializability of transaction execution is checked against the committed trans-actions whereas in the forward validation (FV) scheme, transactions are validated againstother concurrent executing transactions. Most of the real-time OCC protocols employthe forward validation scheme (OCC-FV) (Haritsa, 1990a, 1990b, 1992; Huang, 1991;Lam, 1995; Lee, 1993a) as it provides greater flexibility of choosing either the validatingtransaction or the conflicting active transactions to restart according to the adopted conflictresolution policies. Conflict resolution policies are normally based on transactions’ crit-icality or priorities. However, there is no way to take these factors into consideration in


the backward validation scheme, as the only candidate possible for restart is the validatingtransaction itself.

However, the OCC-FV protocol has a serious problem of unnecessary restarts (Lam,1995; Lee, 1993b) which is caused by an ineffective validation scheme. The FV schememay erroneously regard some serializable executions as non-serializable ones. A transactionthat may be able to commit is selected to restart. To explain the problem fully, the mechanismof the FV scheme is reviewed. In the FV scheme, the write set of a validating transaction ischecked against the read set of the concurrent executing transactions. LetTc be the set ofconcurrent executing transactions in their read phase andTv be the validating transactionandRS(Ti ) andW S(Ti ) be the read set and the write set of transactionTi respectively. TheFV algorithm is as follows.

Validate(Tv){for each Tc (c = 1, 2, . . . , n) do

if WS(Tv ) ∩ RS(Tc ) 6= ∅ thenrestart (Tc );

endif;enddo;}

The FV scheme preserves the serializability of transactions (Bernstein, 1987) under theassumption that the serialization order of transactions is determined by their commitmentorder (Harder, 1984). It implies that the serialization order of the validating transactionalways precedes all other concurrent executing transactions. That is, all conflicting transac-tions of the validating transaction have to be restarted under the FV scheme. This simplifiedassumption leads to the problem of unnecessary restart.

The following example illustrates the problem. Assume that there are three transactions.

T1 : r1[x]w1[x]w1[z]

T2 : r2[x]w2[y]w2[z]

T3 : r3[x]r3[y]w3[z]

whereri [x] andwi [x] represent a read and a write operation respectively on data objectxby transactionTi . Letvi andci be the validation and the commit operation of transactionTi

respectively. Suppose the partial scheduleS1, whenT1 comes to validation, is as follows.

S1 : r1[x]w1[x]r2[x]r3[x]r3[y]w3[z]w1[z]v1c1

Based on the OCC-FV protocol, at the validation phase ofT1, T2 andT3 have to be restarted.It is becauseT1 has write-read conflict on data objectx with T2 and has write-read and write-write conflicts on data objectsx andz respectively withT3. However, the restarts ofT2 andT3 are unnecessary ifT2 andT3 are allowed to continue and enter their validation phase asshown in the scheduleS2.

S2 : r1[x]w1[x]r2[x]r3[x]r3[y]w3[z]w1[z]v1c1w2[y]w2[z]v2c2v3c3

Although the commitment order ofS2 is T1→ T2→ T3, the serializability of the transac-tions can still be preserved such thatS2 is equivalent to a serial schedule with the serialization


order ofT3 → T2 → T1. That is, it is unnecessary to enforce that the serialization orderis identical to the commitment order. We refer to the restarts ofT2 andT3 under the FVscheme asunnecessary restartswhen a serialization order whereT2 andT3 are not requiredto restart exists. Note thatT2 andT3 will be restarted under the OCC-TI protocol becauseit is unable to handle the write-write conflicts between transactions.

2.3. Dynamic Adjustment of Serialization Order with Thomas’ Write Rule

In this section, we will discuss how the serialization order of transactions can be dynamicallyadjusted to resolve their data conflicts so that the unnecessary restart problem can be avoided.In the validation of a transactionTv, there are three possible types of conflicts betweenTv and the concurrent executing transactionsTc which have not entered the validationphase. They are the write-read conflicts(W S(Tv)∩ RS(Tc) 6= ∅), the write-write conflicts(W S(Tv) ∩ W S(Tc) 6= ∅) and the read-write conflicts(RS(Tv) ∩ W S(Tc) 6= ∅). Theread-write conflicts may be resolved by adjusting the serialization order betweenTv andTc

asTv → Tc. This is calledforward adjustment. The write-read conflicts may be resolvedby adjusting the serialization order betweenTv andTc asTc→ Tv. This is calledbackwardadjustmentsuch that the read ofTc precedes the write ofTv in the serialization order. Thisis possible because the value of the data object read byTc is not affected by the write ofTv. Thus,Tc’s read has not yet been invalidated by the write ofTv. Finally, the write-writeconflicts may be resolved by either forward adjustment (Tv → Tc) or backward adjustment(Tc→ Tv). For forward adjustment,Tv ’s write does not overwriteTc’s write. For backwardadjustment, it is possible whenTc’s write can be ignored by applying Thomas’ write rule(Bernstein, 1987).

If Tc has to be both backward and forward adjusted with respect toTv, it means that ithas serious conflict withTv as it is impossible to adjustTc in the serialization order withrespect toTv. Hence, the schedule has become a non-serializable execution. One of themhas to be restarted depending on the adopted conflict resolution policy. It is obvious thatthose concurrent executing transactions which need only either backward adjustment orforward adjustment are allowed to continue as they do not have serious conflict with thevalidating transaction yet. Hence, it is easily observed that if the serialization order can bedynamically adjusted, the number of restarts can be substantially reduced.

Note that the OCC-FV protocol only considers the forward adjustment to resolve dataconflicts and ignores the backward adjustment. Thus, transactions, which only have read-write conflicts with the validating transaction, are unnecessarily restarted by the OCC-FVprotocol. For the OCC-TI protocol, the write-write conflicts are resolved with only forwardadjustment, i.e.Tv → Tc. The possibility of using backward adjustment by applyingThomas’ write rule is ignored. Reconsider the scheduleS2 repeating below as an example:

S2 : r1[x]w1[x]r2[x]r3[x]r3[y]w3[z]w1[z]v1c1w2[y]w2[z]v2c2v3c3

In spite of DASO in the OCC-TI protocol, there are two instances where transactions arerestarted unnecessarily in this example. At the validation phase ofT1, the serialization orderof T2 andT3 are both backward adjusted beforeT1 becauseT1 has write-read conflict on data


objectx with T2 andT3. Under the OCC-TI protocol,T3 will also need forward adjustmentafterT1 for the write-write conflict on data objectz. Therefore, the OCC-TI protocol willconsiderT3 having serious conflicts withT1 becauseT3 needs both forward and backwardadjustments. Hence,T3 will be restarted. Subsequently,T2 will also be restarted when itpre-writes the data objectz in its read phase.

In fact, the restarts ofT2 andT3 under the OCC-TI protocol are unnecessary. AlthoughT3 has write-write conflict on data objectz with T1, the serialization order ofT3 can bebackward adjusted beforeT1 becauseT3’s write on data objectzcan be ignored by applyingThomas’ write rule. By Thomas’ write rule, the two consecutive writes ofT3 andT1 inthe serialization order,T3 → T1, produces the same result on data objectz as processingthe single write ofT1 which is the last write on the data object. At the validation phaseof T2, the serialization order ofT3 is further backward adjusted beforeT2 becauseT2 haswrite-read conflict on data objecty with T3. Likewise, the write ofT2 andT3 on data objectz can both be ignored by Thomas’s write rule. Hence,T2 andT3 can both be committed.Therefore, the final serialization order becomesT3 → T2 → T1. Therefore, the inclusionof Thomas’ write rule in resolving write-write conflicts adds extra flexibility in adjustingthe serialization order of transactions.

2.4. Design Issues of Validation Scheme

For OCC protocols in centralized database systems, the validation phase and the write phaseare implemented in a system-wide critical section (Harder, 1984; Kung, 1981). That is, thereis no parallelism in the validation phase and in the write phase. This decreases the amountof concurrency. If this processing strategy is simply extended to distributed environments,all sites must be checked though the transaction may not have been executed at some ofthese sites. This incurs high communication overheads. The validation phase and the writephase are the integral part of the critical section. After validation, local sub-transactionswill have to wait within their local critical sections until they get commit messages to enterthe write phase from their parent transaction. This, in turn, may lead to a situation wherea group of sub-transactions may get involved in a validation deadlock where each memberof the sub-transactions wait indefinitely to enter its local critical section which is beingvisited by some other sub-transaction. This validation deadlock is mainly caused by therequirement of a sub-transaction waiting inside a critical section. The validation deadlockcan be avoided if the write phase can be disintegrated from the validation phase by pullingit out of the critical section. However, this disintegration introduces another problem wherethe global serializability of transaction execution cannot be guaranteed even if a transactiongets local validation at all participating sites.

Instead of using a system-wide critical section in distributed environments, we proposea locking mechanism to implement the validation scheme. It is well known that the majorproblem of using locking approach is deadlock that is caused by the blocking nature of thelocks. Deadlock is very difficult to detect especially in distributed environments. The highoverhead of the distributed deadlock detection and the subsequent deadlock resolution de-crease the probability of transactions meeting their deadlines in distributed RTDBS. Hence,it is desirable to have a deadlock-free validation scheme. Since the data objects accessed


Table 1.Compatibility lock table.

PR-lock held PW-lock held VR-lock held VW-lock held

PR-lock OK OK NOTOK NOT OKrequestedPW-lock OK OK NOTOK NOT OKrequestedVR-lock OK OK NOT OK NOT OKrequestedVW-lock OK OK NOT OK NOT OKrequested

by a transaction are already known in the validation phase, the validating transaction canrequest validation locks in a circular and unidirectional fashion. In this way, deadlockcan be avoided as there will be no two validating transactions mutually waiting for eachother.

Another issue of designing a validation scheme is the efficiency. In the validation phase,the DASO scheme can be made possible only when the current read/write sets of otherconcurrent executing transactions at all sites are known. It is very difficult and incurstoo many overheads to maintain globally the read/write sets of all concurrent-executingtransactions at all sites. One intuitive approach is that all sub-transactions have to informthe parent transaction of their read/write sets of their conflicting sub-transactions and theparent transaction will centrally adjust the relative serialization order of the conflictingtransactions. However, this centralized approach is inefficient as it introduces potentialperformance bottleneck at the parent transaction as well as risk of single point failure.

2.5. Distributed Circular Validation Scheme

We now describe another core component of the DOCC-DA protocol, a new distributedvalidation scheme using locking approach and circular validation. Four types of locks areutilized in the validation scheme. The PR-lock or PW-lock has to be obtained when a dataobject is read or written respectively by a transaction into its own workspace in its readphase. Since the PR-lock and PW-lock mainly serve as an indicator to inform the system thatthe data objects are accessed by the executing transactions, they are compatible with eachother. When a transaction enters the validation phase after it has obtained all the requestedPR-locks and PW-locks, these locks will be upgraded to the VR-locks and VW-locks one byone respectively. The function of the VR-lock and VW-lock is to prevent other transactionsfrom accessing the data object. Thus, the VR-lock and VW-lock are incompatible witheach other and with the PR-lock and PW-lock. If the requested validation lock (VR-lockor VW-lock) is denied, the validating transaction will be blocked until the data object isunlocked by other transaction. To avoid the problem of deadlock due to the exclusivenature of the two “blocking” locks (VR-lock and VW-lock), they are obtained in a circularand unidirectional fashion. If the blocking direction is unidirectional, deadlock cannot beformed. The compatibility of these locks is shown in Table 1.


In our new validation scheme, we assume that there is a monotonic increasing indexassociated with each data object in the whole database. When a transaction enters thevalidation phase, it triggers the sub-transaction that P-locked the data object with the lowestindex to start its local validation first. Each sub-transaction performs its local validationone by one in a circular and unidirectional fashion. The sub-transaction will use its localserialization order timestamp (SOT) to check the validity of the data objects read or pre-written by it. If all are valid, the sub-transaction will upgrade the PR-locks and PW-locksto the VR-locks and VW-locks one by one. If any transaction has data conflict with it, atoken containing the type of adjustment and the information of the conflicting transactionis created for each conflicting transaction. The token contains the following information:

CTID : the transaction ID of the conflicting transaction;FOR : a flag indicating that the conflicting transaction needs forward adjustment

if it has write-read or write-write conflict with the validating transaction;BACK : aflag indicating that the conflicting transaction needs backward adjustment

if it has read-write conflict with the validating transaction.

Afterwards, the set of tokens contained in a single validation packet are passed to the vali-dating sub-transaction at the next site downstream together with a packet header containingthe validating transaction ID (VTID) and itsSOT.

Upon receipt of the validation packet, the validating sub-transaction will check the validityof the data objects read or pre-written by it in a similar way as its precedent sub-transaction.However, it will use either its localSOTor theSOTin the validation packet header dependingon which one is earlier. If all the accessed local data objects are checked valid, the sub-transaction will identify the conflicting transactions. Note that if the token for a conflictingtransaction already exists, only the FOR or BACK flag is updated. Otherwise, a new tokenwill be created for the conflicting transaction. Then, the validation packet containing a newset of tokens is passed to the validating sub-transaction at the next site downstream. Thiscircular validation will continue site by site until all the data objects are V-locked. Thevalidation packet is returned back to the parent transaction.

Once the validation packet returned to the parent transaction, it determines which con-flicting transactions have serious data conflict with it. A serious conflict occurs when boththe FOR and BACK flags are set. It will also identify those transactions that need back-ward adjustment only. Then, the parent transaction will send this information to all itssub-transactions together with the commit message. Upon receipt of the commit messages,all the sub-transactions will enter the write phase. Note that our new validation scheme canbe easily integrated into the standard two-phase commit protocol. The circular validationcan be considered as the voting phase while the write phase can be considered as the commitphase.

We demonstrate that a deadlock cannot occur in the circular validation scheme. Adeadlock is formed when there exists a circular wait among the validating transactions.Thus, we need to demonstrate that there cannot be a circular wait. The validating trans-actions are required to upgrade their locks in a circular and unidirectional fashion. Let


D = {D1, D2, . . . , Dn} be the set of data objects in the database that is partitioned in dif-ferent sites. The index of a data objectDi , Index(Di ), determines the unidirectional orderin which a validating transaction obtains its validation locks. In other words, a validatingtransaction upgrades its locks in an increasing order of the indices of data objects.

We prove that there cannot be a circular wait by assuming that a circular wait exists (proofby contradiction). Let the set of transactions involved in the circular wait be{T0→ T1→T2→ · · · → Tn→ T0}, whereTi is waiting for upgrading a lock on data itemDi , which isbeing V-locked by transactionTi+1. Then since transactionTi+1 is holding a V-lock onDi

while it is requesting a V-lock on data itemDi+1, we must have Index(Di ) < Index(Di+1)

for all i . But this condition means that Index(D0) < Index(D1) < Index(D2) < · · · <Index(Dn) < Index(D0). By transitivity, Index(D0) < Index(D0), is impossible. There-fore, there can be no circular wait.

3. The DOCC-DA Protocol

In this section, we describe the detailed algorithm of the DOCC-DA protocol. In the DOCC-DA protocol, serialization order is maintained by assigning timestamps to transactions.The timestamp of each transaction, called the serialization order timestamp (SOT), willbe dynamically adjusted during its execution based on the types of data conflicts with thevalidating transaction. Thus, theSOTof a transaction indicates its relative position in theserialization order. Note that with DASO, a validating transaction may precede committedtransactions in the serialization order. Thus, the serialization order timestamp sequence,with respect to a scheduleS, for a set of transactions is a sequence of timestamps such thatfor any pair of transactionsTi andTj , if SOT(Ti ) andSOT(Tj ) are the serialization ordertimestamps ofTi andTj respectively, then the following holds: ifSOT(Ti ) < SOT(Tj ) thereexists a serial schedule equivalent toS, in whichTi completes beforeTj .

Each sub-transaction of a transactionTi will also carry its ownSOT(Ti ) at its local site toperform its local validation. The initial value ofSOT(Ti ) at each site is set to be∞ whenthe sub-transaction is initiated. Whenever a committed transactionTk backward adjustsTi at a local site,SOT(Ti ) at that site will be set to a value that is sufficiently smallerthanSOT(Tk). It is desirable that each sub-transaction should carry the sameSOTvalue toindicate the position ofTi in the serialization order. However, in the DOCC-DA protocol, theserialization order of a transaction can be determined at the end of transaction execution.Therefore, theSOT(Ti ) at each site can be of different values. In other words, a localSOT(Ti ) indicates only the relative serialization order of the sub-transaction at that site.WhenTi starts its validation, each sub-transaction may use its localSOT(Ti ) or theSOT(Ti )received from the validating sub-transaction at the upstream site depending on which one isearlier. In this way, this deferment design can significantly reduce the amount of messagepassing in the course of transaction execution in order to synchronize theSOT(Ti ) value ateach site.

Upon successfully passing the circular validation scheme, the validating transactionTi

is assigned a final serialization timestamp. IfTi has not been backward adjusted, its finalserialization timestamp will be set to the validation time. Otherwise, the final serializationtimestamp is set to the value of theSOT(Ti ) returned to the parent transaction.


In each site, a data object table and a transaction table are maintained. The data objecttable keeps a read timestamp and a write timestamp for each data object in the local database.They are defined as follows:

RTS(Dx) : the latest timestamp among the committed transactions that have read

the data objectDx;WTS(Dx) : the latest timestamp among the committed transactions that have written

the data objectDx.

The transaction table at each site maintains the following information for each local activetransaction or sub-transactionTi :

RS(Ti ) : the read set ofTi ;WS(Ti ) : the write set ofTi ;

SOT(Ti ) : the serialization order timestamp ofTi ;TR(Ti , Dx) : the value ofWTS(Dx) of the data objectDxwhenTi readsDx;

3.1. Read Phase

When a sub-transaction ofTi wants to read or pre-write a data objectDx in its privateworkspace, it will first obtain the PR-lock or PW-lock respectively. These locks will begranted if there is no VR-lock or VW-lock. In the read phase, there is no need forTi to detectdata conflicts. However, the write timestamp of each data object read will be recorded. Thatis, if Ti wants to readDx, the value ofWTS(Dx) will be recorded intoTR(Ti , Dx). If Ti

wants to writeDx, the new value ofDx will be pre-written into its private workspace.

3.2. Validation Phase

When a sub-transaction ofTi receives a validation packet, it will update itsSOT(Ti ) if thereceivedSOT(Ti ) is earlier. Afterwards,Ti will upgrade its local PR-locks and PW-locksto the VR-locks and VW-locks respectively one by one. If there is a VR-lock or VW-lockbeing held by another transaction,Ti will be blocked until the lock is released.

To upgrade the PR-lock to the VR-lock onDx, Ti will check the value ofTR(Ti , Dx)to ensure that the version ofDx read byTi is the one written by a committed transactionwhose serialization order precedes that ofTi , i.e. TR(Ti , Dx) is earlier thanSOT(Ti ). IfTR(Ti , Dx) is later thanSOT(Ti ), Ti will send “Abort” message to the parent transaction thatwill globally abort the whole transaction because a committed transaction has invalidatedthe value ofDx thatTi has read. Otherwise, the VR-lock will be granted. If there is a PW-lock held by another transaction,Ti will either create or update the token for the conflictingtransaction and set the FOR flag in the token.

To upgrade the PW-lock to VW-lock onDx, if the RTS(Dx) is later thanSOT(Ti ), Ti willsend “Abort” message to the parent transaction. It is because a committed transaction after


Ti in the serialization order has readDx beforeTi wants to writeDx. Since the conflictingtransaction has committed, the only way to resolve the data conflict is to abortTi . If SOT(Ti )is later thenRTS(Dx), the PW-lock is upgraded to the VW-lock. If there is a PR-lock,Ti

will update the token for the conflicting transaction accordingly. However, if there is aPW-lock,Ti does not need to do anything because write-write conflicts will be handled inthe write phase. The UpgradePR-lock and UpgradePW-lock procedural descriptions areas follows:

Upgrade PR-lock(Ti ,Dx ){if VR-lock (Dx ) or VW-lock (Dx ) exists then

block T i ;endif;if TR(Ti ,Dx ) > SOT(Ti ) then

send ‘‘Abort’’ message to the parent transaction ;else

upgrade PR-lock(D x ) to VR-lock(D x ) ;if ∃PW-lock(D x ) held by T k ∧ k 6= i then

if a token for T k does not exist thencreate a token for T k ;

endifset FOR flag ;

endifendif}

Upgrade PW-lock(T i ,Dx ) {if VR-lock(D x ) or VW-lock(D x ) exists then

block T i ;endif;if RTS(Dx ) > SOT(Ti ) then

send ‘‘Abort’’ message to the parent transaction ;else

upgrade PW-lock(D x ) to VW-lock(D x ) ;if ∃PR-lock(D x ) held by T k ∧ k 6= i then

if a token for T k does not exist thencreate a token for T k ;

endifset BACK flag ;

endif;endif; }

Table 2 describes how a validating transaction sets the flags for the conflicting transactions.When the sub-transaction successfully upgrades all its local PR-locks and PW-locks, it

will pass the validation packet containing the set of tokens to the validating sub-transactionat next site downstream and waits for the response from the parent transaction about thefinal decision.


Table 2. Setting of forward and back-ward flags in a token.

Locks already held byTk

Update PR-lock PW-lockLock TypePR→ VR no flag set set FORPW→ VW set Back no flag set

3.3. The Role of Parent Transaction

The parent transaction has two roles. One is to coordinate the synchronization of thevalidation and write phases. The other is to perform a global conflict resolution based onthe adopted conflict resolution policy. That is, when the validation phase is completed, thetransaction has to determine whether to commit or to abort in face of having data conflictswith high priority transactions. It appears undesirable in the context of priority-drivenscheduling to allow the occurrences of low priority validating transactions unilaterallycommitting at the cost of restarting higher priority transactions.

Studies in (Haritsa, 1990, 1992) addressed the problem of adding transaction priorityinformation in conflict resolution. They showed that the problem is nontrivial partly becausegiving preferential treatment to high priority transactions may result in an increase in thenumber of missed deadlines. They proposed a class of priority wait schemes, particularlyWait-50 (Haritsa, 1992), to enhance the real-time performance of the OCC-FV protocol.The basic idea of Wait-50 is to optimize the beneficial effects of priority wait while reducingthe effects of later restarts and an increased number of conflicts.

However, recent study (Datta, 1997) showed that there appears to be little advantage to begained by incorporating priority cognizance in the conflict resolution of the OCC protocolsin RTDBS. They revealed that real-time performance might be improved provided that theconflict set of a validating transaction is reasonably large. However, their simulation resultsshowed that the number of higher priority transactions that conflict with the validatingtransaction is relatively small even under the condition of high data contention.

In addition, restart of a validating transaction may have two performance implications.First, the validating transaction is restarted after spending most of the time and resourcesfor its execution. In particular, the delayed conflict resolution policy of the OCC protocolssignificantly reduces the possibility that a validating transaction sacrificed for a higherpriority active transaction will meet its deadline. Second, there is no guarantee that theactive transaction that causes the restart of the validating transaction will meet its deadline.If the active transaction does not meet its deadline for any reason, the sacrifice of thevalidating transaction is wasted.

Most of the conflict resolution policies require a system snapshot so that the number of lowand high priority transactions can be determined. It would be impracticable in distributedenvironments as it means that all sites have to be involved in reaching this decision. Hence,in order to focus our attention on the performance of our DOCC-DA protocol, a simpleconflict resolution policy is adopted in our study. Data conflicts are resolved by “transaction


races”: the transaction which reaches the “goal line” (validation phase) first gets to surviveand other conflicting transactions have to be restarted or backward adjusted. Thus, theparent transaction will identify those conflicting transactions that needed to be restartedand those conflicting transactions that needed to be backward adjusted. To enter the writephase, the parent transaction will send a “Commit” message to its sub-transactions togetherwith the following two sets of conflicting transactions.

BTRAN : the set of transactions to be backward adjusted;SERIOUS : the set of serious conflicting transactions to be restarted;

The algorithm of the conflict resolution is as follows.

Conflict resolution (T i ) {BTRAN := {}; SERIOUS := {};for each token do

if both FOR and BACK flags are set thenSERIOUS := SERIOUS ∪ {CTID};

elsif only BACK flag is set thenBTRAN := BTRAN∪ {CTID};

endif;enddo;if (SOT(Ti ) ==∝) then //** SOT (Ti ) received back **//

SOT(Ti ) := current time ;endif;Send ‘‘Commit’’ message with SERIOUS, BTRAN and SOT (Ti )to sub-transactions ;}

3.4. Write Phase

For each sub-transaction, if a “Commit” message is received,Ti will abort those seriousconflicting transactions in the SERIOUS set. For those transactions in BTRAN set, theirSOTvalues are updated toSOT(Ti )− ε whereε is a sufficiently small value. ThenTi willupdate the values ofRTS(Dx) andWTS(Dx) to the receivedSOT(Ti ) value onDx held byits VR-lock or VW-lock. Finally, the prewritten data objects will be made permanent inthe database following Thomas’ write rule. Finally, all its VR-locks and VW-locks will bereleased. On the other hand, if “Abort” message is received, all its locks are released and allprewritten data objects are disregarded. The algorithm for each sub-transaction to performthe write phase is as follows:

Write phase (T i ) {if Commit message is received then

FWS(Ti ) := {};for each T k in SERIOUS do

restart T k ;enddo


for each T k in BTRAN doSOT(Tk ) := SOT(Ti )− ε;//** ε is a sufficiently small value **//

enddo;for each Dx in RS (Ti ) do

if RTS(Dx ) < SOT(Ti ) thenRTS(Dx ) := SOT(Ti );

endif;enddo;for each Dx in WS(Ti ) do

if WTS(Dx ) < SOT(Ti ) thenWTS(Dx ) := SOT(Ti );FWS(Ti ) := FWS(Ti ) ∪ Dx

endif;enddo;//** Thomas’ write rule applied **//copy the local prewritten data objects in FWS (Ti ) tothe database ;

else//** Abort message is received **//discard the local prewritten data objects;restart T i itself ;

endif;release all its locks ;}

4. Experimental Model

The distributed RTDBS model consists of a set of inter-connected sites and the database ispartitioned in different sites with the data objects in each site forming its local database. Eachsite is connected to a local communication interface that in turn is connected to other sitesthrough the communication network that is modeled as a constant delay server. In each site asshown in Figure 1, there is a transaction generator, a ready queue, a block queue, a scheduler,a CPU, a local database, and a communication interface. The transaction generator createsfirm real-time transactions with inter-arrival time following exponential distribution. Thecreation of a transaction in a site is independent of the creation of transactions in other sites.Each transaction is modeled as a sequence of read/write operations on data objects thatare evenly distributed among different sites. The processing of an operation involves useof the CPU and access to data object. Upon arrival, transactions are queued in the readyqueue for the CPU. The queuing discipline is earliest deadline first (EDF). In each site,there is a scheduler. If the deadline of the transaction at the head of the ready queue ismissed, the scheduler will abort the transaction. Otherwise, the scheduler assigns the CPUto the transaction. When the transaction’s data request is denied, the scheduler will placethe transaction into the block queue until the requested data object is available.


Figure 1. Model of a site in a distributed RTDBS.

4.1. Model Parameters

Table 3 summarizes the baseline setting of the model to be used in the simulation exper-iments. The purposes of the simulation experiments are to evaluate the characteristicsof the proposed protocol and to demonstrate the capabilities of the proposed protocol inimproving the performance of distributed RTDBS. The values of the baseline setting arebased on those used in other related research studies (Lam, 1997; Ulusoy, 1992). However,the simulation experiments are not confined to the baseline setting. In addition to the meantransaction arrival rate, the impact of write probability and the amount of slack time arealso studied by varying their values from the baseline setting.

To assign a deadline to each transaction, the following function applies.

Deadline= Tgen+ Texe× (1+ SF)

The value ofSF is uniformly selected from the range in Table 3.Tgen is the current timewhen the transaction is generated.Texe is the estimated execution time that is a function ofthe parameters,Tprocess, Noper, andTcomm.

Table 3.The baseline setting.

Number of sites 4Database size 200 data objects/siteMean transaction arrival rate 0.4–2.8 transactions/secTransaction size(Noper) 3–20(number of operations) (uniformly distributed)Write proabability 0.0–1.0Communication delay(Tcomm) 100 msCPU time to process a data object (Tprocess) 34 msCPU time to update a data object (Tupdate) 6 msSlack factor (SF) 2.5–13.75


4.2. Performance Measures

In distributed RTDBS, the major performance measure is the “miss rate” which indicatesthe probability of missing deadlines of transactions.

Miss Rate= Nmissed/(Ncommitted+ Nmissed)× 100%

where

Nmissed = number of transaction missing its deadline;Ncommitted = number of transaction committed.

The other two measures, which help to study the performance of the DOCC-DA protocol,are the “restart ratio” and the “backtrack ratio”. The restart ratio gives the number ofrestarts per transaction completed. The backtrack ratio gives the number of adjustment ofserialization order made per transaction completed. Since a restarted transaction may meetits deadline, miss rate cannot provide direct effect of the DOCC-DA protocol. Therefore,the restart ratio can help to measure the actual change in the number of restarts brought bythe protocol. The backtrack ratio, on the other hand, helps to reflect the effectiveness of theprotocol by collecting the frequency of adjustment made.

5. Performance Results

We have performed a series of experiments comparing the performance of the DOCC-DA protocol with that of the two-phase locking-high priority (2PL-HP) and the OCC-FVprotocol in distributed environments. Although the OCC-FV protocol is not originallydesigned for RTDBS, recent study (Datta, 1997) showed that the OCC-FV protocol withEDF scheduling can be better than the priority cognizant real-time protocols. To our bestknowledge, we do not aware of other distributed OCC protocols for real-time domain in thecurrent literature. Therefore, we have adapted the OCC-FV protocol in distributed environ-ments for comparison. The validation of the OCC-FV protocol in distributed environmentsis implemented using the distributed circular validation scheme. On the other hand, thereare a number of locking-based concurrency control protocols in distributed real-time en-vironments. These protocols are based on 2PL with variation on conflict resolution suchas high priority, conditional restart (Abbott, 1988), priority inheritance and priority ceiling(Sha, 1988). 2PL-HP and OCC-FV are chosen because they represent concurrency controlprotocols for RTDBS based on locking and optimistic concurrency control, respectively, inthe previous studies (Abbott, 1988; Haritsa, 1990a, 1990b, 1992; Huang, 1991; Lee, 1993a).All these experiments show that the DOCC-DA protocol outperforms both protocols for awide range of different parameters.

5.1. Impact of System Workload

Figure 2 shows the miss rates of the three protocols as a function of mean transaction arrivalrate (MTAR) in transactions per second (tps). In this experiment, the write probability is


Figure 2. Transaction miss rates.

fixed at 0.6. The MTAR controls the workload of the system. When the MTAR is low(< 1.2 tps), there is no significant difference between the three protocols. However, as theMTAR increases, the DOCC-DA protocol outperforms the DOCC-FV protocol, which inturn outperforms the 2PL-HP protocol.

The reason for the better performance of both DOCC protocols over the 2PL-HP protocolis due to the lower restart ratios as shown in Figure 3. The DOCC protocols incur much fewertransaction restarts and hence make better use of resources than the 2PL-HP protocol, whichsuffers from wasted transaction restarts. Transaction restarts in distributed environments canmake a transaction more difficult to meet its deadline as the time spent on communicationdelays before restarts will be wasted. On the other hand, the delayed conflict resolutionpolicy of the DOCC protocols helps them to avoid such wasted restarts. Note that therestart ratio decreases after a certain MTAR. The reason is that resource contention becomesto dominate data contention, making more transactions miss their deadlines without anyrestart. In fact, some recent studies (Haritsa, 1990a, 1992; Lee, 1996) showed that OCCprotocols outperform 2PL protocols over a wide range of system workload and resourceavailability in RTDBS. The results in our study showed that this is also true in distributedenvironments.

We now focus on the comparison between the performance of the DOCC-FV and theDOCC-DA protocols under different parameter settings. Figure 4 shows the miss rates


Figure 3. Transaction restart ratios.

of the DOCC-FV and the DOCC-DA protocols as a function of MTAR at different writeprobabilities. When the workload is light, the miss rates under both protocols are lowand close to each other. As the workload increases, the performance of the DOCC-DAprotocol starts to outperform the DOCC-FV protocol. The maximum performance gain isattained when the MTAR is around 2tps. When the system begins to saturate (> 2.4 tps),the performance gain diminishes gradually. Nevertheless, the performance of the DOCC-DA protocol is consistently better than that of the DOCC-FV protocol across differentMTAR.

In the figure, it can also be observed that the miss rate of both protocols increases withthe write probability. When the write probability is 0, all transaction operations are readoperations. In the other end, all transaction operations are write operations. As the writeprobability increases, there are more data conflicts and most of them are serious conflictsthat cannot be resolved by DASO. However, the DOCC-DA protocol still performs betteracross different write probabilities. In particular, the performance gain is the largest whenthe write probability is 0.2, that is, when the read operation is the majority.

One of reasons for this performance difference is the difference in the number of transac-tion restarts, as indicated by restart ratio, incurred by the two protocols, shown in Figure 5.The DOCC-FV protocol suffers performance degradation caused by restart overheads. Thecurves show that the DOCC-DA protocol can avoid a number of unnecessary restarts. Again,


Figure 4. Transaction miss rates with different workload.

note that the restart ratio increases as the workload increases in the beginning where morerestarts are incurred due to increasing data conflicts. When the workload further increases,the restart ratio decreases. In this case, resource contention dominates data contention, mak-ing more transactions miss their deadlines without any restart. Therefore, the restart ratiodecreases because many transactions are aborted and discarded due to deadline missing. Inthe figure, it can also be observed that the restart ratio increases with the write probabilityfor both protocols because high write probability means more conflicts, in particular, theserious conflicts.

The performance gain brought by the DOCC-DA protocol is mainly due to the backwardadjustment of the conflicting transactions with respect to a validating transaction in theserialization order. Figure 6 shows the backtrack ratios at different MTAR and write prob-abilities. Similar interpretation can be used to explain the difference in backtrack ratiosat different MTAR. However, there is one point to note. Given a certain workload, as thewrite probability increases, the backtrack ratio increases to a certain peak value and dropsthereafter until it becomes zero again when the write probability is 1. Similar phenomenoncan also be found in Figure 7.


Figure 5. Transaction restart ratios with different workload.

5.2. Different Proportion of Read/Write Operations

Figure 7 shows the miss rate as the write probability varies. It can be observed that thereis no performance difference between the protocols at both ends of the write probability.Same behavior can be observed for different workloads. When all operations are readoperations, no data conflict occurs. Therefore, no DASO is made as shown in Figure 6.On the other hand, when all operations are write operations, all data conflicts are seriousconflicts. Therefore, it is impossible to adjust the serialization order among transactions asshown in Figure 6.

5.3. Impact of Slack

Figure 8 shows the miss rate when the slack varies. When the slack is tight, transactions aremore sensitive to the resource contention and it is more likely for them to miss their deadlines.Therefore, a higher miss rate is resulted when the slack is tight. Furthermore, there maynot be sufficient remaining slack for a transaction to be restarted. In this case, reduction intransaction restarts becomes very important. One reason is to save resource from spendingon restarted transactions. Another reason is to avoid transactions to be restarted. Therefore,


Figure 6. Transaction adjustment ratios with different workload.

the performance gain brought by the DOCC-DA protocol becomes more significant whenthe slack is tight. On the other hand, if the slack is not tight (baseline), a transaction may stillbe able to meet its deadline although it has been restarted. For instance, when the MTAR isunder 1.2 tps, the miss rate under both protocols is insignificant when the slack is not tight.However, when the slack is tight, the performance gain brought by the DOCC-DA protocolis more than one third.

6. Conclusions

In this paper, we studied the performance of using optimistic approach to concurrency con-trol in distributed real-time environments. The traditional optimistic approach suffers fromthe problem of unnecessary restarts. This problem affects the performance of RTDBS astransaction restarts can significantly increase the system workload and intensify resourceand data contention. In distributed environments, the complexity of the system and the highcommunication overhead exacerbate the problem. Transaction restarts in distributed RT-DBS make a transaction more difficult to meet its deadline than in a centralized one becauseof the communication overhead. Therefore, the number of unnecessary restarts is the de-terminant factor that affects the performance of optimistic approach in distributed RTDBS.


Figure 7. Transaction miss rates with different write probabilities.

In this study, a new real-time DOCC protocol, called DOCC-DA, is proposed. Theprotocol alleviates the problem of unnecessary restart by dynamic adjustment of serializationorders of the concurrent executing conflicting transactions with respect to a validatingtransaction. Under the DOCC-DA protocol, only those transactions with serious conflictwith the validating transaction will be restarted. In addition, the design of the DOCC-DAprotocol is suitable to distributed environments in the sense that it reduces the numberof message passings between different sites by using a new distributed circular validationscheme.

A series of simulation experiments have been done to investigate the performance of theDOCC-DA protocol as compared to the 2PL-HP protocol and the DOCC-FV protocol. It isfound that the DOCC-DA protocol out-performs the 2PL-HP protocol and the DOCC-FVprotocol for a wide range of workload parameters by reducing the number of transactionrestarts. Another improvement can be observed in the reduction of miss rate that is alsoimportant to the performance of the system. It is also observed that the DOCC-DA pro-tocol gives a greater performance gain when transactions have a large proportion of readoperations. The performance gain is manifested by the use of DASO, which exploits thesemantics of read-write and write-write operations of transactions.


Figure 8. Transaction miss rates with different slacks.

References

Abbott, R., and Garcia-Molina, H. 1988. Scheduling real-time transactions: A performance evaluation.Proceed-ings of the 14th VLDB Conference. Los Angeles, pp. 1–12.

Abbott, R., and Garcia-Molina, H. 1992. Scheduling real-time transactions: A performance evaluation.ACMTransactions on Database Systems17(3): 513–560.

Bernstein, P. A., Hadzilacos, V., and Goodman, N. 1987.Concurrency Control and Recovery in Database Systems.Mass: Addison-Wesley.

Datta, A., Viguier, I. R., Son, S. H., and Kumar, V. 1997. A study of priority cognizance in conflict resolution forfirm real time database systems.Real-Time Database and Information Systems, Research Advances. Boston.Kluwer Academic Publishers.

Haerder, T. 1984. Observations on optimistic concurrency control schemes.Information Systems9(2).Haritsa, J. R., Carey, M. J., and Livny, M. 1990a. Dynamic real-time optimistic concurrency control.Proceedings

of 11th Real-time Systems Symposium. Florida, pp. 94–103.Haritsa, J. R., Carey, M. J., and Livny, M. 1990b. On being optimistic about real-time constraints.Proc. of the

ACM SIGACT-SIGART-SIGMOD Symp. on Principles of Database Systems.Haritsa, J. R., Carey, M. J., and Livny, M. 1992. Data access scheduling in firm real-time database systems.

Real-time Systems4(3): 203–242.Huang, J., Stankovic, J. A., Towsley, D., and Ramamritham, K. 1991. Experimental evaluation of real-time

optimistic concurrency control schemes.Proc. of the 17th VLDB Conf. Spain, pp. 35–46.Huang, J., Stankovic, J. A., Ramamritham, K., Towsley, D., and Purimetla, B. 1992. On using priority inheritance

in real-time databases.Real-time Systems4(3): 243–268.Konana, P., Lee, J., and Ram, S. 1997. Updating timestamp interval for dynamic adjustment of serialization

order in optimistic concurrency control-time interval (OCC-TI) protocol.Information Processing Letters63(4):


189–193.Kung, H. T., and Robinson, J. T. 1981. On optimistic methods for concurrency control.ACM Transactions on

Database Systems6(2): 213–226.Lam, K. Y. 1994. Concurrency control in distributed real-time database systems. Department of Computer

Science, City University of Hong Kong, Ph.D. Thesis.Lam, K. Y., Hung, S. L., and Son, S. H. 1997. On using real-time static locking protocols for distributed real-time

databases.Real-Time Systems13: 141–166.Lam, K. W., Lam, K. Y., and Hung, S. L. 1995. Real-time optimistic concurrency control protocol with dynamic

adjustment of serialization order.Proceedings of IEEE Symposium on Real-time Technology and Applications.pp. 174–181.

Lee, J., and Son, S. H. 1993a. An optimistic concurrency control protocol for real-time database systems.Proc.of the 3rd Int. Symp. on Database Systems for Advanced Applications. Korea.

Lee, J., and Son, S. H. 1993b. Using dynamic adjustment of serialization order for real-time database systems.Proceedings of 14th IEEE Real-time Systems Symposium. North Carolina, pp. 66–75.

Lee, J., and Son, S. H. 1996. Concurrency control algorithms for real-time database systems.Performance ofConcurrency Control Mechanisms in Centralized Database Systems. V. Kumar, ed., Prentice Hall.

Ramamritham, K. 1993. Real-time databases.International Journal of Distributed and Parallel Databases1:199–226.

Sha, L., Rajkumar, R., and Lehoczky, J. 1988. Concurrency control for distributed real-time databases.ACMSIGMOD Record. pp. 82–98.

Sha, L, Rajkumar, R., and Lehoczky, J. P. 1990. Priority inheritance protocols: An approach to real-time synchro-nization. IEEE Transactions on Computers39(9): 1175–1185.

Son, S. H., and Chang, C. 1990. Performance evaluation of real-time locking protocols using a distributed softwareprototyping environment.Proceedings of the 10th International Conference on Distributed Computing Systems.Paris, pp. 124–131.

Son. S. H., and Koloumbis, S. 1993. A token-based synchronization scheme for distributed real-time databases.Information Systems18(6): 375–389.

Ulusoy, O., and Belford, G. G. 1992. A simulation model for distributed real-time database systems.Proceedingsof 25th Annual Simulation Symposium. pp. 232–240.

Ulusoy, O. 1994. Processing real-time transactions in a replicated database system. Technical Report BU-CEIS-94-13, Bilkent University.

Yu, P. S., Wu, K. L., Lin, K. J., and Son, S. H. 1994. On real-time databases: Concurrency control and scheduling.Proceedings of the IEEE82(1): 140–157.

transaction scheduling in distributed real-time systems

Documents