TANGO: A notation for describing advanced

TANGO: A notation for describing advanced transaction models Sergio Bandinelli, Stefano Ceri, Miguel Felder CEFRIEL { Politecnico di Milano

GOODSTEP ESPRIT-III pro ject No. 6115

GOODSTEP Technical Report No. 019 March, 1994

Abstract

The classical transaction model, that guarantees atomicity, consistency, isolation, and durability of transactions, has proved to be very useful in the development of traditional database applications. However, these properties are not adequate for modeling non traditional applications, such as software engineering, CAD, oce automation, and cooperative work. New transaction models have been proposed in order to capture the semantics of non traditional database applications. This work brie y surveys these extensions to the traditional transaction model and proposes a formal notation, called TANGO, that may be used to describe existing models and, in general, to design non-traditional database applications, involving complex dependencies among transactions. TANGO is based on a high-level Petri net formalism, and includes a modularization construct that permits to structure a TANGO speci cation in work units.

TANGO: A notation for describing advanced transaction models Sergio Bandinelli, Stefano Ceri and Miguel Felder Dipartimento di Elettronica e Informazione Politecnico di Milano Piazza Leonardo da Vinci, 32 20133 Milano (Italy) e-mail: fbandinel, ceri, [email protected]

Abstract

The classical transaction model, that guarantees atomicity, consistency, isolation, and durability of transactions, has proved to be very useful in the development of traditional database applications. However, these properties are not adequate for modeling non traditional applications, such as software engineering, CAD, oce automation, and cooperative work. New transaction models have been proposed in order to capture the semantics of non traditional database applications. This work brie y surveys these extensions to the traditional transaction model and proposes a formal notation, called TANGO, that may be used to describe existing models and, in general, to design non-traditional database applications, involving complex dependencies among transactions. TANGO is based on a high-level Petri net formalism, and includes a modularization construct that permits to structure a TANGO speci cation in work units.

1 Introduction The ACID transaction model showed to be very eective in the development of traditional transactional applications. But it is no more adequate for advanced database applications, such as oce automation, cooperative work, CAD and software engineering environments in which transactions are long, cooperative, and require user interaction. In these cases, it is not acceptable to follow the traditional mechanisms to guarantee the ACID properties of a transaction (e.g., lock all the resources during the whole transaction life). Much research is being conducted in the database eld, drawing considerable interest in new models for transaction mangement. Current research work can be grouped in two broad areas. One approach is to propose new transaction paradigms that serve speci c application needs; among many others, we mention 1

in this category the works on Multi-Level Transactions [3], Sagas [10], Nested Transactions [16] and Split Transactions [13]. The second group focuses on providing a general framework for the speci cation of transaction mechanisms and the environment for their execution, thereby oering transaction modeling features instead of speci c paradigms. In this category we include Contracts [19] and ACTA [5]. The work presented in this paper may be classi ed in this latter area: we present a formal and easy to use notation for modeling and analyzing advanced transactions. The notation is called TANGO1 and is based on the Petri net formalism. TANGO speci cations have thus a graphical representation that improves its readability by application designers. In addition it includes a simple modularization mechanism to hierarchically structure transaction descriptions. A TANGO speci cation captures the signi cant events that concern a transaction and shows the inter-relationships among these events. A transaction may be decomposed into several work units; a work unit consists of a set of logically related events, hiding internal events and showing only the starting and ending events of the transaction, and some intermediate events with which other transactions may synchronize. The components of a TANGO description correspond to a state machine: it is possible to identify the transaction states and what are the events that may cause the transaction to transit from one state to another. This scenario is adequate to represent a situation in which the dependencies among events are static and may be xed at speci cation time. For example, suppose that in a software development environment we want to model the transaction Code, that represents the coding of a program module. Within this transaction we may identify the events finish file editing and compile file. Here we may establish a static dependency stating that the event compile file come always after the event finish file editing for that le. This kind of dependencies may be modeled adequately with Petri nets. However, sometimes transaction dependencies are not established statically, since they may depend on dynamic conditions. For example, let us take again the example of the development environment. Suppose that in addition to the Code transaction we have a Design transaction, as a result of which a module design document is produced. Let us suppose that the coding of a program module may start even if the design has not yet been completed, on the basis of preliminary results of the design. Assume that transaction Code starts for a particular module whose design has not yet been nished, then if the Design transaction aborts, also the Code transaction should abort. This is a dynamic dependency that is only veri ed if Code starts before Design nishes. To capture this kind of dependencies in TANGO we have extended Petri nets by incorporating a signal mechanism capable 1 Tango is a popular dance in region of the \Rio de la Plata", in which the partners stand very close to each other and have to precisely synchronize their movements. Transactions happen to be as inter-dependent as two tango dancers.

2

of modifying the behavior of the system, depending on run-time conditions. In TANGO there is no built-in notion of transaction correctness (such as serializability). We believe that the correctness of an advanced transaction mainly depends on the application being modeled, an thus it is impossible to give a general prede ned correctness criteria. We envisage two ways of facilitating the modelers' task when describing advanced transactional applications. On one hand, already de ned transaction models may be integrated in a library of prede ned models and used whenever a transaction model ts in the application requirements. On the other hand, validation techniques may be used on TANGO speci cations to test whether the speci cation matches (imprecise) user requirements. To this end, many of the well known techniques already developed for Petri nets may also be used for validating TANGO speci cations. The remainder of this paper is organized as follows. In Section 2 we introduce the formalism and a general example is shown in Section 3. The purpose of this paper is to present TANGO modeling features and show it \at work" in modeling existing transaction models; therefore, Section 4 reviews all the transaction dependencies identi ed in ACTA, and Section 5 illustrates how existing transaction mechanisms can be modeled using TANGO. Section 6 outlines some of the validation techniques that can be supported by TANGO, subject for further investigation. Section 7 relates TANGO with other works in the literature. Finally, Section 8 draws some conclusions and points out future research.

2 TANGO de nition

2.1 Primitive constructs of TANGO

The mechanisms proposed in TANGO aim at providing a way to precisely specify complex advanced transactions. In doing so, we are not interested in specifying all the algorithmic details of an application. Instead, we abstract from these details and concentrate only on control ow and dependencies among transactions. TANGO views transactions2 as state machines that change state due to the occurrence of events. The occurrence of an event requires certain conditions to hold. When an event occurs, some conditions may cease to hold and others may become true. In addition, event occurrence may produce signals, which, in turn, cause (or force) the occurrence of other events. TANGO speci cations are structured in work units. Each work unit (WU) models a logically related unit of work that represents a transaction. A work unit de nition describes its control ow and provides it with a precise failure semantics. WUs may include internal parallelism and their de nitions may be nested. The concept of WU is similar to that of We will use the word \transaction" to denote general transactional applications, including non traditional transaction models. When referring to the traditional transaction model, we will write \ACID transaction". 2

3

activities presented in [2], where it is used for process modeling purposes. TANGO is based on a high-level Petri net formalism, which makes TANGO speci cations easier to read and provides the grounds for a precise de nition of its semantics. Each WU is described by a Petri net. The transitions of the net represent events and places represent conditions. The presence of a token in a place indicates that the associated condition holds. If the place is empty, it means that, for that state, the condition is not true. When all the input places of a transition are marked (each of them contains a token), we say that the transition is enabled. An enabled transition may re. The ring of a transition represents the occurrence of an event and causes changes in the WU state: tokens are consumed from input places and produced in the output places of the red transition. We restrict to 1-safe nets, in which places may be marked with at most one token citePeterson81. A WU groups a set of related events. Some of these events are only relevant within the WU and are hidden to other WUs. Thus we call them hidden events. Other events are needed for interfacing the WU with other WUs, these ones are called visible events. Among this latter group, we distinguish the set of starting events, the set of ending events and the set of intermediate events. The WU execution starts when one of the starting events occurs and terminates with the occurrence of one of the ending events. Intermediate events may occur while the WU is in progress, that is after it has been initiated and before it is terminated. In TANGO, we augmented the traditional Petri net formalism by introducing signals. Signals work as triggers; they are generated by the occurrence of an event and are addressed to another event. If the conditions of a signaled event are satis ed, the event is immediately scheduled to occur. That is, it will re, unless it is disabled by the occurrence of another signaled event. If, instead, the signaled event is not enabled, the signal is lost. Signals are used when we want to force the occurrence of an event in order to maintain consistency constraints. We may now introduce a formal de nition of work unit.

De nition 1 (Work Unit (WU)) A work unit W is a 4-uple W = (E; C; F; S ),

where,

 E is a set of events partitioned into two subsets, the set of visible events (V E ) and the set of hidden events (HE ). The set V E is further partitioned into three subsets:

{ SE are the starting events { EE are the ending events { IE are the intermediate events  C is a set of conditions 4

 F is a set of ows connecting events to conditions and conditions to events (i.e., F  (C  E ) [ (E  C )).  S is a set of signals. Each signal is a pair (e1; e2) where e i = 1; 2 are events (i.e., S  E  E ). e1 is the event generating the signal and e2 is the signaled i

event.

Visible events are the interface with other WUs. Therefore, they are the only ones that can have external conditions and can produce or receive signals to/from other WUs. WU de nitions may be nested. An arbitrary number of nesting levels is allowed. A WU w1 is nested in a WU w0 if all events, conditions, ows, and signals of w1 also belong to w0. Two WUs cannot partially overlap: either one is nested in the other or they are independent, that is, they may not have intersecting sets of events, conditions, ows or signals. We may now provide a formal de nition of TANGO speci cation as a set of work units hierarchically structured in a nesting tree.

De nition 2 (Nested Work units, TANGO speci cation) Given two work units w1 = (E1; C1; F1; S1) and w0 = (E0; C0; F0; S0), w1 is nested in w0 i E1  E0, C1  C0, F1  F0, and S1  S0 and all the ows and signals connecting an element of w1 with an element (event or place) not belonging to w1 have as source or target a visible event of w1. A TANGO speci cation is a top-level work unit (not nested in another work unit), which may contain nested work units. The top level work unit is also called the system work unit. Recall the example of the software development environment we gave in Section 1. The example deals with a fragment of the description os software development process. For this process we assume that each program module undergoes a design phase and a coding phase. These two phases may be partially carried out in parallel. The module design is made available as soon as it has been nished and before it has been approved. In this way, it is possible to start coding with a non de nitive version of the design. Of course, if the design is rejected for some reason, there is a second iteration of the design and, if the coding phase has already been started, it has to be aborted. On the other hand, it is not possible to commit the module code until the module design has been approved. In order to model this situation we use two WUs: design and code. A graphical representation of these two WUs, including the dependencies among them, is given in Figure 1. A WU is depicted as a box with the starting events on top, the ending events on bottom and the intermediate ones on the sides of the box. Hidden events remain inside the WU box. Design has one starting event (Start Design), two ending events (Reject Design and Approve Design), and one intermediate event (Finish Design). Code visible events are: Start Code, Request Abort, Abort Code, and Commit Code. 5

Ready to Design Start Design Design Preliminary Design Designing Evaluating

Start Code Finish Design

Code Request Abort Coding

Reject Design

Approve Design

Approved Design

Abort Code

Commit Code

Figure 1: Work unit example. The dependencies among transactions are now speci ed using conditions and signals. Condition Design Finished, allows Code to start as soon as the design is available. Condition Design Approved prevents Code from committing before the design is approved. Finally, when Reject Design occurs, a signal is generated to force the occurrence of event Request Abort, which, in turn, signals Abort Code. It is the work unit designer responsibility to guarantee that when event Request Abort occurs, the transaction ends with Abort Code. In the example, this is very simple, since Abort Code is always enabled while the work unit is in progress and thus, it is enough to signal the event. In the following we will assume that whenever a \request" event occurs, the work unit designer guarantees that it nishes with the occurrence of the requested event. Note that WUs in general do not satisfy the ACID properties. For example, the two WUs of the previous example are not executed in isolation: as if each one were the only transaction in the system. On the contrary, the execution of one of them may signi cantly aect the execution of the other.

2.2 Work Unit Behavior

This section introduces the semantics of a work unit as the set of all its valid behaviors. Then, we de ne the semantics of a TANGO speci cation as the system work unit behaviors. It is also possible to abstract from other work units behavior and \observe" only the behavior of a single work unit, by recoding only the relevant 6

events for that work unit. The execution of a WU starts with the occurrence of one of its starting events and nishes with the occurrence of one of its ending events. In the start state, none of the places of the WU is marked, and there are no signaled events. Once the WU execution starts, tokens may be inserted into places and transitions may be signaled. The work unit state is, thus, determined by the marking of all its places and the set of pending signals (i.e., signaled events that have not already occurred). The work unit state is changed by the event occurrences.

De nition 3 (marking, set of pending signals, state, event occurrence)

Given a work unit w = (E; C; F; S ), the marking of w is a subset of conditions M  C and the set of pending signals is a subset of the set of events P  E . The state of w is de ned as the pair hM ; P i. Let us denote with pre(e) the set of input places of event e, and with post(e) to the set of output places of e. We say that event e 2 E is enabled i pre(e)  M . Then, the occurrence of event e in state hM ; P i is possible only if e is enabled in that state and changes the state yielding a new state hM ; P i, where 1. M = M ? pre(e) + post(e) w

w

w

w

w

w

w

0

0

w

w

0

w

w

2. P = ((P ? feg) [ fx j he; xi 2 S g) \ fy j pre(y )  M g 0

w

0

w

w

The occurrence of an event is written M ; P [eiM ; P . In the obtained marking the preconditions of e cease to hold and the postconditions became true.3 The set of pending signals is obtained by augmenting the original set with all the signals generated by the event and discarding all the events that have been disabled. An occurrence sequence is a sequence of event occurrences where the rst event is a starting event, the last one is an ending event, and all other events are neither starting nor ending. Instead, a valid occurrence sequence is an occurrence sequence in which signaled events always occur before other events. Thus, a valid occurrence sequence veri es the invariant that either the set of pending signals is empty or the next occurrence is an event belonging to the set of pending signaled events. Formally, w

w

0

0

w

w

De nition 4 (Occurrence Sequence, Valid Occurrence Sequence) An oc-

currence sequence of work unit w = (E; C; F; S ) is a sequence of occurrence events  = e1 ; e2; :::; e where e1 2 SE , e 2 EE and fe2; :::; e ?1g\ (SE [ EE ) = ;. An occurrence sequence  = e1 ; e2; :::; e is a valid occurrence sequence i for each event occurrence M ?1 ; P ?1 [e iM ; P is satis ed that P ?1 = ; or e 2 P ?1 w

n

n

w

i w

n

n

i w

i

i w

i w

i w

i

i

From the previous de nition it is clear that a starting event of a work unit may not occur while the work unit is in progress. Notice that this behavior of 3 Note that + and ? denote the set union and dierence, thus if, for example, a condition belongs to both the pre and post set, it remains marked.

7

only one execution thread for each WU does not prevent the intra-parallelism in a WU, that is internal events and nested WUs can be executed in parallel. An additional condition is that a WU ending events are not enabled if there are nested work units in progress. These additional controls can be implemented by adding to the WU de nition the adequate conditions, that, for the sake of simplicity, are left implicit4 .We may now give a precise de nition of the behavior of a work unit and, in general, of a TANGO speci cation. De nition 5 (Work Unit Behavior, TANGO Speci cation Behavior) The behavior of a work unit is de ned as the set of all valid sequences for that work unit. The behavior of a TANGO speci cation is the set of valid occurrence sequences of the system work unit. We return again to our running example of Figure 1 in oder to illustrate work units behaviors. Let us suppose that the two transactions (Design and Code) are part of a transaction called Develop (not shown in the gure) in which both are nested. Consider now these three partial behaviors of transaction Develop (a complete behavior would begin with one starting event and nish with an ending event of the transaction):

1 = : : :Start Design; Finish Design; Start Code; Reject Design; Start Design; Finish Design; Approve Design; Commit Code : : : 2 = : : :Start Design; Finish Design; Start Code; Reject Design; Request Abort; Abort Code : : : 3 = : : :Start Design; Finish Design; Start Code; Reject Design; Request Abort; Abort Code; Start Design; Finish Design; Start Code; Approve Design; Commit Code : : : It is easy to see that all of them (1 , 2 , and 3 ) are occurrence sequences; but only 2 and 3 are valid occurrence sequences. In fact, 1 does not represent a desired behavior of the transaction, because the second iteration of Design is not re ected by the coding, which is uniquely based on the rst (rejected) design. On the contrary, 2 represents a correct behavior. In this case, the signal forces rst the work unit Code to abort if the design is rejected. 2 can be completed by the activation of another execution of Code, obtaining the valid behavior 3 . In 3 , work unit Code is successfully commited depending on the design approval. 4 For example, this control can be enforced by assuming the presence of implicit preconditions for ending events. These conditions hold only when there are no nested WUs in progress.

8

T CT2 s c

a

CT1 s c

s a s

T1

a s

a

T2

c

s

T3

c

c

c

Figure 2: An example with compensanting transactions. As we said above, it is possible to abstract from the behavior of nested work units of a work unit w, by considering only the \proper events" of w. This means that, when executing w, we wish to \observe" only the events that belong to w discarding the \hidden" events of nested work units.

De nition 6 (Proper Events, Proper Behavior) The set PE of proper events of a WU w = (E; C; F; S ) is the set PE = E ?fx j x 2 HE 1 and w1 is nested in wg. w

w

w

The proper behavior of a work unit w is the projection of a w behavior  onto w proper events. We denote such projection ( ). w

w

The TANGO basic constructs de ned so far (events, signals, conditions, etc.) may be seen as a kernel notation on top of which new constructs may be de ned. For example, some advanced transaction models include the notion of compensation of a transaction [10]. The compensation occurs when, due to some condition, the normal execution of the transaction is stopped: running (sub)transactions are aborted, no new (sub)transactions are initiated, and committed (sub)transactions are compensated. This schema assumes that, for each transaction, there exists a compensating transaction that semantically undoes the eects of a committed transaction. For example, this can be represented as in Figure 2 where a WU T is mainly composed by the sequence of nested WUs T1, T2, T3 and compensating transactions CT1 for T1 and CT2 for T2. If T is in progress, and Request Abort occurs, three dierent situations depending on which nested WU is in progress can follow such occurrence. If T1 is in progress, it will abort and then T will end by abort. If T2 is in progress, T2 will abort and then CT1 will be executed. Finally, if T3 is in progress, the occurrence will be followed by the end of T3 by abort and the execution of CT2 and CT1. When specifying compensation mechanisms for more complex models, the TANGO nets become rather complex. Therefore, since compensation mechanisms are widely used by advanced transaction models and to simplify these models, we 9

Req. Kill T a s a s

T1

a s

T2

a s

T3

c

c

c

c

Figure 3: An example using the \kill" signal. provide a built-in request event to handle a particular signal called \Kill". When a Request Kill is signaled, the following actions are executed: 1. the \killed" WU stops its normal execution, 2. the kill signal is re-transmitted to all the running nested WUs, 3. for all the nested WUs already committed triggers the execution of compensating WUs in the reverse order that they have committed, 4. the WU nishes the execution by executing a pre xed ending event. The semantics of \Kill" may be given in terms of TANGO. Consider the transaction in Figure 3. When event Req. Kill occurs, its behavior is given by the TANGO work unit of Figure 2. A TANGO model of a transaction describes control information. Regarding data, we assume that there exists a persistent global repository (the database) on which all operations are carried out. However, each WU may have its own local memory. When a nested WU commits, its results are made persistent in the local memory of the WU in which it is nested. Dashed WUs have no local memory and thus, they use the outer WU's memory. The local memory allows us to model dierent situations of committed data. If a WU produces de nitive persistent data, this might be written directly in the global data base. If the data is temporary persistent and do not want to make it visible everywhere, we may keep it in the local memory so that it can be accessed in a limited way.

3 An example of transaction speci cation This section presents an example in order to illustrate TANGO modeling features \at work". Suppose a that a travel agency is organizing a trip from Milan to Buenos Aires for a family group. The travel agency employee has to reserve the

ight tickets in one of the companies that the customer has already chosen. Then, he/she has to book the hotel, but only is the ight is available. Finally, a car has 10

to be rented for all the days the family group is staying in Buenos Aires. If either the ight reservation or the hotel booking fail, the trip plan is given up. Renting a car is not vital so the trip is carried out even if the car is not available. Thus, the failure in renting a car does not imply the rollback of the the whole transaction. Figures 4, 5, and 6 provide a TANGO model for the transaction the travel agent has to carry out to satisfy the family group wishes. Figure 4 is the system transaction and provides a high-level view of the model. Req. Kill

TRIP

f s

Hotel c c

c s

s

Flight

a

f s

Car

f f c

Figure 4: The Trip Example Figures 5 and 6 provide further details of the travel plan. Figure 5 speci es the ight reservation preferences. The family group prefers a direct ight MilanBuenos Aires, but if it is not possible, the cheapest way is to go to New York and then take a plane to Buenos Aires. A compensating transaction is called if the agency succeeds in reserving Milan{New York but not New York{Buenos Aires. In such case, the compensating transaction is responsible to cancel the former reservation. Flight c

f a

C-Milan s NY

s Milan- f s Bs As c

s MilanNY

f s c

NYBs As

f c

c c

Figure 5: Flight preferences Figure 6 details the family group preferences for the hotel. They want to go to one of the two hotels named there without any preference, so the transactions can be executed in parallel and they will take the rst hotel that con rms its 11

availability. When one subtransaction commits, it must kill the other one. The hotel activity fails if both subtransactions fail. a Plaza Hotel

s

f

R.Kill

f

c

s

c R.Kill

c

Alvear Hotel

s

f a

Hotel

Figure 6: Hotel preferences The resulting TANGO transaction speci cation is thus composed of a hierarchy of work units. Each work unit models graphically and in an operational manner one level of the description, hiding the details of lower level transactions and improving the model understability.

4 Representation of transaction dependencies identi ed in ACTA When reasoning about the behavior of concurrent transactions, the speci cation and analysis of dependencies became a crucial issue. [5] identi es a set of different types of dependencies (t ; t ) two transactions may have. In this section we assess the expressive power of TANGO by modeling all the synchronization dependencies between transactions presented in [5]. TANGO models are based on an operational formalism, rather than a logic-based one. We believe that, in this way, dependencies are easier identi ed and understood. The representation is intuitive and readable without loosing formality. i

j

Commit Dependency: if both transactions t and t commit then the commiti

j

ment of t precedes the commitment of t (Fig. (A)). Strong-Commit Dependency: if transaction t commits then t commits (Fig. (B)). Abort Dependency: if t aborts then t aborts. (Fig. (C)). i

j

i

i

j

12

j

S

S

Ti A

Ti

S C

S

A

Tj A

C

Tj

RC A

C

C

(B) Strong-Commit Dependency

(A) Commit Dependency

Weak-Abort Dependency: if t aborts and t has not yet committed, then t i

aborts (Fig. (D)).

j

S

S

Ti A

j

Ti

S C

A

Tj

RA A

S C

Tj

RA

C

A

(C) Abort Dependency

C

(D) Weak-Abort Dependency

Exclusion Dependency 1: if t commits and t has begun executing, then t i

aborts5.(Fig. (E)).

j

j

Exclusion Dependency 2: t and t cannot both commit. (Fig. (F)). i

j

S Ti A

S C

A

Tj

RA A

S

S

Ti

Tj C

A

C

C

(E) Exclusion Dependency 1

(F) Exclusion Dependency 2

Termination Dependency: t cannot commit or abort until t either commits or aborts (Fig. (G)).

j

i

Force-Commit-on Abort Dependency: if t aborts , t commits. (Fig. (H)). Begin Dependency: t cannot begin executing until t has begun (Fig. (I)). i

j

j

i

Actually, [5] presents only one Exclusion Dependency, but we give two dierent interpretations to this dependency and thus we present two dierent exclusion dependencies. 5

13

S

S

Ti A

Ti

S C

A

Tj A

S C

Tj

RC A

C

(G) Termination Dependency

C

(H) Force-Commit-on-Abort Dependency

Serial Dependency: t cannot begin executing until t either commits or aborts j

(Fig (J)).

i

S

S

Ti

Ti

A

S

C

A

S C

Tj

Tj A A

C

C

(I) Begin Dependency

(J) Serial Dependency

Begin-on-Commit Dependency: t cannot begin executing until t commits j

(Fig. (K)).

i

Begin-on-Abort Dependency: t cannot begin executing until t aborts (Fig. j

(L)).

i

Weak-Begin-on-Commit Dependency: if t commits, t can begin executing i

after t commits. (Fig. (M)).

j

i

S

S

Ti A

Ti

S C

A

Tj A

S

C

A

Tj A

C

(K) Begin-on-Commit Dependency

Ti

S

C

(L) Begin-on-Abort Dependency

S C

Tj A

C

(M) Weak-Begin-on-Commit Dependency

Commit dependency is present in the above described software engineering example. Abort dependency is used when a transaction is vital for another transaction [7]. Weak Abort dependency is useful dealing with nested transactions [16]; instead, Begin-on-Commit dependency, Begin-on-Abort dependency and Forcecommit on Abort dependency are useful dealing with compensating transactions 14

[10] and contingency transactions (i.e., alternative transactions to be executed if a given transaction aborts) [5]. Exclusion Dependencies are present when we have several transactions doing the same activity, and the successful end of only one is meaningful.

5 Overview of transaction models In this section, we present a brief overview of some transaction models, and we discuss how they can be speci ed using TANGO. The aim of this section is not present an exhaustive survey of the present transaction models, but illustrate the TANGO formalism and its potentialities.

5.1 Flat Transactions

A traditional at transaction may be easily modeled as a WU by, for example, identifying one starting event start and two possible ending events: commit and abort, as shown in Figure 7(A). In some cases, it might be convenient to distinguish between two commit states: a successful commit, in which some prede ned conditions are satis ed and a fail commit, in which these conditions do not hold. To model this fact, we may distinguish three ending events: successful commit, fail, and abort (rolling back the transition's eects). This situation may be modeled as in Figure 7(B), where a new relevant ending event has been added to the step. Start

Commit

Start

Commit

Abort

Fail

(A)

Abort

(B)

Figure 7: Flat Transactions.

5.2 Transactions with Savepoints

Flat transactions are often extended to deal with savepoints. A savepoint is established recording the current state of processing. In case of an abnormal execution, the transaction is rolled back to a savepoint re-establishing the recorded state rather than to be completely rolled back. Savepoints are xed when partially consistent states are reached. They de ne potentially re-starting points of the 15

transaction. In this way, returning to a savepoint rather than a complete rollback, a transaction continues to live maintaining its resources. The execution between two savepoints can be considered as atomic [12]. Hence, a way to specify Transactions with Savepoints using TANGO is the follows:

 Divide a transaction with savepoints in more elementary ones, each elemen    

tary transaction must be composed by the code between two savepoints. Each savepoint belongs to an elementary transaction and, it is represented by a visible intermediate event. Every savepoint issues a signal to the start event of the following elementary transaction creating it. After a savepoint, the created transaction is executed and the creator stays waiting for the commit (or a possible abort). A termination dependency is then established between the creator and the created transaction. Only the last transaction can initiate the commit work which will be continued in order by the predecessors till the full transaction commits. A chain of signals requiring commit is issued from the last elementary transaction to the rst one. In the case that an elementary transaction aborts, the entire transaction should be roll-backed to a desired savepoint. Hence, a signal requiring abort is issued to all the transactions created after such savepoint.

A restriction using TANGO is that the selection of the savepoint to be rollbacked must be statically de ned. A particular case of Savepoints are the Chained Transactions:

5.3 Chained Transactions

The idea behind chained transactions is that a whole sequence of transactions is executed as a larger one, where the control is passed from one to the other without loosing the context. Chained transactions can be viewed as a particular case of transactions with savepoints. Instead of the savepoints, the elementary transactions commit what they have done; and rollback is limited to the currently active transaction [12]. The commit work of a transaction and the beginning of the posterior transaction must be done as an atomic operation in order to prevent the alteration of the context by an external transaction. This is the reason for the signals addressed to the start events in Figure 8 where a sequence of chained transactions is speci ed using TANGO. 16

T

a a

s

s

a s

T1 c

a s

T2 c

T3 c c

Figure 8: Chained Transactions

5.4 Nested Transactions

In the nested transaction model, transactions are decomposed into subtransactions which can be either nested or at transactions. In this way, each transaction forms a tree hierarchy where the leaves are at transactions. Each subtransaction is executed atomically and it can either commit or abort independently of its parent or siblings. This is an important bene t with respect traditional transactions because nested transactions can be used to localize the eects of failures and faults in the system [1]. The policy to follow in case of failure can be modeled, if a part of the transaction (i.e., a subtransaction) aborts the user may retry the aborted part, abort the whole transaction, try with an alternative subtransaction or ignore it directly. In fact, a subtransaction can abort without cause any eect to its parent, but if the parent aborts, all its children must be aborted. Other important bene t is the intra-transaction parallelism. A subtransaction has access to the objects manipulated by its parent. When a subtransaction commits, its objects are made visible only to its parent. Only when the root transaction commits, these objects are accessible by the outside world. A parent transaction can commit only when all its children have terminated (i.e., they have committed or aborted). All these aspects are modeled with TANGO by:  using solid line boxes for nested transactions. This is due to the visibility rules of the model. A child works on a copy of the memory accessed by its parent and when it commits, it writes on the parent's memory;  using an abort dependency relation to represent a vital subtransaction;  using a begin-on-abort dependency to represent an alternative subtransaction;  issuing a signal requiring abort to all the children when the parent receives an analogous signal. Figure 9 shows an example of nested transaction where at the rst level two subtransactions are executed in parallel and when both terminate a third trans17

action starts. In addition, the three transactions are composed by a sequence of two subtransactions. In case of a transaction abortion, the signals (dashed arcs) expand the abort to the children. If T1 aborts, its parent continues executing ignoring the abort. That is, T1 is an example of a non-vital transaction. Instead, T2 is an example of a vital transaction because its abort produces the abort of its parent.6 RA

T T2

RA

a

s c

2abort T3

a RA

a

s

s T1

RA

c a

s c c

Figure 9: Nested Transactions

5.5 Sagas

Sagas, in its sequential version, is an extension of chained transactions where each transaction composing the chain has a compensating transaction. A compensating transaction CT of a transaction T is a transaction that can semantically undo the eects of T after it has committed7 . A Saga is a long lived transaction composed by a chain of transactions T1,..,Tn as a unit of control. Unlike chained transactions, an execution of a Saga is either the complete sequence T1,..,Tn or, in case a transaction aborts, the partial execution is semantically rolled back executing in the reverse order the compensating transactions of those already committed. For example, if a Saga is composed by transactions T1,..,T4, the system guarantees that one of the following sequences are executed: 1. T1.T2.T3.T4 if neither T1, nor T2, nor T3, nor T4 aborts 2. T1.CT1 if T2 aborts 3. T1.T2.CT2.CT1 if T3 aborts 4. T1.T2.T3.CT3.CT2.CT1 if T4 aborts 6 7

A better de nition of vital and non-vital transactions can be found in [7]. It is assumed that a compensating transaction must commit whatever happens.

18

A sample of a Sagas composed by three transactions T1, T2 and T3 is shown in Figure 10 which is a slight variation of the net fragment presented in Figure 2. The most external box has to be dashed because a Saga compose a semantical unit where its components release their results to the rest of the concurrent transactions. Sagas hence relax the isolation, a necessary issue to deal with long-lived transactions. Hence, to describe a Saga composed by transactions T1 ; : : :; T using TANGO you must:  de ne a chain of begin-on-commit dependencies from T1 to T ;  de ne a chain of begin-on-commit dependencies from CT ?1 to CT1;  for each i, 2  i  n, de ne a begin-on-abort dependency from T to CT ?1  enclose all in a dashed WU. n

n

n

i

i

T CT2 s c

a

CT1 s c

s a s

T1

a s

T2

c

a s

c

T3 c

c

Figure 10: Sagas Moreover, Sagas can be modeled using directly the \kill signal". The resulting net is similar to that of Figure 3 but adding a signal from each event Abort of transactions T2 : : :T to the Request Kill. n

5.6 Multi-Level Transactions

Multi-Level Transactions (MLT) is a special case of nested transactions where the hierarchy tree is balanced. Each level of the tree represents a level of abstraction with respect the database management operations; the deeper the level, the less abstract they are. The concept behind MLT is that operations at level i are implemented by those at level i+1. A single operation regarded at a level i appears indivisible and thus is referred to as a transaction at such level. Moreover, the operations composing it are considered its subtransactions. This permits to exploit level-speci c semantics for concurrency control and then enhance intra-transaction parallelism taking advantage of level-speci c con ict information [7], [20], [3]. MLT go beyond Nested transactions allowing early commit of the subtransactions doing visible their results to the outside world. Thus, transaction abort 19

cannot be implemented restoring the original state, but using high-level operations compensating the subtransactions [20]. That is, MLT assume the existence of a compensating transaction which can semantically undo what the subtransactions have done, even those already committed [12]. These compensating operations cannot be de ned statically due to the intraparallelism and hence is necessary a strong use of a multi level logging architecture. Each log record the level-speci c information to compensate the level operations [20]. The speci cation in TANGO of MLT diers from that of nested by allowing dashed WUs, and when a subtransaction aborts, it issues a kill signal to the container transaction. Open nested transactions are a generalization of MLT where the hierarchy tree may not be balanced relaxing the level-speci c or layer based concurrency control.

5.7 The DOM model

The DOM transaction model is yet another extension of the nested model where closed nested transactions can be combined with open nested transactions. Open nested transactions stand for nested transactions that allow partial results to be viewed by other transactions. The model also support the de nition of compensating transactions and contingency transactions. Contingency transactions are alternative transactions to be executed if a given transaction aborts. Moreover, subtransactions can be speci ed vital or non-vital. Vital subtransactions are those that their abort implies the abort of the parent. Instead, a parent may continue although a non-vital sub-transaction aborts. The DOM model allows intra-transaction parallelism but dependencies may be speci ed establishing a commit order for the transactions. All this can be speci ed using TANGO by:  using a dashed box to specify a full open nested transaction;  using a solid line box to specify a complete closed nested transaction;  using visible intermediate events to specify the release of some partial results;  using an abort dependency and the kill signal to specify vitality. The nonvitality is directly speci ed ignoring the abort event.  using the commit dependencies to x the commit order of the transactions.

6 Analyzing TANGO speci cations Since TANGO is an operational (model based) formalism, the executability of speci cations written in TANGO is straightforward. In the last years, the importance of execute formal speci cations was widely advocated [14] as a means 20

of validation. One can check whether speci cations capture the intended functional requirements by executing the speci cations and observing the behavior of the system. That is, we can test the transaction model in the early phase of the development process by executing the TANGO speci cation. Moreover, given the simplicity of TANGO, we can easily adapt and apply most of the well-known techniques for analysis of Petri nets, such as invariants, and matrix equations and reachability analysis [17]. For example, TANGO deals with bounded nets and hence only a nite number of markings are reachable from a given initial marking. This allows the representation of the reachability relation among these markings by a nite directed graph, called reachability graph . This graph represents all the possible behaviors of the system model. Every valid occurrence sequence is a directed path in the graph, and conversely, every directed path in the graph is a valid occurrence sequence. In spite of the variations introduced in TANGO with respect Petri nets, the reachability graph for a work unit can be built in much the same way as for a classical Petri net. A graph node (or a state) consists now of the set of pending signals besides the reachable marking. When building the graph, the set of successor states of a given state is calculated considering also the set of signals. The introduction of signals in the model may reduce but not enlarge the set of possible ring sequences (model behaviors) with respect to the pure Petri net model (i.e., without signals). Using these methods one can prove properties about reachable markings, possibility of deadlocks, sequence of transitions representing either desired or undesired behaviors, etc. For example, considering the model of Figure 1, one could wish to prove that transaction Code cannot commit before Approve Design occurs. This can be proved by exploring the reachability graph and verifying that there is no path in which the transition Commit Code precedes the transition Approve Design. By combining the possibility to observe the proper events of a WU with the above mentioned techniques, one can reason about the behavior of the system at dierent levels of abstraction. This means that analysis focuses at one level of the speci cation abstracting from the work units internals, looking only at the proper work unit behaviors. For example, when presenting the trip example in Section 3, we were able to reason at the Trip level, without knowing how transaction Flight would nally be implemented. An additional advantage of this approach is that analysis can be carried out incrementally. In other words, the analysis is not repeated each time, but instead can be reused [8]. In order to drop any kind of ambiguity, a formal language should be used to express properties desired in the model. Temporal logic [15] has been shown adequate for reasoning about the execution sequences of programs and was found useful in proving properties of concurrent programs. Using temporal logic one can adequately describe the behavior of a WU by stating properties about the events composing the WU. Then, the implementation of a WU can be veri ed by using one of the available techniques. These techniques veri es if the drawn net satis es 21

the formulas (i.e., the desired properties) checking the formulas against the set of all valid occurrence sequences. This can be done, for example, by building regular !-expressions and the reachability graph associated to such work unit [18]. The analysis can be done even algorithmically by considering the reachability graph an automaton and model checking the formulas [6] or manually by axiomatizing the net and using a proof system [9].

7 Related Work One of the main aims of current research in transaction modeling is to provide a general uni ed theory in which all transaction models are precisely stated. Several works explore this direction. A rst example is the ACTA framework [5], that allows the speci cation of the eects of transactions on other transactions and also their eects on objects. A transaction model is speci ed axiomatically with a set of properties. The stated properties must be satis ed by any behavior of the modeled transaction. As in TANGO, each transaction in ACTA is characterized by a set of signi cant events. Among these events, there is a set of initiation events and a set of termination events, that respectively correspond to the starting and ending events of TANGO. In opposition to ACTA, TANGO provides an operational view of the behavior of transactions, while ACTA speci cations are fully declarative. Another interesting approach is the ConTract Model [19]. The basic idea of ConTract is to build large applications from short ACID transactions, by providing an application independent system service that has control over the execution of short transactions. The step is the elementary unit of work in ConTract. It corresponds to the idea of sequential program and may be coded in one arbitrary sequential language. Relationships among steps are speci ed with a script language. The scripts provide a notation to group steps in bigger steps, to describe the control ow (with sequence branch, loop, and some parallel constructs) and to state dependency declarations. Thus, we may say that the script language combines dierent alternatives in an eclectic approach. A recent textbook on transaction processing [12] includes a notation for describing transaction models by a set of simple rules. The notation assumes that a transaction model is made up of atomic actions, each of them is a state machine where state transitions are triggered by events. There is one rule for each state transition. A rule is identi ed with the name of the transition and has two parts: the right hand-side that speci es a set of preconditions and the left hand-side which speci es dependencies among atomic actions, the generated signals, and the new state of the atomic action. Rules are executed in a forward chaining manner: when an event occurs the corresponding transaction rule is signaled and the preconditions are evaluated. If preconditions hold, the right hand-side of the rule is executed. The rule execution eects are that dependencies are added, signals 22

activate other rules, and the atomic action changes state. All the actions triggered by one event are executed atomically; that is the whole chain of dependent events is completed before any non related event is considered. TANGO chaining mechanism is more exible, allowing a chain of signaled events to be interrupted. The choice is left to the work unit speci er.

8 Concluding remarks This paper has presented a new language, called TANGO, suited for the design of non-traditional database applications, involving complex dependencies among transactions and parallelism. TANGO is not yet another transaction model, but rather a framework which allows one to specify transaction models and to reason about the behavior of such models. TANGO is based on a high-level Petri net formalism, and includes a modularization construct that permits a TANGO speci cation to be structured in work units. TANGO allows the speci cation of the control ow between the dierent interacting transactions of the system. In particular, the intra-parallelism and the failure-prone part of a transaction can be explicitly modeled. TANGO showed to be exible for modeling the peculiar characteristics of most of the present transaction models. In this version of TANGO, particular attention was given control ow. We are currently investigating the extension of TANGO in order to include also data ow information. One possible way of doing this is by introducing labeled tokens as in [11]. This would allow us to model con icts due to particular data, data locking at dierent levels and a ner representation of the data visibility. Moreover, data integrity would be better described by extending the concept of signals where a signal should be triggered due to a data change as in rule systems [4]. We also plan to characterize the properties which hold for sets of transactions modeled by using TANGO. For instance, we would like to establish whether a WU has some of the ACID properties or, observing the occurrence sequences, determine if two WUs are commutable. The extension to data ow should help this process. There are two other extensions that we intend to incorporate. The rst one is provide language constructs to specify executions that explicitly depend on the history, i.e., to incorporate log mechanisms. The second is extend the formalism in order to allow dynamic transaction models, that is, transactions that are created, deleted or recon gured during execution as in the Split model[13].

References [1] D. Agrawal and A. El Abbadi. Transaction managemenent in database systems. In A. Elmargamid, editor, Data Base Transaction Models for Advanced 23

[2] [3] [4] [5] [6] [7] [8] [9]

[10] [11] [12] [13] [14]

Applications. Morgan-Kauman Publishers, 1992. S. Bandinelli, A. Fuggetta, and S. Grigolli. Process modelling in-the-large with slang. In Proceedings of 2nd. International Conference on the Software Process, Berlin (Germany), 1993. C. Beeri, H. Scheck, and G. Weikum. Multilevel transactions management, theoretical art or practical need? 1st EDBT- LNCS 303, 1988. S. Ceri and J. Widom. Deriving production rules for incremental view maintenance. Technical Report RJ 8027, IBM, 1991. appeared in VLDB'91. P. Chrysanthis and K. Ramamrithan. Acta: The saga continues. In A. Elmargamid, editor, Data Base Transaction Models for Advanced Applications. Morgan-Kauman Publishers, 1992. E. Clarke, E. Emerson, and A. Sistla. Automatic veri cation of nitestate concurrent systems using temporal logic speci cations. ACM-TOPLAS, 8(2):244{263, April 1986. A. Elmargamid, Y. Leu, J. Mullen, and O. Bukhres. Introduction to advanced transaction models. In A. Elmargamid, editor, Data Base Transaction Models for Advanced Applications. Morgan-Kauman Publishers, 1992. M. Felder, C. Ghezzi, and M. Pezze. Analyzing re nements of state-based speci cations: the case of tb nets. In Proceeding of International Symposium on Software Testing and Analysis, 1993. M. Felder, D. Mandrioli, and A. Morzenti. Proving properties of real-time systems through logical speci cations and petri nets models. Technical Report 91-72, Dip. di Elettronica-Politecnico di Milano, December 1991. To appear in Transactions on Software Engineering. H. Garcia-Molina and K. Salem. Sagas. Proc. ACM SIGMOD, 1987. C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezze. A uni ed high-level petri net model for time- critical systems. IEEE Transactions on Software Engineering, 17(2), February 1991. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan-Kauman Publishers, 1993. G. Kaiser and C. Pu. Dynamic restructuring of transactions. In A. Elmargamid, editor, Data Base Transaction Models for Advanced Applications. Morgan-Kauman Publishers, 1992. R. A. Kemmerer. Testing formal speci cations to detect design errors. IEEE Transactions on Software Engineering, January 1985.

24

[15] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems. Springer Verlag, 1991. [16] E. Moss. Nested transactions: An approach to reliable computing. Technical Report MIT-LCS-TR-260, M.I.T., 1981. [17] J. L. Peterson. Petri Net Theory and the Modelling of Systems. Prentice-Hall, Englewood Cli NJ, 1981. [18] I. Suzuki. Formal analysis of alternating bit protocol by temporal petri nets. IEEE-TSE, 16(11):1273{1281, Nov 1990. [19] H. Wachter and A. Reuter. The contract model. In A. Elmargamid, editor, Data Base Transaction Models for Advanced Applications. Morgan-Kauman Publishers, 1992. [20] G. Weikum and H. Scheck. Concepts and applications of multilevel transactions and open nested transactions. In A. Elmargamid, editor, Data Base Transaction Models for Advanced Applications. Morgan-Kauman Publishers, 1992.

25