**3.1 System model**

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

[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 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

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

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

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

transactions. For these methods X takes the values infinite, 0 and 50 respectively.

transaction waits if at least 50% of the conflicting transactions have higher priority.

allocated time slot. Time slots are adjusted when a transaction commits.

the read set of the validating transaction is not empty either [Lee].

drawbacks [Lee].

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 sensors. The entire data object is divided into two categories in database:

1. temporal objects and non-temporal objects

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 validity of Xi , after avie(Xi), value (Xi) is effective no longer.

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


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

**Definition1.** Data-deadline of transaction T is the minimum data time validity which

to t t e X RS (T) dd (T) min avi (X) <sup>∈</sup> =

The temporal relationship between temporal data and transaction is presented by datadeadline. The data-deadline increased the difficulty of transaction scheduling and concurrent control, because no achieving deadline to the transactions may restart or abort due to the data deadline. Example 1 shows that the data-deadline of transactions influences

The deadline of transaction T1 is t7, and its estimated time of completion is t6. The deadline of transaction T2 is t8; and its estimated time of completion is t6. The validity of temporal

As shown in Fig. 1, transaction T2 enter into validation phase at time t5, according to literature [Lindstrom, Wang], WS(Tv)∩RS(Ta)={y}≠Ø, transactions execution sequence is T1→T2, T2 will delay to submit. If transaction T1 submits after t6, transaction T2 will die for

Do not consider real-time of data, we will succeed scheduling T1, T2 , according to the traditional optimistic method[Lindstrom]; But it increases the real-time nature of data, transaction T2 will die because it can't satisfy data-deadline. Example1 shows the temporal characteristics of the data influence the concurrency control, while the existing concurrency

In addition to data-deadline, there is another important characteristic is the stability of the data. Real-time data has different rate of change, some change frequently and others not. If |avie (X) -avib (X) | < k , we denoted temporal data as changeful, otherwise stable. According to the different time limit of transactions, the value k dynamic changes along with the transaction access to temporal data, it will be discussed in detail in the next

control method is no consideration to the conflict which access temporal data.

transaction T access to the temporal data objects at time t, denote it as dd (T) <sup>t</sup> ,

the concurrent control.

the temporal data z exceed deadline.

Fig. 1. Execution of Transactions

section.

data z is [t4, t6].

**Example 1.** Transaction T1: w1(x)r1(y); T2:w2(y)r2(z).

2. the basic objects and derived objects

The basic objects update the database by the sensor and reflect specific entity in the real environment. Derived objects are composed by the new derived data from basic object and others. In Active real-time database, it can trigger transactions according to ECA rules when basic object is updated by sensor. Triggered transactions may update the status from the basic derived objects. In this chapter, the basic object take need scheduling strategy, until transactions need call, it was called by sensor. Transactions T call temporal data X at time t, absolute validity for the start time is t.

Active real-time database system had sensor transaction, which are used to update basic objects, only writing transaction; triggered updating transaction, which are updated and triggered transaction by the basic objects, and used to update derived object; user transaction, which have user transactions of the deadline. When transaction satisfies only the following conditions in system, it commits successfully:

