Real-time data semantics and similarity-based concurrency control

Real-Time Data Semantics and

Similarity-Based Concurrency Control

Tei-Wei Kuo, Member, IEEE, and Aloysius K. Mok, Member, IEEE

AbstractÐThis paper formalizes the concept of similarity which has been used on an ad hoc basis by application engineers to provide more flexibility in concurrency control. We show how the usual correctness criteria of concurrency control, namely, final-state, view, and conflict serializability, can be weakened to incorporate similarity. We extend the weakened correctness criteria in [16] for real-time applications which may run continually, have concurrent transaction executions, or skip unimportant computations. A semantic approach based on the similarity concept is then taken to propose a sufficient condition for scheduling real-time transactions without locking of data.

Index TermsÐConcurrency control, schedule correctness, real-time database, serializability, similarity.

æ

1 I

W

mostly on throughput, there is increasing interest in the performance of transaction systems that have significant response time requirements. These requirements are usually posed as hard or soft deadlines on individual transactions so that a concurrency control algorithm must attempt to meet deadlines, as well as preserve database consistency. A number of analytic and simulation studies on the performance of scheduling algorithms to meet deadlines have been reported in the literature, e.g., [1], [2], [13], [27], [30], [34], [37], [38], [36], [41]. In these studies, database consistency is preserved by enforcing serial-izability. However, serializability is often too strict a correctness criterion for real-time applications, where the precision of an answer to a query may still be acceptable even if serializability is not strictly observed in transaction scheduling. Obviously, violation of serializability must be justified in the context of the semantics of the application domain. The subject of this paper is to explore a weaker correctness criterion for concurrency control in real-time transactions by investigating the notion of similarity.

Similarity is closely related to the important idea of imprecise computation in real-time systems [25] and also to the idea of partial computation for databases [8]. The idea of similarity is certainly not new in practice. In avionic systems, the dynamics of a sensor or the environment may impose an upper bound on the change in the sensor reading over a short time interval. For certain computations, engineers often consider the change in sensor reading over a few consecutive cycles to be insignificant in the execution of the avionic software. It is sometimes acceptable to use a

sensor value that is not the most recent update in a transaction. This suggests that serializability can be weakened in concurrency control of real-time transactions. However, it is imperative for us to justify and make explicit the implicit assumptions that are behind the currently ad hoc engineering practice. They can be the cause of costly errors.

Real-time databases should model the real world with sufficient precision. Several consistency requirements be-sides internal consistency [4] have been introduced in [15], [16], [20], [30], [26], [36], [41]. External consistency require-ments keep real-time databases up-to-date; temporal consis-tency requirements ensure that multiple data objects read by a transaction are compatible in the currency of their data. External and temporal consistency constraints are design specifications that are introduced to cope with the dynamic nature of the operating environment, inasmuch as a real-time database can capture the values of real-world objects only up to a certain precision. Hence, the consistency constraints on real-time databases are inherently concerned with imprecise values. Intuitively, data values that are sufficiently close by some metric may be interchanged as input to a transaction without undue adverse effects. This motivates the concept of similarity among data values. The satisfaction of external and temporal consistency constraints ensures that such interchanges are admissible, but the adequacy of the consistency constraints must be justified by the semantics of data similarity.

In this paper, we formalize the concept of similarity, which has been used on an ad hoc basis by application engineers to provide more flexibility in concurrency control. We show how the usual correctness criteria of concurrency control, namely, final-state, view, and conflict serializabil-ity, can be weakened to incorporate similarity. We then generalize the weakened correctness criteria in [16] for infinite schedules and extend the criteria when true parallelism, instead of interleaving, is considered. We propose the idea of physical schedules in which a real-time database scheduler may skip unimportant computation or updates to meet time constraints and/or satisfy some safety requirements on the system. The correctness of physical

. T.-W. Kuo is with the Department of Computer Science and Information Engineering, National Taiwan University, Taipei, Taiwan 106, ROC. E-mail: [email protected].

. A.K. Mok is with the Department of Computer Sciences, University of Texas at Austin, Austin, TX 78712. E-mail: [email protected]. Manuscript received 5 Aug. 1997; revised 11 Aug. 1998; accepted 20 Sept. 2000.

For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number 105465.

schedules is justified by the notion of similarity. We then take a semantic approach based on the similarity concept to propose a sufficient condition for scheduling real-time transactions without locking of data.

The rest of this paper is organized as follows: In Section 2, we define the system model and formally introduce the concept of similarity. In Section 3, we show how the traditional correctness criteria of concurrency control can be weakened to incorporate similarity. In Section 4, we extend the proposed weaker consistency requirements [16] on infinite schedules, parallel executions, and physical schedules. Section 5 describes a sufficient condition with which transactions can be scheduled independently. We then further extend the results. Section 6 is the conclusion.

2 S

R

-T

T

2.1 Data Objects, Events, Transactions, and Schedules

A real-time database is a collection of data objects. Each data object takes its value from its domain. We define a database state as an element of the Cartesian product of the domains [29] of its data objects. A database state may be represented by a vector of data values such that every data object is a component of this vector.

Events are primitive database operations (read or write). A transaction is the template of its instances; a transaction instance is a partial order of events. An instance of a transaction is scheduled for every request of the transaction. To distinguish between a transaction and an instance of it, we shall use the notation i;j to denote the jth instance of

transaction i. An interpretation of a set of transactions is a

collection of transaction definitions and data domain definitions [29].

A schedule over a set of transactions is a partial order of events issued by instances of the transaction set. Each event in a schedule is issued by one transaction instance. The ordering of events in a schedule must be consistent with the event ordering as specified by the transaction set. In this paper, schedules are represented by sequences of events that are consistent with the partial order of the schedule. A serial schedule is a sequence of transaction instances (i.e., a schedule in which the transaction instances are totally ordered).

2.2 Timed Events and Timed Schedules

A real-time computation may be represented as a collection of events with time-stamps. The time-stamp of each event in the computation indicates its occurrence time. Events with such time-stamps are called timed events. In other words, a real-time computation is a collection of timed events.

Let a timed schedule over a set of transactions be a collection of timed events issued by instances of the transaction set. Each event in a timed schedule is issued by one transaction instance. The time ordering of events in a timed schedule must be consistent with the partial order of the corresponding events as specified by each transaction. It is clear that corresponding to each timed schedule is a unique (untimed) schedule which preserves the time-stamp order of events in the timed schedule.

A real-time computation, such as an engine warming-up procedure, is a timed schedule. It should be not only logically correct, but also in timely fashion. The timeliness of events can be properly checked regarding their occur-rence times, whereas the logical correctness of the computa-tion must be justified through a careful examinacomputa-tion of its corresponding (untimed) schedule, which preserves the time-stamp order of events in the computation. In this paper, we shall devote our efforts in justifying the logical correctness of real-time computations.

2.3 Similarity

