specification and execution of transactions for advanced database applications

fnformarion Systems Vol. 17, No. 2, PP. 171-183, 1992 0306-4379/92 $5.00 + 0.00 Printed in Great Britain. All rights reserved Copyright 0 1992 Pergamon Press Ltd

SPECIFICATION AND EXECUTION OF TRANSACTIONS FOR ADVANCED DATABASE APPLICATIONS

YUNGHO LEU, AHMED K. ELMAciARMIDt and NOUREDDINE BOUDRIGA~

Department of Computer Sciences, Purdue University, West Lafayette, IN 47907, U.S.A.

(Received 22 October 1990; in revised form 4 August 1991)

Abstract-Autonomous multidatabases, Computer Aided Design (CAD) databases, and Object Oriented Databases have requirements which traditional transactions cannot meet. Users of these advanced applications are more sophisticated than users envisioned for On Line Transaction Processing (OLTP) applications a few decades ago. The need to relax the properties of complex database transactions is urgent. Frameworks for flexible transaction systems are needed. This paper is a step towards this objective.

This paper addresses the formalization of a new transaction model called Flex transactions, along with execution control and analysis protocols. The algorithm is formalized through the use of Predicate Transition Nets (PTN) and reachability trees.

Key words: Multidatabases, transaction models, distributed databases, heterogeneous databases, flexible transaction management

1. INTRODUCTION

A transaction constitutes a unit of work in a database system. Systems that use transactions must guarantee the basic transaction properties, namely, atomicity, consistency, isolation and durability (also called the ACIDity properties). Most DBMSs strive to guarantee these properties through the use of concurrency, commitment and recovery algorithms. Transactions have been a successful technology to build meaningful and extensive applications over the last few decades.

With the wide spread use of DBMSs in advanced applications, the suitability of these transaction systems has come under question. It has lately been argued that while it is proper for the system to guarantee the ACIDity properties, it should be up to the application to decide which of these properties they need to be enforced and which they can trade for more flexibility or higher performance.

This paper presents an extended transaction model, called Flex& which relaxes two of the transaction properties, namely, atomicity and isolation. While the Flex model is studied in the context of the InterBase projecty, it is formulated and is intended for general use.

The extended model outlines the goal offlexible execution control. Three important notions of the extended model are: alternatives, dependencies (both external and internal) and compensatability. Usually, an application can be decomposed into a set of tasks. Function replication states that there might be more than one way to accomplish a specific task of the application. Therefore, we can compose a set of subtransactions to implement a specific task of the application. The set of subtransactions which implements the same task is said to bejhzctionafly equivalent [l]. Function replication renders more than one possible execution path for a single transaction. As a result, transaction execution in the extended model becomes resilient to failures in the sense that even if some subtransactions fail, the transaction may still be “successfully” executed (when one of the execution paths can be achieved). The execution of a transaction in the extended model is nondeterministic, i.e. the actual execution path depends on failures occurring during the transaction execution.

The notion of dependency is very important in the extended model. Two categories of dependencies, external-dependency and internal-dependency can be specified over the set of

tTo whom all correspondence should be addressed. SPresent address: University of Tunis, Faculty of Science, Tunisia. §Flex stands for flexible. BInterBase is a project in the Indiana Center for Database Systems that studies issues of transaction management and consistency in the multidatabase area. The InterBase prototype has been built and it currently includes Sybase, Ingres, Guru, Dbase IV and Oracle. In addition, it also integrates various other non-database packages.

171

172 YUNGH~ LEU et al.

subtransactions of a transaction. External-dependency specifies the dependency of the subtransaction execution over events or objects outside the transaction. For example, we can specify the dependency of subtransactions on time or cost functions. The external-dependency provides useful information for scheduling subtransaction execution in multidatabase systems. The extended model also allows users to specify internal-dependencies among subtransactions of the same transaction. The internal-dependencies explained in this paper are success-dependency and failure-dependency. Other useful internal-dependencies are commit-dependency and abort-dependency in Ref. [2].

Finally, a transaction in the extended model can have two types of subtransactions, compensatable and non-compensatable. This approach results in mixed transactions. The mixed transaction concept allows flexible control of the transaction isolation granularity. Those subtransactions which are non-compensatable must run in isolation of the rest of the system (i.e. maintaining isolation property), while the compensatable subtransactions can be committed once they are completed and, therefore, externalize their effects to other transactions before their composing transactions commit [3]. Through the proper specification of the types of subtransactions, we can control the isolation granularity of a transaction to be as large as a whole transaction (as in nested transactions [4]), or as small as a single subtransactions (as in Sagas [5]).

