**2.2 Optimistic Concurrency Control-based algorithms**

176 Real-Time Systems, Architecture, Scheduling, and Application

modular concurrency control permits an elementary transaction to hold locks across atomic data sets. This increases the duration of locking and decreases preemptibility. In this study

Priority Ceiling Protocol minimizes the duration of blocking to at most one elementary lower priority task and prevents the formation of deadlocks. The idea is that when a new higher priority transaction preempts a running transaction its priority must exceed the priorities of all preempted transactions, taking the priority inheritance protocol into consideration. If this condition cannot be met, the new transaction is suspended and the

The priority ceiling of a data object is the priority of the highest priority transaction that may lock this object [Sha, Rajkumar, Son]. A new transaction can preempt a lock-holding transaction only if its priority is higher than the priority ceilings of all the data objects locked by the lock-holding transaction. If this condition is not satisfied, the new transaction will wait and the lock-holding transaction inherits the priority of the highest transaction that it blocks. The lock-holder continues its execution, and when it releases the locks, its original priority is resumed. All blocked transactions are alerted, and the one with the highest

The fact that the priority of the new lock-requesting transaction must be higher than the priority ceiling of all the data objects that it accesses, prevents the formation of a potential deadlock. The fact that the lock-requesting transaction is blocked only at most the execution time of one lower priority transaction guarantees, the formation of blocking chains is not

The Priority Ceiling Protocol is further worked out in [Sha, Rajkumar, Son], where the Read/Write Priority Ceiling Protocol is introduced. It contains two basic ideas. The first idea is the notion of priority inheritance. The second idea is a total priority ordering of active transactions. A transaction is said to be active if it has started but not completed its execution. Thus, a transaction can execute or wait caused by preemption in the middle of its execution. Total priority ordering requires that each active transaction execute at a higher priority level than the active lower priority transaction, taking priority inheritance and

A protocol called Real-Time Locking (RTL) that uses locking and dynamic adjustment of serialization order for priority conflict resolution was proposed. The basic idea of serialization order adjustment is to delay the decision of final serialization order among transactions, and to adjust the temporary serialization order dynamically in favour of transactions with high priority. Thus, this scheme can avoid blocking and aborts resulting from a mismatch between serialization order and priority order of transactions. In order to implement the dynamic adjustment of serialization order, in RTL, the execution of a transaction is phase-wise as in OCC. In the first phase called read phase, a transaction reads from database and writes to its local workspace as in OCC. However, unlike OCC where conflicts are resolved only in the validation phase, RTL resolves conflicts in the read phase using transaction priority. In the write phase of RTL, the final serialization order is determined, and updates are made permanent to the database. The use of the phasedependent control and local workspace for transactions also provides potential for a high

blocking transaction inherits the priority of the highest transaction it blocks.

transactions do not hold locks across atomic data sets.

priority will start its execution.

possible [Sha, Rajkumar, Son].

degree of concurrency.

read/write semantics into consideration.

Optimistic Concurrency Control (OCC), is based on the assumption that conflict is rare, and that it is more efficient to allow transactions to proceed without delays to ensure serializability. When a transaction wishes to commit, a check is performed to determine whether a conflict has occurred. There are three phases to an optimistic concurrency control method:


In optimistic concurrency control, transactions are allowed to execute unhindered until they reach their commit point, at which time they are validated. Thus, the execution of a transaction consists of three phases: read, validation, and write. The key component among these is the validation phase where a transaction's destiny is decided. Validation comes in several flavours, but it can carry out basically in either of two ways: backward validation and forward validation. While in backward scheme, the validation process is done against committed transactions, in forward validation, validating of a transaction is carried out against currently running transactions.