A real-time database models an external environment that changes continuously. The value of a data object that models an entity in the real world cannot in general be updated continually to perfectly track the dynamics of the real-world entity. The time needed to perform an update alone necessarily introduces a time delay which means that the value of a data object cannot be instantaneously the same as the corresponding real-world entity. Fortunately, it is often unnecessary for data values to be perfectly up-to-date or precise to be useful. In particular, data values of a data object that are slightly different in age or in precision are often interchangeable as read data for transactions. This observation underlies the concept of similarity among data values. The concept of similarity can be described in terms of regions in the state space of a database.

As an example, let us consider the similarity of data read by two transactions in a railroad-crossing monitor system. Suppose there are two data objects, distance and velocity, which provide information about the nearest approaching train. In Fig. 1, s is a database state (a point) in the database state space of the system. Let 1 be a transaction that

displays the distance and velocity of the approaching train on the monitor. The other transaction, 2, controls the

crossing gate, which depends only on the distance of the train. With different precision requirements, 1 and 2

regard data values falling inside, respectively, 1's box and

2's box to be similar to their counterparts in the state s.

Notice that, because 2does not read velocity, all values in

the domain of velocity are similar to one another and, therefore, similar to that at s. In our model, two values of a data object are similar if and only if all transactions that may read them consider them as similar.

2.3.1 Definition of Similarity

Similarity is a binary relation on the domain of a data object. Every similarity relation is reflexive and symmetric, but not necessarily transitive. Different transactions can have different similarity relations on the same data object domain. Two views of a transaction are similar iff every read event in both views uses similar values with respect to the transaction. We say that two values of a data object are similar if all transactions which may read them consider them as similar.

In a schedule, we say that two event instances are similar if they are of the same type and access similar values of the same data object. We say that two database states are similar if the corresponding values of every data object in the two states are similar.

As one might expect, there is no general criterion for determining whether two values are similar. More often than not, proximity in data value alone may not be a good criterion. For example, a temperature of 99_{C is equidistant}

from 98_{C and 100}_{C. Whereas one might consider 99}_{C to}

be similar to 98_{C as far as hotness of water is concerned,}

there is a qualitative difference between 99_{C and 100}_C

because water turns into steam at 100_{C. In general,}

similarity need not be transitive if the proximity of values is defined in terms of ªmagnitude difference.º However, some mappings such as ªroundingº or ª=º that may be used in establishing similarity do yield transitive similarity relations.

Similarity is an inherently application-dependent con-cept and we expect the application engineer to define it for specific applications. Similarity can be defined by explicit declaration or other syntatic conventions. For example, a transaction might have associated with it a set of para-meters to specify read-data similarity. A related approach is found in [31].

A minimal restriction on the similarity relation that makes it interesting for concurrency control is the require-ment that it is preserved by every transaction, i.e., if a transaction  maps database state s to state t and state s0_to

t0_{, then t and t}0_{are similar if s and s}0_{are similar. We say that}

a similarity relation is regular if it is preserved by all transactions. From now on, we shall be concerned with regular similarity relations only. Further restrictions on the similarity predicate will yield a correctness criterion for transaction scheduling that can be checked efficiently.

3 C

C

3.1 Related Work

Previous work on real-time databases can be roughly classified into three types: semantics and requirements of real-time databases, design of real-time transaction sche-duling algorithms, analytic and experimental studies of concurrency control protocols with deadlines. A compen-dium of recent approaches can be found in [3], [35].

In conventional databases, the notion of correctness of a schedule has mainly been based on the concept of

serializability [29]. Three increasingly restrictive criteria for correctness are commonly accepted and have been studied in depth. They are: final-state serializability, view serial-izability, and conflict serializability [29]. Other different correctness criteria have been proposed for different purposes and application areas [7], [10], [11], [14], [21], [30], [31], [33]. We list some of them below.

Several new consistency requirements besides internal consistency [29] have been discussed [20], [22], [26], [30], [36] in relation to real-time systems. Song and Liu [36] also evaluate the effectiveness of multiversion lock-based con-currency control algorithms in maintaining the temporal homogeneity of shared data. New real-time transaction scheduling algorithms are proposed in [2], [20], [27], [30], [34], [39], [41]. In particular, Xiong et al. [41] exploited temporal data similarity and evaluated the performance improvement of transactions when combinations of simi-larity and forced wait policies were considered. A force wait policy may force a transaction to delay further execution until a new version of sensor data becomes available.

Garcia-Molina and Wiederhold in [11] discarded con-sistency considerations for read-only transactions, with the stipulation that, after read-only transactions have been removed, the resulting schedule should be serializable. Garcia-Molina and Salem [10] also proposed ªSAGASº so as to solve consistency problems brought on by long-lived transactions. SAGAS are long-lived transactions that can be broken up into a collection of subtransactions that can be interleaved in any way with other transactions. Thus, SAGA is not atomic, but should be executed as a unit. It means that correct schedules can be nonserializable.

Peng and Lin proposed the idea of compatibility matrix to allow transactions to acquire different degrees of consistency requirements [30]. Their work was motivated by avionic systems and automated factories that have a limited number of high-speed sensors with frequent user-initiated command processing. The rationale behind their work was that the consistency between the device readings and the current values used by transactions could be more important than the serializability of transactions.

Korth and Speegle [21] proposed a formal model which allows transactions to specify preconditions and

postconditions. These conditions can be specified in conjunctive normal form. They enforced serializability with respect to every conjunct in the conjunctive normal form by a criterion called predicatewise serializability. Their model also includes consideration of nested transactions and multiple versions.

Epsilon-serializability (ESR) [31], [33] formalizes the query behavior by deriving the formulae that express the inconsistency in the data values read by a query. Transac-tions are associated with limits of importing inconsistency and exporting inconsistency. Query transactions are al-lowed to view inconsistent data in a controlled fashion. Kamath and Ramamritham [14] then introduced the idea of hierarchical inconsistency bounds that allows inconsistency to be specified at different granularities such as transactions and objects. They provided mechanisms to control the inconsistency and reported the evaluation of the perfor-mance improvement due to ESR.

Our proposed criteria can be viewed as extensions of the standard correctness criteria to exploit the concept of similarity. As a result of our extension, it is possible to permit much more concurrency for updates that are close in time.

3.2 View Similarity and
-Serializability

Our proposed criteria can be viewed as extensions of the standard serializability-based correctness criteria [29] to exploit the concept of similarity. Three correctness criteria defined in [16] are final-state, view, and conflict
-serial-izability. The definition of final-state
-serializability can be found in [16].1

The transaction view of a transaction instance is a vector of data object values such that the ith component is the value read by the ith read event of the transaction instance [29].

Definition: View Similar. A schedule is view-similar to another schedule iff

1. They are over the same set of transactions (transaction instances).

2. For any initial state and under any interpretation,2

they transform similar initial database states into similar database states with respect to their transaction sets, respectively.