This paper is organized as follows. In Section 2, we present our extensions to the traditional transaction model. In Section 3, we present the extended transaction model. In Section 4, we formulate a mapping from a Flex transaction to Predicate Transition Nets which serves as a basis for execution control and analysis of Flex transactions. In Section 5, we present an execution control algorithm for Flex transactions. We also present a method for analyzing the correctness of the Flex transactions. In Section 6, we summarize this paper by comparing our work to other related work and outlining our on-going research.

2. EXTENDING TRANSACTION MODELS

In this section, we discuss the extensions to the traditional transaction model.

2.1. Alternatives

Multidatabase users frequently find themselves with functionally equivalent alternatives to reach their objectives. A powerful transaction model must allow the user to express the various choices by which his request can be implemented. The presence of alternate ways of achieving a particular objective represents a state of non-determinancy.

An example of these alternatives can be found in a travel agent scenario.

Example 1: Consider a travel agent (TA) information system [6]; a transaction in this system may consist

of the following tasks:

1. TA negotiates with airlines for flight tickets. 2. TA negotiates with car rental companies for car reservation. 3. TA negotiates with hotels to reserve rooms.

Let us assume, now, that for the purpose of this travel, two airline companies (Northwest and United), one car rental company (Hertz) and three hotels (Hilton, Sheraton and Ramada) can be involved in this trip. The travel agent can implement these tasks as

1. Order-a-ticket from either Northwest or United airlines. 2. Rent-a-car from Hertz. 3. Reserve-a-room in any one of the three hotels.

These three tasks can be implemented respectively by three sets of functionally equivalent subtransactions: {t,, t2}, {f3} and {f4, t,, fs}, where the tis are defined as follows:

t,-Order a ticket at Northwest Airlines; t,--Order a ticket at United Airlines; +-Rent a car at Hertz;

Transactions for advanced database applications 173

t,--Reserve a room at Hilton; &--Reserve a room at Sheraton; &---Reserve a room at Ramada.

In the above example, we use the term task to name the specific function that we want to perform. For example, buying a ticket is a task. In Example 1, t, and t, are two functionally equivalent subtransactions for the order-a-ticket task. We say that a task is performed successfully if one of its functionally equivalent subtransactions executes successfully. A transaction is said to be successful if all its tasks are successfully performed.

2.2. Dependencies

Let us consider a set T of subtransactions, say T = {t, , t,, . . . , tn}. The execution of a subtransaction ti can depend on the failure or the success of the execution of another subtransaction. Furthermore, this execution can be dependent on some external parameters (such as time). More precisely, we define:

Success-dependency: A subtransaction ti is success-dependent on subtransaction ti if ti can be executed only after t, is successfully executed. Failure-dependency: A subtransaction t, is failure-dependent on subtransaction t, if t, can be executed only after t, is executed and failed. External-dependency: Let X be a set of parameters (X is disjoint from T). A subtransaction ti is external-dependent on X if the execution of t, is dependent on the truth of a predicate on X.

In the previous example, replace t,, t5 and t6 respectively by subtransactions t;, t; and t; which are defined as follows:

t; Order a ticket at United Airlines, if t, fails; t; Reserve a room at Sheraton, between 8a.m. and 5p.m.; t: Reserve a room at Ramada, if t, succeeds.

One can see that, in the set T = {t t’ t t t’ t’} t; is failure-dependent on t,, t; is I, 25 39 49 57 6 3

time-dependent and t;l is success-dependent on t, . Another example of external-dependency is given by subtransactions that have values associated

with them. These values can be cost or time related.

2.3. CompensatibilitJ

The traditional transaction concept is good only for short transactions. It has been shown by Gray [6] that problems arise when strict isolation in long-lived applications is enforced.

Therefore, the isolation granularity of the global transaction should be reduced. In Ref. [6], Gray proposed to associate with each subtransaction a compensating subtransaction which can semantically “undo” the effects of a committed subtransaction, if required. In Ref. [5], Garcia-Molina et al. proposed to model a long-lived transaction by a set of relatively independent subtransactions called saga. A subtransaction of a saga can commit and therefore releases the partial results of the saga before the saga commit. By doing so, the isolation granularity of a saga is reduced to the subtransaction level instead of the global transaction level. While the notion of sagas is useful, not all subtransactions in the real world can be compensated. For example, a subtransaction that fires a missile or a subtransaction that cashes a check are typically non-compensatable.