As explained above, in RTDBSs, data conflicts should be resolved in favor of higher priority transactions. In backward validation, however, there is no way to take transaction priority into account in serialization process, since it is carried out against already committed transactions. Thus backward scheme is not applicable to real-time database systems. Forward validation provides flexibility for conflict resolution such that either the validating transaction or the conflicting active transactions may be chosen to restart, so it is preferable for real-time database systems. In addition, forward scheme generally detects and resolves data conflicts earlier than backward validation, and hence it wastes less resources and time.

All the optimistic algorithms used in the previous studies of real-time concurrency control in [Haritsa] are based on the forward validation. The broadcast mechanism in the algorithm, OPT-BC used in [Haritsa] is an implementation variant of the forward validation. We refer to the optimistic algorithm using forward validation as OCC-FV.

A point to note is that unlike 2PL-HP, OCC-FV does not use any transaction priority information in resolving data conflicts. Thus, under OCC-FV, a transaction with a higher priority may need to restart due to a committing transaction with a lower priority. Several methods to incorporate priority information into OCC-FV were proposed and studied in

Real-Time Concurrency Control Protocol Based on Accessing Temporal Data 179

In this method, every transaction in the read phase is assigned a timestamp interval (TI). This timestamp interval is used to record a temporary serialization order during the execution of the transaction. At the start of the execution, the timestamp interval of the transaction is initialized as [0, ∞], i. e., the entire range of timestamp space. Whenever the serialization order of the transaction is changed by its data operation or the validation of

OCC-DA is based on the Forward Validation scheme. The number of transaction restarts is reduced by using dynamic adjustment of the serialization order. This is supported with the use of a dynamic timestamp assignment scheme. Conflict checking is performed at the validation phase of a transaction. No adjustment of the timestamps is necessary in case of data conflicts in the read phase. In OCC-DA the serialization order of committed

A new optimistic concurrency control method, called OCC-DATI (Optimistic Concurrency Control with Dynamic Adjustment of Serialization Order using Timestamp Intervals), is proposed to reduce the number of transaction restarts in [Lindstrom], which uses information about the criticality of the transactions in the conflict resolution. The main idea behind this method is to offer better chances for critical transactions to complete according to their deadlines. This is achieved restarting transaction with lower criticality if the critical transaction should be restarted because of a data conflict. The proposed method is demonstrated to produce the correct results and the feasibility of the proposed method in

Active real-time database consists of a set of objects and ECA (Event-Condition-Action) rule. Each object represents a real world entity; the status of entity is usually monitored by

The temporal object is possible to be invalid for expired temporal validity; it can be divided into the absolute validity and the relative validity. Non-temporal object have not temporal validity. Temporal object absolute validity expresses as (value (Xi) , avi (Xi) ) , value (Xi) describes the current status of data object X, avi(Xi)=[avib(Xi), avie(Xi)], avib(Xi)≤avie(Xi) is the absolute validity of value (Xi), Xi shows the ith versions of data objects X, avib(Xi) denotes the beginning of the absolute validity of Xi , avie(Xi) denotes the end of the absolute

Temporal object relative validity denotes rvi(R), R is relatively consistent set, each element is

the version temporal data objects. When t>0, R is correct status, if and only if


sensors. The entire data object is divided into two categories in database:

other transactions, its timestamp interval is adjusted to represent the dependencies.

transactions may be different from their commit order.

**3. System model and real-time data** 

1. temporal objects and non-temporal objects

validity of Xi , after avie(Xi), value (Xi) is effective no longer.

i. Xi∈R, value(Xi) is absolute consistent, avib(Xi) ≤ t ≤ avie(Xi). ii. R is relatively consistent, Xi, Yj∈R, |avib(Xi)-avib(Yj)| ≤ rvi(R).

practice is tested.

**3.1 System model** 


[Lindstrom] using priority-driven wait or abort mechanism. However, more work is needed to ensure if these methods have any significant impact on improving OCC-FV performance, because the effect of increased waiting time or increased number of aborts in these methods may overshadow the performance gain due to the preferential treatment of transactions.