3. Every transaction instance has similar views in both schedules for any initial state and under any interpretation.

It is clear that, if a schedule is view-equivalent to another schedule, then it is view-similar to that schedule, but the converse may not hold. Note that the view-similarity relation between schedules is reflexive and symmetric, but not necessarily transitive. A schedule is view
-serializable iff it is view-similar to a serial schedule.

Example 1: view similarity and view
-serializability. The schedule

1ˆ W…3;1; X†; R…1;1; X†; W…1;1; X†; R…2;1; X†; !

R…2;1; Y †; W…2;1; Y †; W…1;1; Y †

is view similar to the schedule 2ˆ 3;1; 2;1; 1;1

ˆ W…3;1; X†; R…2;1; X†; R…2;1; Y †; W…2;1; Y †; !

R…1;1; X†; W…1;1; X†; W…1;1; Y †

if W…3;1; X† and W…1;1; X† are similar. Since 2is a serial

schedule, 1is view
-serializable.

In general, we can show the following theorem:

Theorem 1. Given a polynomial-time procedure for determining if any two states are similar, the problem of deciding whether a schedule is view
-serializable is NP-Hard.

Proof. Follows directly from the view serializability problem [29]. tu 3.3 Conflict Similarity and
-Serializability

The NP-hardness of determining view
-serializability motivates us to find a stronger correctness criterion. In this section, we shall extend the notion of conflict serializability to include the similarity concept. Unlike view serializability, the extension to conflict
-serializability must deal with a new problem, namely, the intransitivity of some similarity relations in order to define equivalent relations (i.e., relation free…† in Section 3.3.2) of ªsimilarº events. The definition of such equivalent relations is essential in defining the equivalent relations of ªsimilarº conflict
-serializable schedules.

3.3.1 Strong Similarity

Our definition of regular similarity only requires a similarity relation to be preserved by every transaction so that the input value of a transaction can be swapped with another in a schedule if the two values are related by a regular similarity relation. Unless a similarity relation is also transitive, in which case it is an equivalence relation, it is in general incorrect to swap events an arbitrary number of times in a schedule. For example, let v1, v2, v3 be three

values of a data object such that v1and v2are similar, as are

v2 and v3. A transaction instance reading v1 as input will

produce similar output as one that reads v2 as input.

Likewise, the same transaction reading v2 as input will

produce similar output as one that reads v3 as input.

However, there is no guarantee that the output of the transaction reading v1 as input will be similar to one

reading v3as input since v1and v3may not be related under

the regular similarity relation. Swapping events two or more times may result in a transaction reading a value that is not similar to the input value before event swapping and is hence unacceptable. In this section, we add another restriction to the similarity relation such that swapping similar events in a schedule will always preserve similarity in the output.

This restriction is motivated by the observation that the state information of many real-time systems is ªvolatile,º i.e., they are designed in such a way that system state is determined completely by the history of the recent past, e.g., the velocity and acceleration of a vehicle are computed

1. A schedule is final-state similar to another schedule if the first two conditions of the following view similarity definition are satisfied.

2. An interpretation of a set of transactions is a collection of transaction definitions and data domain definitions [29].

from the last several values of the vehicle's position from the position sensor. Unless events in a schedule may be swapped in such a way that a transaction reads a value that is derived from the composition of a long chain of transactions that extends way into the past, a suitable similarity relation may be chosen such that output similarity is preserved by limiting the ªdistanceº between inputs that may be read by a transaction before and after swapping similar events in a schedule.

For example, suppose we want to compute the bearing of a vehicle to a reference point and this distance data can be computed with acceptable precision only if the position data is accurate to within 10 meters, where the position data is updated from a sensor every second. Assumptions are often made in practice that the time derivative of the position data is bounded. Thus, if we need a precision of 10 meters and every sample of the position data differs from the previous one by no more than 1 meter, then it is acceptable to use any one of the last 10 samples, assuming that sensor updates are perfectly accurate. This idea can be captured in terms of the data dependency of an event in a schedule as follows:

Recall that a schedule over a transaction set is a partial order of events issued by the transaction instances in the set. Given a schedule , we define its data dependency graph G…† as follows: Corresponding to every read/write event in  is a read/write node in G…†. There is a directed edge(arc) from a read node to a write node in G…† if they are issued by the same transaction instance and the read event precedes the write event in . There is a directed edge from a write node to a read node in G…† if the corresponding read event reads the output value of the corresponding write event in . We note that data dependency graphs are acyclic since the time-stamp of the node at the head of an edge is always greater than that of the node at the tail.

We define the w-length of a path in a data dependency graph to be k if there are exactly k write nodes in the path, k  1. A path with infinitely many write nodes in a data dependency graph has w-length 1. We say that a data dependency graph has depth k if the maximum w-length of its paths is k. A schedule has ddg depth k if its data dependency graph has depth k.

Suppose
is a similarity relation and
i_{is the ith power}

of
, i  1. (Since
is reflexive,
i_
j_{if i  j.) We define}

a similarity relation
#

 with respect to a schedule  as

follows:

1. If the ddg depth of  is 1, then
#

 is defined to be

_{, the transitive closure of
.}

2. If the ddg depth of  is k, k  1, then
#

 is defined to

be
k‡1_.