To address the fact that some of the subtransactions are compensatable and some are not, we introduce the concept of typed transactions. A global transaction is typed if some of its subtransactions are compensatable and some are not. In a typed transaction, the subtransactions which are compensatable are allowed to commit before the global transaction commits, while the commitment of the non-compensatable subtransactions must wait for a global decision. When a decision is to abort a typed transaction, the subtransactions which is in progress and the non-compensatable subtransactions which is waiting for a global decision are aborted, while the committed compensatable subtransactions must be compensated. In this sense, typed transactions are different from sagas [5] which allow only compensatable subtransactions.

174 YUNGliO LEU et at.

Hence, typed transactions fill the spectrum from sagas (assuming the compensability of all subtransactions) to traditional distributed transactions (assuming that subtransactions are non compensatable). Typed transactions are more flexible because they allow compensatable and non-compensatable subtransactions to coexist within a single global transaction.

3. FORMAL MODEL

3.1. Form of Flex transactions

In order to capture the notion of compensatability of subtransactions, we use the concept of type: a subtransaction is said to be of type C, if it is compensatable, it is of type NC, if it is non-compensatable.

A Flex transaction model is formally defined as follows:

Definition 1. A Flex transaction T is a 5-tuple (B,S,F,lT,F) where

l B=(t&,.. . , t,> is a set of typed subtransactions called the domain of T l S is a partial order on B called success-dependency l F is a partial order on B called failure-dependency a IT is a set of external predicates on B l f is an n-ary boolean function defined on the set ( 1, 0} and is called the acceptibility

function of T

In the above definition, (t,, tj) E S (denoted by ti i stj) if tj develops a success dependency on ti. Similarly, (ti, tj) E F (denoted by ti < Ftj) if tj develops a failure-dependency on ti. We illustrate the above definition through the use of the example of travel agents transaction introduced in the previous section.

Example 2: Consider the travel agent transaction introduced in Example 1. In addition, we assume the

following: (1) the ticket ordering subtransactions are non-compensatable; (2) ticket ordering subtransactions must run within business hours from 8 a.m. to 5 p.m. and t2 will be executed only after t, is executed and failed (3) the rent-a-car subtransaction must be executed after the order-a-ticket subtransaction, and the reverse-a-room subtransaction has a budget limit of $100; (4) the transaction is successful, if ordering-ticket, rent-a-car and reserve-a-room are successful. We propose the following Flex transaction to formalize the travel agent transaction.

B = {t, (NC), UNC), [j(C), fd(C), UC), UC)}