In the OPT-SACRIFICE [Haritsa] method, when a transaction reaches its validation stage, it checks for conflicts with other concurrently running transactions. If conflicts are detected and at least one of the conflicting transactions has a higher priority, then the validating transaction is restarted, i. e. sacrificed in favour of the higher priority transaction. Although this method prefers high priority transactions, it has two potential problems. First, if a higher priority transaction causes a lower priority transaction to be restarted, but fails in meeting its deadline, the restart was useless. This degrades the performance. Second, if priority fluctuations are allowed, there may be the mutual restarts problem between a pair of transactions. These two drawbacks are analogous to those in the 2PL-HP method [Lee].

When a transaction reaches its validation stage, it checks if any of the concurrently running other transactions have a higher priority. In the OPT-WAIT [Lee] case the validating transaction is made to wait, giving the higher priority transactions a chance to make their deadlines first. While a transaction is waiting, it is possible that it will be restarted due to the commit of one of the higher priority transactions. Note that the waiting transaction does not necessarily have to be restarted. Under the broadcast commit scheme a validating transaction is said to conflict with another transaction, if the intersection of the write set of the validating transaction and the read set of the conflicting transaction is not empty. This result does not imply that the intersection of the write set of the conflicting transaction and the read set of the validating transaction is not empty either [Lee].

The WAIT-50 method is an extension of the OPT-WAIT - it contains the priority wait mechanism from OPT-WAIT method and a wait control mechanism. This mechanism monitors transaction conflict states and dynamically decides when and for how long a low priority transaction should be made to wait for the higher priority transactions. In WAIT-50, a simple 50 percent rule is used - a validating transaction is made to wait while half or more of its conflict set is composed of transactions with higher priority. The aim of the wait control mechanism is to detect when the beneficial effects of waiting are outweighed by its drawbacks [Lee].

We can view OPT-BC, OPT-WAIT and WAIT-50 as being special cases of a general WAITX method, where X is the cut-off percentage of the conflict set composed of higher priority transactions. For these methods X takes the values infinite, 0 and 50 respectively.

In [Lee and Son] a lock based WAIT-50 concurrency control method, OCCL-PW, is presented. The physical implementation of this method uses locks. If the priority of the validating transaction is not highest among the conflicting transactions, the validating transaction waits if at least 50% of the conflicting transactions have higher priority.

The OCC-TI method resolves conflicts using the timestamp intervals of the transactions. Every transaction must be executed within a specific time slot. When an access conflict occurs, it is resolved using the read and write sets of the transaction together with the allocated time slot. Time slots are adjusted when a transaction commits.

In this method, every transaction in the read phase is assigned a timestamp interval (TI). This timestamp interval is used to record a temporary serialization order during the execution of the transaction. At the start of the execution, the timestamp interval of the transaction is initialized as [0, ∞], i. e., the entire range of timestamp space. Whenever the serialization order of the transaction is changed by its data operation or the validation of other transactions, its timestamp interval is adjusted to represent the dependencies.

OCC-DA is based on the Forward Validation scheme. The number of transaction restarts is reduced by using dynamic adjustment of the serialization order. This is supported with the use of a dynamic timestamp assignment scheme. Conflict checking is performed at the validation phase of a transaction. No adjustment of the timestamps is necessary in case of data conflicts in the read phase. In OCC-DA the serialization order of committed transactions may be different from their commit order.

A new optimistic concurrency control method, called OCC-DATI (Optimistic Concurrency Control with Dynamic Adjustment of Serialization Order using Timestamp Intervals), is proposed to reduce the number of transaction restarts in [Lindstrom], which uses information about the criticality of the transactions in the conflict resolution. The main idea behind this method is to offer better chances for critical transactions to complete according to their deadlines. This is achieved restarting transaction with lower criticality if the critical transaction should be restarted because of a data conflict. The proposed method is demonstrated to produce the correct results and the feasibility of the proposed method in practice is tested.