We say that a schedule  strongly preserves a similarity relation
(or
is a strong similarity relation for a schedule ) if every transaction that has an instance in  preserves
#

 (i.e., for every transaction  that has an

instance in , if  maps database state s to t and state s0_{to t}0_,

then t and t0_{are related by}
#

 if s and s0are related by
#).

In this paper, we shall assume that every similarity relation
is strongly preserved by all serial schedules of the transaction set in a system. In practical real-time

systems, this assumption can often be weakened since the schedules that are produced by a system are often reducible to only a subset of the set of all serial schedules of the transaction set of the system (e.g., as a result of the time constraints imposed by the application). The results reported herein can be strengthened by requiring a similarity relation to be strongly preserved by only those serial schedules that are reduced from the set of schedules produced by the system (e.g., the time constraints may be such that each update on an object is an instance of a transaction that modifies the value of an object in small increments). Without making use of application-specific information, the above assumption is the weakest we can make. From now on, we shall refer to a strong similarity relation with the assumption that it is strongly preserved by all serial schedules.

We say that two data values v1, v2 are weakly similar

under a similarity relation
with respect to a schedule  if  strongly preserves
and v1, v2are related by
#. When

there is no ambiguity, we shall say that v1, v2 are weakly

similar and omit the reference to
and . Notice that two values that are similar must be weakly similar, but the converse is not necessarily true.

Let RE…† be the set of all read events in a schedule  and WE…† be the set of all write events in . Suppose init is a distinct write event which creates the initial state of schedule . Let DB be the set of data objects in the database under discussion. DSPACE is the space of all possible database states. Suppose domain…obj† denotes the domain of data object obj and access…e† is the data object accessed by event e. We define three functions on the events in schedule  as follows:

. Wr: RE…† ! WE…† [ finitg: Wr…er† returns the

write event from which a read event erreads in . If

er reads from the initial state, Wr…er† returns init.

. Upd: DB ! WE…† [ finitg: Upd…obj† returns the

last write event which updates the data object obj in . If no write event accesses obj, Upd…obj† returns

init. .

Out: …DSPACE; WE…†† ! domain…access…ew†† :

Suppose istate is an initial database state of schedule . Outi…istate; ew† returns the write-value of ew(the

value of the accessed data object access…ew†) in

schedule  if  starts with initial state istate. When there is no ambiguity, we shall use Out…ew† and

omit the reference to the initial state. Given any similarity relation
, we write x 
y iff two data values x and y of

the same data object are defined and are similar under
. For convenience, let Out…init† ˆ Out0…init† for any two

schedules  and 0_{(although the special event init is not in}

any schedule).

With the introduction of strong similarity relation, the definitions of final-state and view
-serializability ought to be modified. Two schedules are final-state similar if they transform strongly similar states (under
) into similar states (under
#_{). Corresponding transaction views in two}

#_{). These modifications enlarge the collection of schedules}

which are final-state or view similar to a given schedule. Notice that requiring final-state similar schedules to trans-form similar states (under
#_{) into similar states (under}

#_{) unnecessarily restricts a class of final-state or view}

similar schedules and reduces its applicability in practice. Suppose the schedules  and 0_{have the same event set}

E and
is a strong similarity relation for  and 0_{. We say}

that 0_{is a derived schedule of  if}

8er2 E; Out…init; Wr…er†† 
Out…init; Wr0…e_r††

and

8obj 2 DB; Out…init; Upd…obj†† 
Out…init; Upd0…obj††;

where initial state init can be omitted for convenience. (DB is the set of data objects in the database.)

Suppose k is the maximum of the ddg depths of  and 0

and let
#_ˆ
k‡1_{. We shall show that  and }0 _are

view-similar under the relation
#_{. That is, given two strongly}

similar initial states init and init0_,

8er2 E; Out…init; Wr…er†† 
#Out_0…init0; Wr_0…e_r††

and

8obj 2 DB; Out…init; Upd…obj††


#Out_0…init0; Upd_0…obj††:

In other words, suppose we swap the events in a schedule  and obtain another schedule 0_{. If every one of the read}

events in 0_{reads from write events that are similar under}

in , then the swapped schedule 0_{will be view-similar to }

under the similarity relation
#_{. Thus, all we need to do to}

maintain consistency is to ensure that the rules for swapping events preserve
, as we shall do in the next section.

Theorem 2. Suppose a schedule 0_{is a derived schedule of another}

schedule  and
#_ˆ
k‡1_{, where k is the maximum ddg}

depths of  and 0_{, then  and }0_{are view-similar under}
#_.

Proof. Given a real-time database system, suppose DB is a collection of data objects in the database and
is a strong similarity relation for schedule  and its derived schedule 0_{. Let E be their event set and let k be the}

maximum ddg depth of  and 0_{so that}
#_ˆ
k‡1_{. We}

shall prove that  and 0_{are view-similar under}
#_{. The}

proof is by induction on the ªdepthº of ªchangedº write events, as defined below.

Let G…† be the data dependency graph of a schedule . Ge…† is a subgraph of G…† which consists of an event

e and all ancestors of e in G…†. An event e in the event set E is unchanged (with respect to  and 0_{) if it satisfies}

any one of the following conditions: (See Fig. 2). Otherwise, it is changed.

1. e is a read event. e reads from initial state in both  and 0_.

2. e is a write event. No preceding read event is issued by the same transaction instance.

3. e is a read event. e reads from the same write event ewin  and 0and ew is unchanged.

4. e is a write event and all preceding read events of the same transaction instance are unchanged. Suppose init and init0 _{are two strongly similar initial}

states, where init and init0_{are initial states for schedules}

 and 0_{, respectively. It is trivial to show that an}

unchanged read event receives strongly similar inputs in  and 0_{. An unchanged write event produces strongly}

similar outputs in  and 0_{. (It is because every}

unchanged event has the same data dependence graph in  and 0 _{and transactions preserve the strong}

similarity relation.)

Let ew be a write event in E. e1w is the changed write

event which has the maximum w-length between itself and ewin Gew…0†. (If there is more than one candidate for

e1

w, select one arbitrarily and apply the same argument

below.) Let m be the w-length of the path from e1 wto ew

minus one. If e1

wˆ ew, m ˆ 0. If e1wdoes not exist, ewis an

unchanged write event and produces strongly similar outputs in  and 0_.

We argue that m  …k ÿ 2† (if e1

wexists). Suppose L ˆ

e1; e2;


; enis a maximum w-length path in G…0† where

there is an arc from ei to ei‡1 for i < n. We shall first

show that the first write event closest to e1(it is e1if e1is

a write event) on L is unchanged. Notice that read events and write events alternate on any path in G…0_†.

If e1 is a write event and there exists an arc from a

read event e to e1in G…0†, e must be unchanged and, thus,

e1 is unchanged because L is a path with the maximum

w-length. If e1 is a write event and no preceding read

event is issued by the same transaction instance, e1 is

unchanged according to the ªunchangedº definition. Suppose e1 is a read event and e2is a write event. e1 is

unchanged because L is a path with the maximum w-length. Suppose there is another read event er having

an arc from er to e2. er is also unchanged with the same

argument for the read event e1. Since all preceding read

events issued by the same transaction instance are unchanged, e2must be unchanged.

The above arguments ensure that the first write event closest to e1on L is unchanged. Given a write event ewand

its e1

won L, m, which is the w-length of the path from e1w

to ew minus one, is no larger than …k ÿ 2† because e1w,

which must be changed, cannot be the first write event closest to e1on L. Since L has the maximum w-length in

G…0_{†, given any write event ew and its e}1

w on any path,

m  …k ÿ 2†. If e1

wexists, we shall show that, when m  …k ÿ 2† for

m  0, Out…init; ew† 
m‡2 Out_0…init0; e_w†. The proof is

by induction on m.

Induction basis: m ˆ 0 and e1

wˆ ew. Because ew is

changed, some er of the preceding read events of the

same transaction instance is changed. Because m ˆ 0, Wr0…e_r† is unchanged, i.e.,

Out0…init0; Wr_0…e_r†† 
Out_…init; Wr_0…e_r††:

Because of the assumption

8er2 E; Out…init; Wr…er†† 
Out…init; Wr0…e_r††;

Out0…init0; Wr_0…e_r†† 
2Out_…init; Wr_…e_r††:

That is, Out0…init0; e_w† 
2Out_…init; e_w†.

Induction step: The induction hypothesis assumes t h a t , w h e n m  i f o r s o m e 0  i  …k ÿ 3†, Out…init; ew† 
m‡2 Out_0…init0; e_w†. Let m ˆ i ‡ 1.

Sup-pose e2

w is the write event closest to ewon the path from

e1

w to ew, as shown in Fig. 3. Let a read event er be

between ew and e2w. By the induction hypothesis,

Out…init; e2w† 
i‡2 Out_0…init0; e2_w†. Let a write event

e3

wˆ Wr…er†, as shown in Fig. 3. If e3wˆ e2w, then

Out…init; Wr…er†† 
i‡2 Out_0…init0; Wr_0…e_r†† because

Out…init; e2w† 
i‡2 Out_0…init0; e2_w†. I f e3_w6ˆ e2_w, t h e n

Out…init; e2w† 
Out…init; e3w†becauseoftheassumption

8er2 E; Out…init; Wr…er†† 
Out…init; Wr0…e_r††:

Since

Out…init; e2w† 
i‡2 Out_0…init0; e2_w†;

Out…init; e3w† 
i‡3 Out_0…init0; e2_w†;

i.e., Out…init; Wr…er†† 
i‡3 Out_0…init0; Wr_0…e_r††. Since

e1

wis the changed write event which has the maximum

w-length between itself and ew in Gew…0†, for every

preceding read event er of the same transaction instance,

Out…init; Wr…er†† 
i‡3 Out_0…init0; Wr_0…e_r††. Because

transactions preserve these similarity relations, Out…init; ew† 
i‡3 Out_0…init0; e_w†.

Since, when m  …k ÿ 2† for m  0, Out…init; ew† 
m‡2 Out_0…init0; e_w†

and m  …k ÿ 2†,

Out…init; ew† 
kOut_0…init0; e_w†

for any write event ew in E. Furthermore, because 8er2

E; Out…init; Wr…er†† 
Out…init; Wr0…e_r†† and

8obj 2 DB; Out…init; Upd…obj†† 
Out…init; Upd0…obj††;

8er2 E; Out…init; Wr…er†† 
k‡1Out_0…init0; Wr_0…e_r††

and

8obj 2 DB; Out…init; Upd…obj††


k‡1Out_0…init0; Upd_0…obj††:

Therefore, from strongly similar initial states (under
), the transaction view of any transaction instance and the final states of  and0 _{are similar (under}
#_{). tu}

3.3.2 Conflict
-Serializability

Suppose a schedule  consists of a set E of events and a set T of transaction instances. Let
be a given strong similarity relation. A relation free…† over E is a set f…ei; ej†g of event

pairs in which ei and ej satisfy any of the following

conditions, where i 6ˆ j:

1. ei and ej do not conflict with each other.

2. ei and ej are conflicting write events, but they are

similar under
.

3. ei and ejare conflicting events and one of them is a

read event. Suppose erand eware the read and write

events, respectively, and er precedes ew. Suppose e0w

(e0

w6ˆ ew) is the write event which writes the value

read by erin  and ewand e0ware similar under
.

Notice that the free…† relation is a collection of swappable events in schedule , which can be falsified if a read event and some preceding conflicting write event also satisfy the relation. For example, let events in a schedule  ˆ e1

w; e2w; e3w; er conflict with each another,

where ei

w and er are a write event and a read event,

respectively. Suppose e2

w is strongly similar to both e1w

and e3

w and free…† ˆ f…e1w; e2w†; …ew2; e3w†g. If …er; e3w† satisfy

the free…† relation, then  can be transformed into e2

w; e1w; er; e3w by swapping event pairs …e1w; e2w† and …er; e3w†.

As a result, erreads from e1w, which is not strongly similar to

e3

w in schedule .

Suppose  is a schedule and R is a reflexive and symmetric binary relation over the events in . Let 0 _{be a}

schedule which has the same events as . We say that  !R0if 0can be obtained from  by changing the order

of two consecutive events, e1 and e2 in  and …e1; e2† 2 R.

Let !

R be the transitive closure of the relation !R. A

schedule 1 is conflict similar to another schedule n iff

Fig. 3. e1

1!free…1†n. Notice that the relation free…1† is computed

with respect to 1.

A schedule is conflict
-serializable iff it is conflict similar to a serial schedule. Obviously, if a schedule is conflict equivalent to another schedule, it is conflict similar to that schedule, but the converse may not hold. The conflict similarity relation is reflexive, but not necessarily sym-metric or transitive.

Example 2: Conflict
-serializability. The schedule 1ˆ R…1;1; Y †; R…2;1; Y †; W…1;1; Y †; W…1;1; X†; !

W…2;1; X†

conflict similar to the schedule

2ˆ 2;1; 1;1ˆ R…1;1; Y †; R…2;1; Y †; W…1;1; Y †; !

W…2;1; X†; W…1;1; X†

if W…1;1; X† and W…2;1; X† are strongly similar. Since 2

is a serial schedule, 1is conflict
-serializable.

Example 3: View
-serializable but not conflict
-serial-izable schedules. The schedule

 ˆ R…1;1; Y †; R…2;1; Y †; W…1;1; Y †; W…1;1; X†; !

W…2;1; X†; W…3;1; X†

is view-similar but not conflict-similar to 2;1; 1;1; 3;1

unless W…1;1; X† and W…2;1; X† are strongly similar.

In general, we can show the following.

Lemma 1. A schedule  is conflict similar to another schedule 0

iff every two conflicting events e and e0_{occur in the same order}

in  and 0 _{unless e and e}0 _{satisfy condition 2 or 3 in the}

definition of the free relation.

Proof. The only-if part is based on the fact that 0 _{can be}

obtained from  by swapping every two consecutive events which satisfy the free relation (according to the definition of conflict similarity). Therefore, every two conflicting events e and e0_{must occur in the same order}

in  and 0_{unless e and e}0_{satisfy condition 2 or 3 in the}

definition of the free relation.

The if part can be proven in a similar way as the proof of conflict equivalence in [29]: Let k be the number of pairs of events of the two schedules which occur in different order in  than in 0_{. We shall show, by}

induction on k, that  is conflict similar to 0_{. If k ˆ 0,}

then  and 0 _{are identical (Induction Base). Let k ˆ m}

and m  0 and  is conflict-similar to 0 _(Induction

Hypothesis). Suppose that k ˆ m ‡ 1. Let e1 and e2 be

two consecutive events which occur in different order in  than in 0_{. Because every two conflicting events e and e}0

occur in the same order in  and 0_{, unless e and e}0_satisfy

condition 2 or 3 in the definition of the free relation, e1

and e2 can be swapped without violating the definition

of conflict similarity. It follows that, after the swapping, there are only m pairs of events of the two schedules which occur in different order in  than in 0_{. We}

conclude that  is conflict similar to 0_{. tu}

Lemma 2. Suppose two schedules 1and n satisfy the relation

1!free…1†n and
is a strong similarity relation for both

1and n. Then, nis a derived schedule of 1, i.e., either there

is no write event from which a read event erreads in 1and n

or the write events from which er reads in 1 and n,

respectively, are strongly similar in 1. If ew and e0w are the

last write events of certain data object in 1 and n,

respectively, then ewand e0ware strongly similar in 1.

Proof. Suppose er is a read event in 1 and n. We shall

show that either there is no write event from which er

reads in 1and nor the write events from which erreads

in 1and n, respectively, are strongly similar in 1.

Suppose there is no write event from which erreads in

1and erreads from a write event e0win n. It implies that

e0

w is after er in 1. Since there is no write event from

which erreads in 1, there is no event in 1with which er

can satisfy any condition in the definition of the free…s1†

relation. According to Lemma 1, the order of er and e0w

must be the same in 1 and n. This is contradictory to

the assumption.

Suppose er reads from ew in 1, but there is no write

event from which a read event erreads in n. Because ew

and ercan never satisfy any condition in the definition of

the free…s1† relation such that their order can be

changed, according to Lemma 1, the order of ew and er

is the same in 1 and n, again a contradiction.

Suppose eris a read event which reads from different

write events ewand e0win 1and n, respectively. If e0wis

after erin 1, then the order of e0w and erare different in

1 and n because e0w is before er in n. According to

Lemma 1, e0

w and er must satisfy condition 3 in the

definition of the free…s1† relation, i.e., ew and e0w are

strongly similar in 1.

Suppose e0

wis before er in 1. It is impossible to have

e0

w after ewin 1because er reads from ewin 1. So, e0wis

before ewand erin 1. Because ewand ercan never satisfy

any condition in the definition of the free…s1† relation

such that their order can be changed, according to Lemma 1, the order of ewand eris the same in 1and n.

This implies that the order of ewand e0wis different in 1

and nbecause erreads e0win nand e0wis before ewin 1.

According to Lemma 1, ewand e0wmust satisfy condition 2

in the definition of the free…s1† relation, i.e., ewand e0ware

strongly similar in 1.

Therefore, either there is no write event from which er

reads in 1and nor the write events from which erreads

in 1and n, respectively, are strongly similar in 1.

Suppose ew and e0ware the last write events of certain

data object in 1and n, respectively. We shall show that

ew and e0ware strongly similar in 1. If ewand e0w are the

same write event, the proof is complete. Otherwise, the orders of ewand e0ware different in 1and nbecause ew

is after e0

w in 1 and e0w is after ew in n. According to

Lemma 1, ew and e0w must satisfy condition 2 in the

definition of the free…s1† relation, i.e., ew and e0w are

strongly similar in 1. tu

Lemma 3. Any conflict
-serializable schedule is view
-serializable.

Proof. Follows from Theorem 2 and Lemma 2. tu Lemma 4. There is a view
-serializable schedule that is not

Proof. From Example 3. tu Given a schedule , we define its transaction dependency graph TG…† as follows: Corresponding to every transaction instance in  is a node in TG…†. There is an arc from a node  to another node 0_{in TG…† if there are two events e and e}0

in  and 0_{, respectively, which do not satisfy the free…†}

relation and e precedes e0_{in . For simplicity, let us call any}

two events in  which do not satisfy the free…† relation being ordered in .

Theorem 3. The problem of determining whether a schedule is conflict
-serializable can be solved in O…n2_{† time, where n is}

the number of events in the given schedule.

Proof. Given a schedule , let TG…† be its transaction dependency graph. By Lemma 1,  is conflict
-serial-izable iff TG…† is acyclic. The cycle detection problem can be solved in O…n2_{† time. tu}

4 E

4.1 Continual Operation

Since real-time applications usually run continually, data-base consistency may not be maintained at points when some transaction instances have not completed their executions. However, it is sufficient if every transaction instance sees a consistent view of the database. The purpose of this section is meant to extend the definitions of
-serializability to schedules with incomplete transaction instances (to be defined later). A similar idea can be found in [29].

Definition: Incomplete Transaction Instance. An instance of a transaction is incomplete in a schedule if the schedule contains all events of the transaction instance which occur before some specified event in the instance.

Note that a transaction instance is complete in a schedule if the schedule contains all events of the transaction instance.

Example 4: Incomplete Transaction Instances. Let 1;1and

2;1 be instances of transactions 1 and 2, respectively,

where 1reads and writes data object X and 2reads and

writes data object Y . Consider the following schedule:  ˆ R…1;1; X†; R…2;1; Y †; W…1;1; X†:

1;1and 2;1are a complete transaction instance and an

incomplete transaction instance in , respectively. 2;1 is

incomplete in  because 2;1 has not yet issued a write

event on Y in .

Intuitively, a schedule is acceptable at some observa-tion point if it can be extended for the database to reach a consistent state, where extending a schedule by making transactions complete does indicate adding more opera-tions. For convenience, we introduce the following definitions: A schedule 0 _{is an extended schedule of}

another schedule  if 0 _{is the schedule  appended with}

events which complete all incomplete transaction in-stances in . A schedule 0 _{is a prefix schedule of another}

schedule  if 0 _{consists of all events in  which occur}

before or concurrently with some specified event in . Because there may be more than one way to complete incomplete transactions, a schedule may have more than one extended schedule.

Example 5: Extended schedules and prefix schedules. Consider the following three schedules:

1ˆ R…1;1; X†; R…2;1; Y †

2ˆ R…1;1; X†; R…2;1; Y †; W…1;1; X†; W…2;1; Y †

3ˆ R…1;1; X†; R…2;1; Y †; W…2;1; Y †; W…1;1; X†;

1 is a prefix schedule of 2 and 3. 2 and 3 are both

extended schedules of 1 where 1 and 2 reads and

updates X and Y , respectively.

A (finite) schedule is potentially final-state/view/conflict
-serializable if at least one of its extended schedules is final-state/view/conflict
-serializable. An infinite sche-dule is final-state/view/conflict
-serializable if every one of its prefix schedules is potentially final-state/view/conflict
-serializable.

Example 6: Extension of a prefix schedule to preserve consistency. Let  ˆ W…1;1; X†; R…2;1; X†

be a prefix schedule of another schedule 0_{ˆ W}

1;1; X†; R…2;1; X†; W…1;1; Y †; R…2;1; Y †. In other

words, 0 _{is an extended schedule of . Because }0 _is

conflict similar to a serial schedule 00_{ˆ 1;1; 2;1,  is}

potentially conflict
-serializable. Note that another schedule

000_{ˆ W}

1;1; X†; R…2;1; X†; R…2;1; Y †; W…1;1; Y †;

which is not final-state/view/conflict
-serializable, is also an extended schedule of .

This justifies our treatment of final-state/view/conflict
-serializability, even though there may not be a time instant at which a real-time database system has no incomplete transaction instances. Note that the complexity of determining whether a parital schedule or a complete schedule is final-state/view/conflict
-serializable are the same if missing events of incomplete transaction instances in a partial schedule are ignored. We shall consider only those transactions that have been completed unless other-wise stated.

4.2 Real ParallelismÐ
-Synchronizability

With the advent of parallel processing, true parallelism instead of interleaving [23] is likely to become more realistic in modeling the concurrent execution of real-time transac-tions. Correctness criteria based on the idea of interleaving (such as
-serializability described in previous sections) cannot capture the semantics of true parallelism. For example, to model the operation of the digital watch in Fig. 4, the notion of serializability cannot capture the semantics of the triggering of the time adjustment function which is invoked by pressing two buttons on the watch simultaneously. The purpose of this section is to extend the idea of
-serializability to justify the correctness of real-time transaction executions with true parallelism.

For real-time transaction execution, although simultane-ity can be explicitly defined by proximsimultane-ity in time, the

consistency of a schedule is usually checked by the relative ordering of events and not their time of occurrence. Simultaneous actions have to be grouped to form parallel transitions when we strip off time in consistency checks. Otherwise, there is no way to distinguish two simultaneous closely timed events from two unrelated events. A parallel action is defined as a partial order of events which denotes a parallel execution of a set of transaction instances. Semanti-cally, transaction instances in a parallel action see the same database state and update the same database state. We require that no w/w-conflict events exist in a parallel action and every read event should take effect before all its conflicting write event in a parallel action.

A parallel action is consistent if it preserves all consis-tency predicates. In fact, a serial action is a special case of a parallel action with a single transaction instance. A synchronous schedule is a sequence of consistent parallel actions. A timed schedule is synchronous if its corresponding schedule is synchronous.

We say that a schedule is final-state/view/conflict
-synchronizable if it is final-state/view/conflict similar to some synchronous schedule.

Theorem 4. The problem of deciding whether a schedule is conflict
-synchronizable can be solved in polynomial time if there exists a polynomial time algorithm for determining whether a parallel action is consistent.

Proof. Given a schedule , let TG…† be its transaction dependency graph, as defined in Section 3. By Lemma 1, all transaction instances in  involved in a cycle should be in a consistent parallel action and merged into a single node in TG…† if  is conflict
-synchronizable. Since there exists a polynomial time algorithm for determining whether a parallel action is consistent or not, the problem of deciding whether a schedule is conflict
-synchroniz-able can be solved by executing a sequence of cycle detections and deletions until an inconsistent parallel action is found or no more cycles exist.  is conflict
-synchronizable if no inconsistent parallel action can be found.

Since there are no more than n cycles in TG…†, where n is the number of transaction instances in , and there exists a polynomial time algorithm for determining whether a parallel action is consistent, the problem of deciding whether a schedule is conflict
-synchronizable can be solved in polynomial time. tu The problem of deciding whether a schedule is final-state/view
-synchronizable follows from the NP-hardness of the final-state/view serializability problem.

4.3 Logical Schedules vs. Physical Schedules The concept of physical schedules is motivated by the observation that requests for the same database operation from several transactions that occur close in time can be and are often satisfied by the execution of a single database operation. To make a distinction between the actual physical execution of database operations and the logical events in individual transactions, we shall refer to the schedules that we have discussed so far as logical schedules. In this section, we define the correctness of the physical schedules that result from the actual execution of database operations. With the concept of physical schedules, it is possible to have more flexibility in implementing logical schedules and to justify the correctness of ºactual execu-tion.º Furthermore, under the concept of physical sche-dules, a real-time database scheduler may skip unimportant computation or updates to meet time constraints and/or satisfy some safety requirements on the system.

An occurrence is a pair …op; obj† which represents an event op involving a data object obj. A timed occurrence is an occurrence with a time tag which indicates its occurrence time. A timed physical schedule is a collection of timed occurrences. A physical schedule is a partial order of occurrences.

Definitions: A physical schedule pis a realization of a logical

schedule lif there exists a surjective (onto) mapping which:

1. Maps each read event in lto a read occurrence in p,

2. Maps each write event in l either to a unique write

occurrence in por to the event null,

such that:

1. For any interpretation, l and p transform the same

initial state into the same final state.

2. Each transaction instance has the same view in l

and p.

Note that each read event in a logical schedule must be mapped to a physical occurrence, but some write events in a logical schedule may be mapped to null, in which case they are not performed physically. Each write occurrence in a physical schedule is the image of exactly one write event in the logical schedule, but a read occurrence may be the image of several read events in a logical schedule.

Example 7: Logical schedules vs. physical schedules. The physical schedule: …W; X†; …R; X† is the realization of the logical schedule

W…1;1; X†; W…2;1; X†; R…3;1; X†

through the mapping

W…1;1; X† ! null

W…2;1; X† ! …W; X†;

R…3;1; X† ! …R; X†:

Lemma 5. Every physical schedule p of a logical schedule l

preserves the final-state/view/conflict
-serializability/
-synchronizability property of l.

Proof. Follows directly from the fact that the realization definition preserves transaction views in logical sche-dules and state transformations of logical schesche-dules. tu Our notion of physical vs. logical schedules is different from the Thomas Write Rule (TWR) [40]. TWR ignores obsolete write events instead of rejecting them to prevent obsolete information from entering a database. Together with the basic r/w synchronization rules of a timestamp ordering protocol, serializability of schedules is enforced in TWR. Our concept of physical schedule is different. The unused write events in a schedule can be ignored and several read events from the same write event can be merged to maintain transaction views. Of course, the TWR can be used as to implement physical schedules; however, they were proposed for different applications.

5 A S

C

A

S

F

Similarity is an inherently application-dependent concept and we expect the application engineer to define it for specific applications. In many real-time applications, it is often acceptable to use an older value of a sensor as input to a calculation, instead of waiting for a more up-to-date value. This is possible because the physics of the application may be such that changes in sensor reading over a short interval of time are so small as to be insignificant to the calculation. This observation provides us with the needed connection between similarity and time constraints govern-ing data access.

Specifically, we assume that the application semantics allows us to derive a similarity bound for each data object such that two write events on the data object must be strongly similar if their time-stamps differ by an amount no greater than the similarity bound, i.e., all instances of write events on the same object that occur in any interval shorter than the similarity bound can be swapped in the (untimed) schedule without violating consistency requirements. No-tice that the existence of a similarity bound does not imply that the similarity relation is transitive since event swap-ping is based on (wall-clock) time values and not on the relative positions of events in a schedule.

5.1 Basic Idea

The basic idea is that transactions should not block one another as long as meeting time constraints guarantees the strong similarity of their conflicting events. The event conflicts are resolved by appealing to the similarity bound in the following discussion, which refers to Fig. 5.

Suppose two events e1 and e2 conflict with each other.

Let e1and e2be the write events w2and w3, respectively. If

their write values are similar under the similarity bound, as shown in Fig. 5, these two write events are strongly similar and it does not matter which write value is read by subsequent read events. Suppose e1and e2are, respectively,

the write event w2 and the read event r in Fig. 5. For their

relative ordering to be unimportant, there must exist an earlier write event whose write value is similar to the write value of w2under the similarity bound. If this is the case, as

is shown in Fig. 5, then it does not matter which write value

the read event r reads. The same argument applies to the case where e1 and e2 are a read event and a write event,

respectively.

5.2 A Sufficient Condition: Time Constraints vs. Data Similarity

Suppose sbi is a similarity bound for a data object xi. Any

two writes on xi within an interval shorter than sbi are

interchangeable because they are strongly similar. Let pmax i ,

pnxt

i , and pmini be the maximum, the second largest, and the

minimum periods of transactions updating xi, respectively.

If there is only one transaction updating xi, then pmaxi is

equal to pmin

i and pnxti . Suppose pri is the maximum period of

transactions reading xi. In the following, we shall derive a

sufficient condition which guarantees the ªstrong similar-ityº of any concurrently executing transaction instances.

For simplicity of discussion, we assume in this paper that the deadline of a transaction instance is equal to the end of its period. Extension of our results to relax this restriction will be discussed later.

Write vs. Write Condition: …pmax

i ‡ pnxti †  sbi. By our

definition of strong similarity, two conflicting write events are interchangeable if they are strongly similar. In other words, conflicting write events of any overlapping transac-tion instances are interchangeable if these write events are strongly similar. (We say that two transaction instances overlap if their execution overlap in time.) If no transaction misses its deadline, the maximum temporal distance between any two conflicting write events of overlapping transaction instances on data object xi is …pmaxi ‡ pnxti †.

Obviously, if …pmax

i ‡ pnxti †  sbi, conflicting write events of

any overlapping transaction instances are strongly similar and interchangeable (please see Fig. 6).

Notice that if the deadline of a transaction instance is before the end of its period, then the Write vs. Write condition can be modified as follows: Let dnxt

i be the

maximum (relative) deadline of transactions updating xi

(excluding transaction max

i ). The Write vs. Write condition

becomes …pmax

i ‡ dnxti †  sbi. Furthermore, the Write vs.

Fig. 5. Similarity of conflicting events.

Write condition for data object xican be ignored if there is

only one transaction updating xi. This is because no two

instances of the same transaction will overlap if the transaction never misses its deadline.

Read vs. Write Condition: …pmax

i ‡ 2pmini ‡ pri†  sbi.

Suppose  is a transaction with period pr

i and reads data

object xi. To ensure correctness, conflicting write events

which might be read by an instance of  must be strongly similar (thus interchangeable) so that any instance of  will not block or be blocked by transaction instances which may update xi.

If no transaction updating ximisses its deadline, then no

read event ercan read from a conflicting write event which

occurs more than 2pmin

i ago. Let this oldest write event be

called writeold _{of e}

r. For ease of argument, we assume

without loss of generality that the initial database state is determined by a fictitious set of write events so that an oldest write event always exists. On the other hand, a transaction instance which overlaps with the transaction instance issuing er may issue a conflicting write event

almost pmax

i later than the end of the period of the

transaction instance issuing er. Let this write event be

writeyoung _{of er. Obviously, this transaction instance of}

(which issues er) should not block or be blocked by any

transaction instance because of read-write access conflict on xi, assuming that the maximum temporal distance of

writeold _{and write}young _{of e}

r is no more than the similarity

bound sbiof xi. In order words, read-write access conflict of

xi can be resolved if …pmaxi ‡ 2pmini ‡ pri†  sbi (please see

Fig. 7).

Notice that if the deadline of a transaction instance is before the end of its period, then the Read vs. Write condition can be modified as follows: Let dmax

i be the

maximum (relative) deadline of transactions updating xi

and dr

i the maximum (relative) deadline of transactions

reading from xi. The Read vs. Write condition becomes

…dmax

i ‡ 2pmini ‡ dri†  sbi. When there is only one

transac-tion updating xi, then pmaxi ˆ pmini . (In the last case, further

optimization is possible.)

We claim that if a transaction set satisfies the Read vs. Write and Write vs. Write conditions, then these transactions can be scheduled independently as if they do not share data (with the usual assumption that individual read and write

events are atomic). Formal justification of this claim is stated in Theorem 5 below.

Theorem 5. If a transaction set satisfies both the Read vs. Write and Write vs. Write conditions, then any schedule that satisfies all transaction deadlines is view
-serializable. Proof. The proof follows directly from Theorem 2 if there

exists a serial schedule 0_{which is a derived schedule of}

any schedule  that satisfies all transaction deadlines. According to the definition of ªderived schedule,º  and 0 _{must satisfy the following two requirements: 1) All}

write events read by the same read event in  and 0

must be strongly similar in  and 2) the last write events on every data object in  and 0_{must be strongly similar}

in . In the following, we shall prove that there exists a sequence of event swaps from  to some serial schedule 0_{such that the requirements of a derived schedule are}

preserved at every step in the sequence.

Since any conflicting write events of overlapping transaction instances in  are strongly similar (according to the Write vs. Write condition), they can be swapped in any way without violating the second requirement of a derived schedule. Likewise, a conflicting read event and a conflicting write event of two overlapped executing transaction instances in  can be swapped in any way without violating the first requirement of a derived schedule because they are ªstrongly similarº according to the Read vs. Write condition. In particular, instances of all write events on the same data object that occur in any interval shorter than the similarity bound can be swapped in a (untimed) schedule without violating consistency requirements. Thus, swapping such write events will not violate the first requirement of a derived schedule. Therefore, conflicting events of overlapping transaction instances can be swapped in any order. Since nonconflicting events can also be swapped in any order, events of overlapping transaction instances can be swapped in any order. In other words, overlapping transaction instances can be serialized in any order. Also, transaction instances which are not overlapped in  are already serialized. Therefore,  can be serialized by swapping events of overlapping transaction instances in any order. tu 5.3 Extensions

Since different transactions may have different precision requirements for a data object, the Read vs. Write and Write vs. Write conditions can be weakened. Suppose sb0

i is the

similarity bound of a data object xi with respect to a

transaction 0_{. The Read vs. Write condition can be weakened}

to: …pmax

i ‡ 2pmini ‡ p0†  sb0iif the period of  is p0. The Write

vs. Write condition can be weakened to: …pmax

i ‡ pnxti †  sb0i.

Finally, we consider the situation where some transac-tions satisfy the Read vs. Write and Write vs. Write conditions, but others do not. In this case, the transaction system cannot be scheduled ªfullyº independently. A simple variation of Similarity Stack Protocol (SSP) [17] can be made to take care of this situation, as follows:

As in SSP, transactions are partitioned into interactive sets such that no two transactions in different interactive sets may share any data object. If all transactions in an