S={t,<f&Z<SfJ

F={t,-Gt,)

n = {P, Q} where P and Q are two predicates defined by

P = (8 < time(t,) < 17, 8 < time(t,) < 17)

Q = {cost(t,) < $100, cost(t,) < $100, cost(t,) < $100)

f(x,,x2,x3,xq,xg,xg)=(x,hxjAxq)V

(xIAxX3hx~)V

(x,“xj”xb)V

(xz”xj”x~q)”

(xzAx3”xg)”

(xz”xj”xs)


3.2. Execution states

Definition 2. For a Flex transaction T with m subtransactions, the transaction execution state x is an m-tuple (x, , x2, . . . , x,,,) where

N tf subtransaction ti has not been submitted for execution;

E xi =

(

if ti is currently being executed; S tf t, has successfully completed; F if ti has failed or completed without

achieving its objective;

While “successfully completed” for a compensatable subtransaction means that the subtransaction is committed, “successfully completed” for non-compensatable subtransaction means that the subtransaction is in a prepared state [7]. The execution state is used to keep track of the state of execution of a Flex transaction. The acceptability function appears as a partial function defined on the set of execution states. It is computable whenever all xis occurring in its expression are equal to either S or F. Hence, the acceptability function reflects the acceptability of an execution state. Thus, the following definition

Definition 3. Let T be a Flex transaction and X be the set of its execution states. The acceptable state set, A, of the Flex transaction is the subset

A ={xEX]f(x)= 1)

In Example 2, the set of acceptable states is defined by

A ={(S,-AS,-_,-_)}u

{(S, -9 S, -9 S, -)>u

{(S, -1 S, -9 -9 S)>u

((7 S, S, -, S, -)>u

((-9 S, S, S, -9 -C-J

((7 S, S, -5 -5 S))

Definition 4. Let T be a Flex transaction and x be an execution state of T. T succeeds if x is an acceptable state.

3.3. Execution of Flex transaction

Let T = (B, S, F, IL, f) be a Flex transaction and ti be an element in B. We use the notation Sdep(t,) (resp. Fdep(ti)) to denote the subset of B which is constituted by all elements t of B such that ti is success-dependent (resp. failure-dependent) on t. On the basis of failure-dependencies, we partition the subtransactions in Sdep(t,) into groups. tj and tk(tj, tk E Sdep(ti)) are in the same group, if tj< & or tk-Cftj. Semantically, the subtransactions in the same group are functionally equivalent. We use the notation ES(ti) = {E, , . . . , Ek > (assuming there are k groups) to denote the set of the groups for ti. Each Ei in ES(ti) represents a task that ti success-dependent on (i.e. Ei has to be succeeded before ti can be started). Let x = (x1, x2, . . . , x,,) be an execution state of Flex transaction T. We say that subtransaction ti is executable at state x, if the following four assertions are satisfied.

1. xi= N; 2. For each group E, E ES(t,), 3 a subtransaction t, E Ej such that x1 = S; 3. For all j such that t, E F dep(t,), x1 = F; 4. For each external predicate P, P(t,) is true.

176 ~UNCHO LEU t?l al.

In other words, condition (I) states that subtransaction ti has not been executed yet. Condition (2) states that for each task ,!$ that ti is success-dependent, one of the subtransaction of the set of subtransactions that implement Ej must succeed. Condition (3) states that all the subtransactions that ti failure-dependent must be executed and failed. Condition (4) states that all the external predicates defined for ti must be satisfied.

We can now formulate the execution rules of a Flex transaction as follows:

procedure Exec-Flex-transaction(in:T, out:R) beginl. initialize x:=(N, N, . . . , N), R:=O and

compute the set EXEC of all executable subtransactions; 2. while R = @ and EXEC # @

execute concurrently all elements of EXEC, put the response in x (xi = the execution state of ti) and compute f(x), tff(x) = 1 then R = {x};

3. tf R # @ then commit the Flex transaction else abort the Flex transaction.

end

According to the above execution rules, concurrent execution of subtransactions is allowed if they are executable at the same time. When the result of the execution is known, we modify the execution state accordingly. After the completion of a subtransaction, we check whether or not an acceptable state has been reduced. If an acceptable state has been reached, we commit the Flex transaction. When a Flex transaction terminates without reaching an acceptable state (i.e. EXEC = 8) then we abort the Flex transaction.

4. REPRESENTING FLEX TRANSACTION BY PREDICATE TRANSITION NETS

After the definition of the Flex transaction model, one has to implement this model. Such an implementation must provide control and analysis tools, and has to support the properties of Flex transaction (such as alternative, compensability and dependency). In the sequel, we will present a Flex transaction execution control algorithm which is based on the Predicate Transition Nets (PTNs) introduced in Ref. [8]. Another execution control algorithm which uses logic can be found in Ref. [9]. This section presents an approach of mapping a Flex transaction into a Predicate Transition Net. The Predicate Transition Nets based execution control algorithm and analysis scheme will be presented in the next section. We begin this section by presenting the Predicate Transition Nets, and then construct a mapping from Flex transactions to PTNs.

4. I. On predicate transition nets

We simplify the definition of the Predicate Transition Nets as follows. A predicate transition net consists of

1. a bipartite graph G = (H,K,L) where H and K are called places and transitions respectively, and L is a set of directed arcs, each connecting a place p E H to a transition tr E K, or vice versa. A place is represented by a circle while a transaction is represented by a bar. For each transition tri, a place that has edges directed into tri is called an input place of tri, and a place that tr, has edges directed to it is called the output places of tri. A place can hold tokens. A token in a place is represented by a dot in the corresponding circle.

2. A mapping X- of the set of transitions into the set of formulae of the first order logic; and

3. A marking M,, of the places: it is a mapping that assigns to each place h in H a set of tokens.

To clarify this definition, we introduce the following example.


h 1 -

%

h 2

kl k2

h 3

h 4 z!

Fig. 1. A predicate transition net.

k3

Example 3: Figure 1 represents the Predicate Transition Nets (H, K, L, X, MO) given by

~={~,,~,A~,} K= {k,kk} L = {(h,, k,), (b, k,), (4, h), 06, M, (k,, h,), Oh, 0) 3”:

k, ‘(8 < k, + (8 < k? + true

M,: h, -+ . h2+.

time(k,) < 17) time(k,) < 17) A (x, = F)

Where l is a given symbol.

4.2. Mapping

Let T = (B,

the Flex transaction

S, F, lI,f) be a given Flex transaction, we define the associated Predicate Transition Nets PTN(T) = (H, K, L, X, MO) as follows:

If B is the set {t, , t,, . . . , t,}, then:

K = B (i.e. assign each subtransaction ti E B to a unique transition, also named t,, in K)

.%(tJ = ( Ik E F&(,,) (xk = F, )+,4(1J) MO: assign l to the input place of each tk such that S dep(t,) = 0

- ... H and L can be constructed by the following rules:

1.

2.

for each subtransaction ti such that Sdep(ti) = 0, create and connect an input place to transition ti. for each ti such that S dep(t,) # 8, calculate ES(ti); assuming that ES(&) = {E,, . . . , E,}, connect each tk E S dep(ti) to ti as in Fig. 2. Note that in Fig. 2, t, and t2 belong to the same group (E,) and so on.

3. after rule (1) and (2) have been applied for all transitions, connect those transitions which do not have an output place to an output place (by creating a new place).

In the above mapping, X associates with each transition ti a set of predicates, which includes the failure-dependency predicates (xk = F) for any tk in Fdep(ti) and the external predicates q(ti) for any q E Il.

178 YUNGHO LEu et al.

‘k

Fig. 2. Rule for connecting transitions.

Example 4 Consider the travel agent transaction defined in Example 2, the associated Predicate Transition

Net is represented in Fig. 3. At this point, we should mention that our mapping approach produces a subclass of PTNs,

namely, Petri Nets without conflicting transitions?, because each place in the produced Petri Net has at most one output transition. Because of this fact, firing a transition will not disable other enabled transitions. This notion is important for the execution control algorithm presented in the next section.

5. EXECUTION AND ANALYSIS

In this section, we present an algorithm for the execution control of Flex transactions using their Predicate Transition Net representation. We then give a method for performing the analysis of Flex transactions.

5.1. Execution control of Flex transactions

After the definition of mapping, we are ready to present the execution control algorithm. A PTN models the execution of a Flex transaction by firing transitions in accordance with the conditions specified by the predicates associated with each transition. We define a transition to be enabled, if all of its input places contain at least one token. We then define a transition to be executablet, if it is enabled and all its associated predicates are true. Finally, we define a transition to befit-able, if it is executable and its associated subtransaction has been successfully executed. In marking M, we call the set of all enabled transitions the enabled set. Similarly, we call the set of all executable

a4

t4

b4

. s .

0 h -5 0 b6 0

a . 1 &

. %

a2

t1 t2

a 3

t3

b3 6

Fig. 3. F’TN for the travel agent transaction.

tWe say that two transitions are conflicting if firing one transition will disable the other transition [IO]. $This implies that its associated subtransaction is executable.


transitions the executable set. We attempt to fire a transition by submitting its corresponding subtransaction for execution. If the execution is successful, then we fire the transition; otherwise, we update the corresponding execution state variable. More specifically, when transition tri is fired, the following actions are performed:

l Update the execution state variable xi by setting it to S; and l calculate the new marking by taking one token from each of the input places of transition

tri, and putting one token into each of tri’s output places.

The procedure evaluate_PTN shown in Fig. 4 implements the procedure Exec-Flex-Transaction defined in Section 2,

In procedure eva~uate_PTN, B is the current enabled set; %! is the current executable set derived from 8; and % is the scheduled set that contains the transitions corresponding to the submitted

procedure eualuate_PTN(PTN, f, R) /* PTN is a Predicate Transition Net, f is a acceptability function and R is the output*/

begin

repeat

z + (N,N,N, ---, A’) /’ no subtransactions has been executed */

E + 4; /* E - enabled set */

u + 4; /* U - executable set */

B + 4; /* B - scheduled set */

Q + ev% /* Q - response queue */ compute_enabledset E from PTN; compute_executable~t Zi from the new enabled set E;

/* Let tTi denote both a transition and a subtransaction */ For each transition tri E Gt do

begin submit subtransaction tri to its corresponding local database system;

8 - G u { tri}; 2; c E /* E for executing state */

end; on receiving response enqueue response in Q; /* an exception handling routine */ urhile (Q = empty) do

begin if {U = 0) then

begin flex-abort; exit

end end;

RESP+ dequeue(Q); ,/* assume that RESP is from tti *f

then begin

27; 4-” s; fire(tri); compute-enabled-set &

end else

xi + F endif compute_executable~et U;

until ( (x) = 1); flex_commit; R = 2;

end, Fig. 4. The execution control algorithm.

IS 1712-E

180 YUNGHO LEU et a/.

subtransactions. The algorithm starts from the initial execution state (with all state variables initialized to N), computes the enabled set 8, calculated 4% from 6, and submits all subtransactions whose corresponding transitions are in 93.

Whenever a subtransaction completes, a new executable set 4% is determined by the algorithm. The set 4! is partitioned into two sets, ‘3 and 9 +. The executable transitions which are not yet submitted are contained in 9+, while transitions in 9 are the transitions that are already submitted.

To prevent the loss of responses from the local database systems, the responses are first buffered in queue Q. Whenever Q is not empty, the algorithm gets the first response of Q (by calling a dequeue procedure) and computes the new execution state, fires the corresponding transition if the dequeueing response is an “YES” (meaning that the corresponding subtransaction has been executed successfully), and computes the executable set 43.

The scheduling activity continues until either an acceptable state has been reached (f(x) = 1) or no subtransa~tion is executable (i.e. 0 = 0) and Q is empty. When the execution terminates, if the final execution state x is acceptable, the Flex transaction is committed; otherwise, it is aborted.

To cornmitt a Flex transaction, for each non-compensatable subtransaction ti such that xi = S and that xi = S is required to satisfy f(x) = 1 (otherwise, it is not needed for this specific execution), sends (by the coordinator of the commit protocol [ 1 I]) a “COMMIT” message to its local database system; otherwise, sends an “ABORT” message to its local database system. For each compensatable subtransaction ti such that xi = S, and is not needed for the specific execution, issuing its compensating transaction. Then, abort any subtransactionS in 3 (containing subtransactions which are executing or subtransactions which finish execution but remains in Q).

To abort a Flex transaction, each subtransaction ti which belongs to 9, or whose corresponding execution state variable xi = S, has to be aborted, or compensated depending on its type.

5.2. Analysis of Flex transactions

Before a Flex transaction is actually executed, we have to verify that the transaction will behave exactly as desired. We are especially interested in the following two aspects:

pl. Can each acceptable state be reached from the initial execution state? p2. Which acceptable states can be reached when some specific failures occur?

To analyze these aspects of Flex transactions, we use the well known techniques of Petri Nets reachability. The reachability problem is perhaps the most basic Petri Nets analysis problem. Deadlock and failure can be stated in term of the reachability problem.

In this section, we present the notion of reachability of an execution state in our Flex transaction model and show how to capture it when analyzing the associated Predicate Transition Net. For this purpose, we assume that we are given a Flex transaction T and its predicate transition net. By pattern of failure x, we mean a state (x, , x2, . . . , x,) where xi is S if we assume that ti successfully executes, and F otherwise. For the sake of simplicity, we assume that the places of a PTN are ordered as (a,, a2, . . . , a,). A marking of a PTN is a repre~ntation of the dist~bution of tokens in the places of the PTN. We denote a marking by (p, , ,u2, . . . , p,J where pi is the number of tokens in place ai. Firing a transition consists of deleting a token from each of its input places and adding one token to each of its output places.

We assume in the following that a pattern of failure is fixed. The reachability tree Rt under the pattern of failure x is given as follows.

-Root of Rt is the initial marking of the associated PTN. -A node, in Rt, is obtained from the initial marking by firing a sequence of transitions. -An arc in Rt links a marking p to marking p’ if p is obtained from ,u by firing a transition

in PTN.

tube commit protocol for the Flex transaction can be found in Ref. fl I]. $If the subtransaction has been committed (it is compensatable), then it is absorbed by compensation.


Mo-<

(1, 0, 1, 1, 1, 1, 0,070, 0)

/ t3

(1, o,o, 1, 1,1, 1, 0, 0, 0)

/

t4

(1, 0, 0, 0, 1, 1, 1, 1, 0, 0) Y= (F, S, S, S, N, N) Fig. 5. A reachable acceptable state.

Definition 5. A reachable acceptable state y, under pattern of failure x, is an execution state such that f(y) = 1 and there is a sequence of transitions leading to it.

To illustrate the notion of reachability, we consider the travel agent transaction formalized in Example 4.

Example 5 Consider the PTN in Example 4. We show, in Fig. 4, the reachability tree of the PTN with the

pattern of failures (F,S,S,S,S,S) (i.e. t, will fail when it is executed). As shown in Fig. 5, the state (F,S,S,S,N,N) can be reached by the ordered execution of t,, t, , t4. Note that we order the marking

in Fig. 4 by (a,,a,,a,,a,,a,,a,,b,,b,,b,,b,). In performing the reachability tree analysis, we ignore the external-dependency and fix the

failure-dependency through the use of the pattern of failures. This analysis allows us to predict the behavior of a Flex transaction according to its specification, which may be useful when designing a complex Flex transaction.

6. CONCLUSIONS

6.1. Related work

Several extensions to the initial transaction concept have recently been proposed. One significant extension is the nested transactions [4]. A nested transaction allows a transaction to be dynamically decomposed into a tree of subtransactions and ensures the transaction properties for individual subtransactions. The capability of decomposing a transaction into subtransactions, providing synchronized concurrent execution of subtransactions and encapsulating failures in the subtransactions makes the nested transactions suitable for composing transactions in distributed computing environments. However, the atomicity and isolation properties are still the same as in the classical transaction model.

Many extensions to the classical transaction model have been focused on solving the problem of long-lived transactions. Long-lived transactions impose a formidable challenge to the traditional transaction technology. A long-lived transaction may hold on many system resources for a long time. If a short transaction needs some of these resources, it will end up waiting, may be for hours or days, for the long-lived transaction to commit. Moreover, a long-lived transaction may also cause deadlocks easily. According to Ref. [6], the probability of deadlock increases with the fourth power of transaction size.

Garcia-Molina and Salem proposed to model a long-lived transactions as a saga [5]. As mentioned earlier, a saga consists of a sequence of relatively dependent subtransactions which can commit before their composing saga commits. Sagas relieve the problems of long-lived transactions by early externalize their partial results to other concurrent transactions. Pu et al. proposed a

182 YUNGHO LEU et d.

transaction model [12] to support open-ended activities which are characterized by uncertain duration (long-lived), unpredictable developments and interaction among concurrent activities. The main idea in Ref. [12] is to allow an ongoing transaction to split into two transactions, one commits and the other one will continue. Splitting a transaction allows the ongoing transaction to release the complete part of its results to other concurrent transactions and, therefore, alleviates the problems caused by the longlived transactions. Walter proposed a refinement [13] on the nested transaction model by allowing the subtransactions of a nested transaction to form groups of commitment and group of abort. Subtransactions belong to the same commit group have to commit together (without waiting for subtransactions in other group). Similarly, subtransactions belong to the same abort have to abort together. This refinement allows a nested transaction to commit or to abort its subtransactions in several groups, which effectively reduces the isolation granularity of nested transaction and localize the effects of failures on the nested transaction. Our Flex model is related to the multiple commit points approach in the sense that they both reduce the isolation granularity. However, Flex model uses the compensation t~hnique while the multiple commit points approach does not.

Several transaction models have been proposed to support the cooperation of a group of people who work on the same project. One of the limitations of the traditional transaction model when applied in cooperative environments is the requirement of serializability. Serializability severely restricts the users to cooperate with each other. Ellis and Gibbs proposed the groupware systems to support a group of users to work in a tightly coupled fashion. In groupware, consistency is achieved by a notion called distributed operation trunsforamtion which does not require serializability, Nodine and Zdonik also proposed a model called cooperative transaction hierarchies to support cooperative activities. Their model allows the user to define application-specific correctness conditions for the synchronization of concurrent transactions. Serializability is, therefore, not required in their model.

Perhaps, the works which are more related to our work are ConTracts 1143 and ACTA [2]. In Ref. [ 151, a non-standard applications such as office automation, CAD, manufacturing control etc. was modeled by a ConTract. A ConTract is an execution unit which consists of a set of sequential programs, called steps, each of which implements a well-defined task of the corresponding application. The goal of ConTracts is to support reliable execution for a non-standard application even though each step of the application may not be reliable (i.e. may fail). To achieve this goal, Reuter and Wachter proposed a method which makes the execution of a ConTract firward- recoverable [4]. Other features of ConTracts include (1) supporting compensating actions; (2) using explicitly stated predicates for concurrency control and (3) supporting flexible conflicts resolution. Flex transactions are similar to ConTracts in the sense that they are both resilient to failures. However, Flex transactions are resilient to failure by supporting alternatives and by capturing failure-dependen~ies~ among subtransactions so that a transaction can have more than one acceptable way of execution. In Ref. [2], Chrysanthis and Ramamritham proposed a framework called ACTA for analyzing the existing transaction models. In ACTA, transactions are analyzed by their effects on each other and their effects on data objects. Flex model is similar to ACTA in the sense that they both allow specification of dependencies between subtransactions (or transactions). However, dependencies in ACTA are used to analyze transactions’ behavior while dependencies in Flex model are used to support transaction execution control.

6.2. Summary

In this paper, an extension to the traditional transactions is described and formalized. Flex transactions are described in the context of autonomous multidatabase systems. The Flex transaction model contains features which are especially useful for coping with problems caused by autonomy. A Flex transaction has alternate ways of committing. The exte~al-de~ndencies associates with subtransactions make the scheduling of Flex transactions more convenient. The Flex transaction model also supports the mixing of compensatable and noncompensatable subtransactions, thereby, reducing isolation granularity. The rationale for several of these extensions are described in the paper, and several algorithms for controlling its execution has been proposed.

tThe notions of alternatives and failure-dependencies can be traced to Ref, fl6].


The InterBase prototype is currently being extended to support Flex transactions. We are also studying transaction management routines to support these new transactions in the context of both serializability [17] and quasi serializability [18]. Various other extensions are also now underway. Among others, we are working on using the logic programming paradigm to specify Flex transactions [9, 191 and extending the notion of durability property of transactions.

Acknowledgements-This research is sponsored by the Indiana Corporation for Science and Technology (CST), a PYI Award from NSF under grant IRI-8857952. nrants from the AT&T Foundation. Bellcore. Tekbronix. SERC. Mobil Oil and Bell Northern Research.

111

PI

131

[41

PI 161

[71

PI [91

PO1 1111

WI

[I31

P41 t151

1161

[I71

1181

[I91

M. Rusinkiewicz, A. Elmagarmid, Y. Leu and W. Litwin. Extending the transaction model to capture more meaning. ACM SIGMOD RECORD 19(l) (1990). P. K. Chyrsanthis and K. Ramamtitham. Acta: A framework for specifying and reasoning about transaction structure and behavior. In Proc. ACM-SIGMOD Int. Conf on Management of Data, pp. 194-203 (1990). A. Elmagarmid, Y. Leu, W. Litwin and M. Rusinkiewicz. A multidatabase transaction model for interbase. In 16th Int. Conf. on Very large Data Bases (1990). J. E. Moss. Nested transactions: an approach to reliable distributed computing, Ph.D thesis, Dept. of Electrical Engineering and Computer Science, MIT (1981). H. Garcia-Molina and K. Salem, Sagas. In Proc. ACM Co@ on Management of Data, pp. 249-259 (1987). J. Gray. The transaction concepts: Virtues and limitations. In 7th Int. Conf: on Very Large Data Bases, pp. 144-154 (1981). J. Gray. Notes on database operating systems. In Lecture Notes in Computer Science-Operating Systems: An Advanced Course, pp. 624633. Springer, Berlin (1978). H. J. Genrich and K. Lautenbach. System modeling with high level petri nets. Theor Comp. Sci. 13, 109-136 (1981). E. Kuhn, A. K. Elmagarmid, Y. Leu and N. Boudriga. A parallel logic language for transaction specification in multidatabase systems. Technical Report CSD-TR-1031, Purdue University (1990). J. L. Peterson. Petri Net Theory and the Modeling of Systems. Prentice-Hall, Englewood Cliffs, N.J. (1981). Y. Leu. Flexible transaction management in the InterBase Project. Ph.D thesis, Department of Computer Science, Purdue University (1991). C. Pu, G. Kaiser and N. Hutchinson. Split-transactions for open-ended activilities. In 14th Inr. Conf on Very Large Data Bases (1988). Bernd Walter. Nested transactions with multiple commit points: an approach to the structuring of advanced database applications. In 10th Int. Conf. on Very Large Data Bases, pp. 161-171 (1984). A. Reuter and H. Wachter. The contract model. IEEE Data Engng Bull. (1991). A. Reuter. Contract: A means for extending control beyond transaction boundaries. In Proc. 2hd. International Workshop on High Performance Transaction Systems (1989). Y. Leu, A. Elmagarmid and M. Rusinkiewicz. An extended transaction model for multidatabase systems. Technical Report CSD-TR-925, Department of Computer Science, Purdue University (1989). Y. Leu and A. Elmagarmid. A hierarchical approach to concurrency control for multidatabases. In Second Int. Symp. on Databases in Parallel and Distributed Systems (1990). W. Du and A. Elmagarmid. Quasi serializability: a correctness criterion for global concurrency control in interbase. In 15th Int. Conf on Very Large Data Bases, Amsterdam, The Netherlands (1989). Y. Leu, N. Boudriga, A. K. Elmagarmid and E. Kuhn. Logic framework for the specification of complex transactions (1992). In press.

I

REFERENCES

specification and execution of transactions for advanced database applications

Documents