Derived Transaction TerminationDependencies: An Algorithm forComputing Transitivity RulesKerstin Schwarz Can T�urker Gunter SaakeOtto-von-Guericke-Universit�at MagdeburgInstitut f�ur Technische InformationssystemePostfach 4120, D{39016 Magdeburg, GermanyE-mail: fschwarzjtuerkerjsaakeg@iti.cs.uni-magdeburg.deFebruary 1998

AbstractComplex applications consist of a large set of transactions which are interrelated. Thereare di�erent kinds of dependencies among transactions of a complex application, e.g. ter-mination dependencies which are constraints on the occurrence of signi�cant transactionevents. Often, it is very di�cult for the application/transaction designer to get a graspof the transitive relationships among the transactions of a complex application. In thispaper, we introduce the notion of transaction closure as a generalization of nested trans-actions. A transaction closure comprises all transactions which are transitively initiatedby one (root) transaction. The relationships among transactions of a transaction closureare speci�ed by di�erent kinds of dependencies. We identify transaction terminationdependencies which determine reasonable termination event combinations of two relatedtransactions. These basic termination dependencies are further re�ned considering theaspect of compensatable transactions. In particular, we consider the transitivity prop-erty for all kinds of transaction termination dependencies discussed in this paper andpresent a set of rules for reasoning about the transitivity of these dependencies. Thus,we are able to conclude how two arbitrary transactions are transitively interrelated. Thisissue is essential for understanding the entire semantics of a complex application.Keywords: transaction closure, termination dependencies, compensation, transitivedependencies.

CONTENTS iContents1 Introduction 12 The Notion of Transaction Closures 33 Termination Dependencies in Transaction Closures 53.1 Basic Termination Dependencies . . . . . . . . . . . . . . . . . . . . . . . 53.2 In uence of Transaction Compensation . . . . . . . . . . . . . . . . . . . 84 Transitivity of Termination Dependencies 134.1 Foundations of Derived Dependencies . . . . . . . . . . . . . . . . . . . . 134.2 Computing Valid Dependency Combinations . . . . . . . . . . . . . . . . 164.3 Exemplary Application of the Algorithm . . . . . . . . . . . . . . . . . . 225 Application of the Transitivity Rules 256 Conclusions and Outlook 29Bibliography 31A Transitivity Rules of Termination Dependencies 35

ii CONTENTS

Chapter 1. Introduction 1Chapter 1IntroductionThe dynamics of complex applications can be modeled by collections of related transac-tions. Examples for such complex applications are business processes, CSCW applica-tions or design transactions. In such applications there are di�erent kinds of dependenciesamong the related transactions, e.g. termination dependencies which are constraints onthe occurrence of signi�cant transaction events. Often, it is very di�cult for the ap-plication/transaction designer to get a grasp of the transitive relationships among thetransactions of a complex application.The concept of transaction closure [STS98] as a generalization of the well-knownconcept of nested transactions [Mos85] together with a set of transaction terminationdependencies provide a common framework for modeling advanced, complex transac-tions/activities. A transaction closure comprises of a set of transactions which are tran-sitively initiated by the same (root) transaction. In contrast to nested transactions,a child transaction in a transaction closure may survive the termination of its parenttransaction | a case which is needed for example in models for long-during activities[DHL91, RKT+95], work ows [GHS95, KR96], or in active databases [HLM88, B�OH+92].Termination dependencies play a central role in transaction closures. A terminationdependency is a constraint on the possible combinations (and orders) of the termina-tion events (commit/abort) of two related transactions. In transaction closures, theframework for termination dependencies has to be extended in comparison to nestedtransactions. Besides the termination combinations, one has to consider, for instance,the e�ects of compensating transactions on termination dependencies. Whereas the ter-mination condition for direct child transactions are explicitly speci�ed, the conditions fortransitively related transactions have to be computed based on the direct dependencies.In this paper, we present a framework for handling termination conditions for tran-sitive ancestor relations in transaction closures. Here, we also consider the aspect oftransaction compensation. The formalization of transaction closures and dependenciesis based on the ACTA framework presented in [CR90, CR91, CR94]. The result is apractical algorithm for computing derived dependencies for transitively related transac-tions. Furthermore, the rules obtained by this algorithm together with the concept of

2transaction closure and the basic dependencies provide the basis for a transaction designand analyzing tool. Such a tool can help to understand the entire semantics of a complexapplication and thus it may support the design of better and more e�cient applications.The paper is organized as follows: In Section 2, we introduce the notion of transactionclosure. Thereafter, in Section 3, we discuss transaction termination dependencies whichdeal with valid combinations of termination events (commit and abort) of related trans-actions of a transaction closure. Furthermore, the e�ect of transaction compensation ontermination dependencies is analyzed. In Section 4, we consider the transitivity of thedependencies introduced and develop an algorithm for deriving all valid combinations ofdependencies for a given transitive dependency. The application of transaction closures,especially the derivation of transitive dependencies in transaction closures, is shown byan example in Section 5. Finally, the paper is concluded by an outlook on future work.

Chapter 2. The Notion of Transaction Closures 3Chapter 2The Notion of Transaction ClosuresTraditionally, advanced transaction models base on the idea of nesting transactions.A nested transaction [Mos85] is a transaction consisting of several transactions calledchild transactions. These child transactions are initiated within a transaction. Theinitiating transaction is called parent. A child transaction itself may consist of other childtransactions, i.e., a nested transaction forms a transaction tree. However, activity models[DHL91] or work ow models [KR96] require a more general framework for describing setsof related transactions. The same holds for execution models of active database systems[HLM88]. We introduce the notion of transaction closure as a generalized transactionstructure allowing greater independence between constituting transactions.A transaction closure consists of a set of transactions which are transitively initiatedby the same (root) transaction, i.e., there are parent-child relationships between transac-tion pairs of a transaction closure. The transactions of a transaction closure are furtherinterrelated by the dependencies we discuss in the following chapters. For example, achild transaction in a transaction closure may leave the scope of its parent transactionbecause of a special termination dependency between them. By using transaction clo-sures (in connection with the various dependency types) we have a uniform frameworkfor describing traditional as well as advanced transaction models, particularly activityand work ow models. For the de�nition of the notion of a transaction closure we �rstde�ne some basic notions.De�nition 2.0.1 The following self-explanatory functions and predicates describe gen-eral relationships between a transaction and its initiator:parent(ti; tj) := ( ti is parent of tj )root(tj) := ( tj has no parent )ancestor(ti; tj) := ( parent(ti; tj) _ (9tk : ancestor(ti; tk) ^ parent(tk; tj)) )The relationship between the initiation of two transactions can be expressed by a begindependency. For our de�nitions we use the ACTA formalism [CR90, CR91, CR94, RC97],including the fundamental dependency de�nitions such as the abort dependency and

4exclusive dependency and the notion of a history of transactions [BHG87, GR93] (in thefollowing formulas denoted as H). A single arrow (!) denotes temporal sequence.Begin Dependency (ti BD tj). A transaction ti can be initiated only if transaction tjis already initiated: (beginti 2 H)) (begintj ! beginti)De�nition 2.0.2 (Transaction Closures) Suppose tc denotes a set of transactions ofa transaction closure and let ti and tj be two transactions of this closure:� Each transaction closure has exactly one1 root transaction:9! ti 2 tc : root(ti)� Each non-root transaction has exactly one parent transaction:8tj 2 tc : :root(tj)) (9! ti 2 tc : parent(ti; tj))� Each transaction closure is acyclic:6 9ti 2 tc : ancestor(ti; ti)� The initiation of a transaction must follow the initiation of the parent:8tj 2 tc : :root(tj)) (9ti 2 tc : parent(ti; tj) ^ (tj BD ti))In the following chapters, we discuss di�erent termination dependencies between transac-tions of a transaction closures. These dependencies have to be de�ned (at least) betweena transaction and its parent. As we will see later, these dependencies have transitivelye�ects on the other transactions of the closure.

1The symbol 9! stands for \it exists exactly one".

Chapter 3. Termination Dependencies in Transaction Closures 5Chapter 3Termination Dependencies inTransaction ClosuresIn addition to the begin dependency, there are several dependencies among transactionsof a transaction closure. In this paper we concentrate on termination dependencieswhich are constraints on the occurrence of the signi�cant termination events and showthe derivation of transitive termination dependencies.3.1 Basic Termination DependenciesInvestigating constraints on the occurrence of the signi�cant termination events commitand abort leads to di�erent termination dependencies. In case of two transactions ti andtj there are four possible combinations of termination events:(1) both transactions abort (ati , atj )(2/3) one transaction commits whereas the other one aborts (ati , ctj )/(cti , atj )(4) both transactions commit (cti , ctj )These termination event combinations may be valid in any order (denoted by p) or arenot valid (denoted by |). Obviously, there are at most sixteen possible dependencieswhich are formed by di�erent values for the termination event combinations, e.g. allcombinations are valid (see the last column in Table 3.1). Under the assumption that atransaction may be forced to abort but not to commit, the number of possibly reasonabletermination dependencies is reduced to at most eight. This is due to the fact that theabortion of both transactions is considered as valid event combination for all dependen-cies. We identify �ve of the eight dependencies as reasonable according to real-worldapplication semantics. These dependencies are summarized in Table 3.1.The remaining three dependencies are inapplicable according to real-world applicationsemantics. These are the cases (1) in which only the abortion of both transactions is

6 3.1. Basic Termination Dependenciesti tj vital dep(ti; tj) vital(ti; tj) dep(ti; tj) exc(ti; tj) indep(ti; tj)ati atj p p p p pati ctj | | p p pcti atj | p | p pcti ctj p p p | pTable 3.1: Termination Dependencies between two Transactions ti and tjvalid, and (2 and 3) in which the abortion of one transaction and the commitment of theother transaction are valid in addition to the �rst case. The dependency where only theabortion of both transaction is valid makes no sense because in this case no transaction isallowed to commit. In other words, if transactions are only allowed to abort, they do notneed to be executed. The last two dependencies are also not reasonable because in thesecases always one of the related two transactions is not allowed to commit, independentlyof the termination event of the other transaction.After having discussed the non-reasonable termination event combinations, we willnow de�ne the termination dependencies which are the basis for the reasonable termi-nation events combinations.Abort Dependency (tiAD tj). If transaction tj aborts, then transaction ti has toabort, too: (aborttj 2 H)) (abortti 2 H)Exclusive Dependency (ti ED tj). If transaction tj commits, then transaction ti hasto abort: (committj 2 H)) (abortti 2 H)A dependency between two transactions ti and tj which requires that both transactionseither abort or commit together is called vital-dependent.De�nition 3.1.1 (Vital-Dependent) Two di�erent transactions ti and tj are vital-dependent on each other if and only if both transactions are abort dependent on eachother: vital dep(ti; tj) :, (tiAD tj) ^ (tj AD ti)The vital-dependent dependency is (as the name suggests) a combination of the depen-dencies vital and dependent which are de�ned below.De�nition 3.1.2 (Vital) A transaction ti is vital for another transaction tj if and onlyif tj is abort dependent on ti:vital(ti; tj) :, (tjAD ti)

Chapter 3. Termination Dependencies in Transaction Closures 7Thus, the vital dependency between two transactions ti and tj concerns the case wherethe abortion of transaction ti leads to the abortion of transaction tj. In comparison to avital transaction, a dependent transaction tj has to abort if transaction ti aborts. Thus,the termination event of transaction ti is necessary for an acceptable outcome accordingto the semantics of the application. In contrast, the results of transaction tj are notessential for the application.De�nition 3.1.3 (Dependent) A transaction ti is dependent on another transactiontj if and only if ti is abort dependent on tj:dep(ti; tj) :, (tiAD tj)From the De�nitions 3.1.2 and 3.1.3 directly follows that either vital or dependent isnot required because these dependencies can be substituted by each other (vital(ti; tj) �dep(tj; ti)). This observation is true if we do not consider combinations of termina-tion dependencies with other kinds of dependencies, e.g. the so-called object visibilityconstraints which determine when results of a transaction are made visible to othertransactions. The combination of termination dependencies with object visibility de-pendencies leads to di�erent results for vital(ti; tj) and dep(tj; ti) due to the fact that atransaction which make its e�ects only visible to its parent requires that its terminationprecedes the commitment of the parent. In other words, the parent transaction has towait for the termination of such a child transaction to get the child's results. Since thedependent and vital termination dependencies cannot be substituted in this case, weexplicitly distinguish these two termination dependencies.A completely di�erent dependency is the exclusive dependency. Here, only one ofthe transactions is allowed to �nish successfully. This dependency may be useful, forinstance, in real-time applications where two alternative transactions are executed inparallel and the results of the transaction which �nishes at �rst are accepted and theresults of the other one is aborted after that.De�nition 3.1.4 (Exclusive) Two di�erent transactions ti and tj are exclusive foreach other if and only if both transactions are exclusive dependent on each other:exc(ti; tj) :, (ti ED tj) ^ (tj ED ti)Our �fth dependency concerns the case where each combination of transaction termi-nation events is valid. Therefore, the involved transactions are denoted as independent.Concurrently executed transactions without any constraints on the occurrence of thetermination events are independent. A possible scenario for independent transactionsis the situation in which two di�erent sources o�er the same service and two (or more)transactions are executed in parallel to get the required results.De�nition 3.1.5 (Independent) Two di�erent transactions ti and tj are independentif all termination event combinations of ti and tj are allowed. This case is denoted asindep(ti; tj).

8 3.2. Influence of Transaction CompensationAfter having a closer look on the de�nitions above, we can conclude that vital(ti; tj) isequivalent to dep(tj; ti). In other words, transaction ti is vital for tj if and only if tj isdependent on ti and vice versa. In contrast, the other dependencies are symmetrical (byde�nition).Theorem 3.1.6 The following relationships hold for dependencies between two transac-tions ti and tj: vital dep(ti; tj) � vital(ti; tj) ^ dep(ti; tj) (3.1)vital dep(ti; tj) � vital dep(tj; ti) (3.2)vital(ti; tj) � dep(tj; ti) (3.3)exc(ti; tj) � exc(tj; ti) (3.4)indep(ti; tj) � indep(tj; ti) (3.5)3.2 In uence of Transaction Compensation on Ter-mination DependenciesIn this section, we will see that the termination dependencies can be weakened whentransaction compensation is supported. Transaction compensation is the ability to se-mantically undo the e�ects of a transaction ti by a compensating transaction comptiin order to achieve semantic atomicity [Gar83]. If there exists such a compensatingtransaction compti for a transaction ti, ti is denoted as compensatable.The basic termination dependencies de�ned in Section 3 base on the abort depen-dency and the exclusive dependency, respectively. If transaction compensation is con-sidered, these dependencies are weakened to the weak-abort dependency1 and the weak-exclusive dependency, respectively.Weak-Abort Dependency (tiWAD tj). If transaction ti commits and transaction tjaborts, then the commitment of ti precedes the abortion of tj and the compensatingtransaction compti of ti has to commit:((aborttj 2 H) ^ (committi 2 H))) (committi ! aborttj ^ (commitcompti 2 H))In contrast to an abort dependent transaction, a weak-abort dependent transaction cancommit without waiting for the commit of the other transaction. In case the othertransaction aborts, the \committed" e�ects of the weak-abort dependent transaction aresemantically undone by executing a compensating transaction.1Please note that our de�nition of the weak-abort dependency di�ers from the weak-abort dependency(tiWD tj) de�ned in [CR94], because we here integrate the aspect of compensation.

Chapter 3. Termination Dependencies in Transaction Closures 9Weak-Exclusive Dependency (tiWED tj). If both transactions ti and tj commit,then the compensating transaction compti of ti has to commit, too:((committj 2 H) ^ (committi 2 H))) (commitcompti 2 H)In comparison to the exclusive dependency, the weak-exclusive dependency (tiWED tj)only demands that the compensating transactions of ti must commit in case both trans-actions ti and tj are committed. Thus, the case where both transactions can commit isallowed under the restriction that transaction ti is compensatable.By using the weakened versions of the abort and the exclusive dependency, we nowrede�ne the termination dependencies under the consideration that the related trans-actions are compensatable (at least one of them). For the symmetrical dependencyvital dep(ti; tj) we have to distinguish three cases: (1) vital depJ(ti; tj) if only ti is com-pensatable, (2) vital depI(ti; tj) if only tj is compensatable, and (3) vital dep�(ti; tj) ifboth ti and tj are compensatable.De�nition 3.2.1 (Vital-DependentJ) Two transactions ti and tj are vital-dependentJ on each other if and only if ti is weak-abort dependent on tj and tj isabort dependent on ti:vital depJ(ti; tj) :, (tiWAD tj) ^ (tj AD ti)De�nition 3.2.2 (Vital-DependentI) Two transactions ti and tj are vital-dependentI on each other if and only if ti is abort dependent on tj and tj is weak-abortdependent on ti: vital depI(ti; tj) :, (tiAD tj) ^ (tjWAD ti)De�nition 3.2.3 (Vital-Dependent�) Two transactions ti and tj are vital-dependent� on each other if and only if both transactions are weak-abort dependenton each other: vital dep�(ti; tj) :, (tiWAD tj) ^ (tjWAD ti)For the asymmetric relationships vital and dependent, only one direction has to behandled.De�nition 3.2.4 (VitalI) A transaction ti is vitalI for another transaction tj if andonly if tj is weak-abort dependent on ti:vitalI(ti; tj) :, (tjWAD ti)In other words, if vitalI(ti; tj) holds, then transaction ti is vital for the compensatabletransaction tj.

10 3.2. Influence of Transaction CompensationDe�nition 3.2.5 (DependentJ) A transaction tj is dependentJ on another transac-tion ti if and only if ti is weak-abort dependent on tj:depJ(ti; tj) :, (tiWAD tj)In other words, if depJ(ti; tj) holds, then the compensatable transaction ti is dependenton tj.As in the vital-dependent case, we have also to distinguish three cases for the exclusivedependency.De�nition 3.2.6 (ExclusiveJ) Two transactions ti and tj are exclusiveJ if and onlyif ti is weak-exclusive dependent on tj:excJ(ti; tj) :, (tiWED tj)De�nition 3.2.7 (ExclusiveI) Two transactions ti and tj are exclusiveI if and onlyif tj is weak-exclusive dependent on ti:excI(ti; tj) :, (tjWED ti)De�nition 3.2.8 (Exclusive�) Two transactions ti and tj are exclusive� for eachother if and only if either ti is weak-exclusive dependent on tj or tj is weak-exclusivedependent on ti: exc�(ti; tj) :, (tiWED tj) _ (tjWED ti)ti tj vital dep�(ti; tj) vital depJ(ti; tj) vital depI(ti; tj) vitalI(ti; tj)ati atj p p p pati ctj ctj ! ati ^ ccomptj | ctj ! ati ^ ccomptj ctj ! ati ^ ccomptjcti atj cti ! atj ^ ccompti cti ! atj ^ ccompti | pcti ctj p p p pti tj exc�(ti; tj) excJ(ti; tj) excI(ti; tj) depJ(ti; tj)ati atj p p p pati ctj p p p pcti atj p p p cti ! atj ^ ccompticti ctj ccompti _ ccomptj ccompti ccomptj pTable 3.2: Relaxed Termination DependenciesConsidering transaction compensation the basic termination dependencies are relaxed.All disallowed �elds (except the two �elds in vital depJ(ti; tj) and vital depI(ti; tj),

Chapter 3. Termination Dependencies in Transaction Closures 11respectively) are replaced by a constraint on the termination order of the related trans-actions or by the requirement that there must be a committed compensating transaction(compare Table 3.1 and Table 3.2). These e�ects are due to the usage of the weak-abortand weak-exclusive dependencies instead of the basic abort and exclusive dependencies.From the De�nitions 3.2.3 to 3.2.8, we can derive the following theorem.Theorem 3.2.9 The following relationships hold for dependencies between two transac-tions ti and tj: vital dep�(ti; tj) � vitalI(ti; tj) ^ depJ(ti; tj) (3.6)vital depJ(ti; tj) � vital(ti; tj) ^ depJ(ti; tj) (3.7)vital depI(ti; tj) � vitalI(ti; tj) ^ dep(ti; tj) (3.8)vital dep�(ti; tj) � vital dep�(tj; ti) (3.9)vital depJ(ti; tj) � vital depI(tj; ti) (3.10)vitalI(ti; tj) � depJ(tj; ti) (3.11)exc�(ti; tj) � exc�(tj; ti) (3.12)excJ(ti; tj) � excI(tj; ti) (3.13)Up to now, we have discussed termination dependencies with and without compensation.The following section investigates the transitivity of the dependencies introduced sofar. The transitivity is fundamental for deriving the relationship between two arbitrarytransactions of a transaction closure. In particular, it is required to reason about theconsequences of a transaction's abortion on the other transactions.

12 3.2. Influence of Transaction Compensation

Chapter 4. Transitivity of Termination Dependencies 13Chapter 4Transitivity of TerminationDependenciesA termination dependency may have a transitive in uence on other transactions of thetransaction closure. Suppose, X is a termination dependency between the transactionsti and tk and Y a dependency between the transactions tk and tj, then the combinationof these two dependencies leads to a transitive dependency Z between the transactionsti and tj; i.e., X(ti; tk) ^ Y (tk; tj)) Z(ti; tj) holds.

Z (t ,t )ji

X (t ,t )ki

t

t i jt

kY (t ,t )j

kFigure 4.1: Example of a Transitive DependencyOur approach is now to �nd all valid combinations of dependencies X and Y for a giventransitive dependency Z (see Figure 4.1). For that, we analyze the basic relationshipsbetween the dependencies introduced so far. Based on the results how two dependenciescan be combined, we present a method for deriving all valid combinations of dependenciesX and Y for a transitive dependency Z. These valid dependency combinations resultin rules which are the basis for a tool to assist the transaction designer in specifyingtransaction closures.4.1 Foundations of Derived DependenciesBefore introducing the method to derive all valid combinations of dependencies for agiven transitive dependency, we have to investigate the following basic formula in more

14 4.1. Foundations of Derived Dependenciesdetail: X(ti; tk) ^ Y (tk; tj)) Z(ti; tj) (4.1)Concerning the possible termination event combinations, we distinguish �ve possibilitiesfor the application of the dependencies X, Y , and Z on a pair of transactions (denotedby the following symbols): The combination of termination events is not valid. In this case both transactionsare non-compensatable.� The termination event combination is valid (independent of the termination orderand compensation properties) for a dependency.� The combination of termination events is valid under the restriction that com-pensation of one of the two related transactions is possible. In this case bothtransactions have to be compensatable.J, I In comparison to �, in this case only one of the two related transactions is com-pensatable. The direction of the triangle indicates the transaction which has to becompensatable.The usage of this symbols is illustrated in Table 4.1 (cf. Table 3.2).ti tj vital dep�(ti; tj) vital depJ(ti; tj) vital depI(ti; tj) vitalI(ti; tj)ati atj � � � �ati ctj I I Icti atj J J �cti ctj � � � �ti tj exc�(ti; tj) excJ(ti; tj) excI(ti; tj) depJ(ti; tj)ati atj � � � �ati ctj � � � �cti atj � � � Jcti ctj � J I �Table 4.1: Graphically Representation of Termination Dependencies with CompensationThe transactions ti, tj, and tk of the dependencies X(ti; tk), Y (tk; tj), and Z(ti; tj) mayeither abort or commit. Thus, there are four possible termination event combinationsfor each dependency: X(ti; tk) 7! x(a;a) _ x(a;c) _ x(c;a) _ x(c;c)Y (tk; tj) 7! y(a;a) _ y(a;c) _ y(c;a) _ y(c;c)Z(ti; tj) 7! z(a;a) _ z(a;c) _ z(c;a) _ z(c;c)

Chapter 4. Transitivity of Termination Dependencies 15where x(a;a); x(a;c); x(c;a); x(c;c); y(a;a); y(a;c); y(c;a); y(c;c); z(a;a); z(a;c); z(c;a); z(c;c) 2 f;�;�;J;Ig.As represented in Table 4.2, there are altogether eight possible termination eventcombinations for three transactions ti, tj, and tk. These termination event combinationsare set into formula (4.1).ti tk tj X(ti; tk) ^ Y (tk; tj)) Z(ti; tj)a a a x(a;a) ^ y(a;a) ) z(a;a)a a c x(a;a) ^ y(a;c) ) z(a;c)a c a x(a;c) ^ y(c;a) ) z(a;a)a c c x(a;c) ^ y(c;c) ) z(a;c)c a a x(c;a) ^ y(a;a) ) z(c;a)c a c x(c;a) ^ y(a;c) ) z(c;c)c c a x(c;c) ^ y(c;a) ) z(c;a)c c c x(c;c) ^ y(c;c) ) z(c;c)Table 4.2: Termination Event Combinations for Transitive DependenciesFrom the results represented in Table 4.2 we derive the following integrated formulas:(x(a;a) ^ y(a;a)) _ (x(a;c) ^ y(c;a)) ) z(a;a) (4.2)(x(a;a) ^ y(a;c)) _ (x(a;c) ^ y(c;c)) ) z(a;c) (4.3)(x(c;a) ^ y(a;a)) _ (x(c;c) ^ y(c;a)) ) z(c;a) (4.4)(x(c;a) ^ y(a;c)) _ (x(c;c) ^ y(c;c)) ) z(c;c) (4.5)The formulas above are the basis for deriving transitive dependencies. The conjunction(^) and disjunction (_) of two dependencies x and y is de�ned in Table 4.3.x y (x ^ y) (x _ y) � � I I J J � � � � � �� I I �� J �� � I �� �x y (x ^ y) (x _ y)J � J �J I � �J J J JJ � � �J JI � �I I I II J �I � I �I I

x y (x ^ y) (x _ y)� � J �� I � �� J J �� � � �� �Table 4.3: Conjunction and Disjunction of x and yFrom Table 4.3 follows that is stronger than (�;J;I), whereas (�;J;I) are strongerthan �. However, in the case of combinations with (�;J;I) we have to consider the

16 4.2. Computing Valid Dependency Combinationsdirection of this dependency. The �-symbol can be seen as a combination of J and I.For the ^-connectivity we have to �nd a way along the two triangles to get a triangleas result, e.g. I and I leads to I, whereas I and J leads to . In case one of theelements is �, the way along the plus and the triangle has to end at a triangle of thesame direction, e.g. � and I leads to I, whereas � and J leads to .The reason for these results is that the connection of two symbols by an ^-operatoris a combination of a termination events of transactions ti, tk, and tj. The �rst symbolrepresents the connection between the termination events of ti and tk and the second oftk and tj. Obviously, the termination event of tk has to be the same in both cases. Thecombination of a I and J (tk is compensatable) cannot lead to one of the compensatingsymbols (�;J;I), because neither ti nor tj are compensatable in this case. The resultingsymbol is because we have to set a stronger constraint on the termination eventcombination than the possibility of compensation represented by a triangle.Using the rules represented in Table 4.3 and the formulas (4.2){(4.5), we are able toderive the transitive dependency Z for a given dependency pair X and Y . We demon-strate this for the following example. Suppose, there are three transactions ti, tk, and tjwhich are connected by the following dependencies:vital depJ(ti; tk) ^ vital depI(tk; tj)Table 4.1 illustrates the symbols for the termination event combinations of the termina-tion dependencies. Setting these symbols in the formulas (4.2){(4.5) results in a patternwhich indicates that the derived dependency is vital dep�(ti; tj):(� ^�) _ ( ^ ) ) �(�^ I) _ ( ^ �) ) I(J ^�) _ (� ^ ) ) J(J ^ I) _ (� ^ �) ) �In conclusion, using the rules represented in Table 4.3 and the formulas (4.2){(4.5), wecan derive for each pair of termination dependencies X(ti; tk) and Y (tk; tj) the corre-sponding transitive termination dependency Z(ti; tj).4.2 Computing Valid Dependency Combinations fora Transitive DependencyThe considerations in the previous section are the basis for an algorithm which deter-mines all valid combinations of dependencies X and Y for a given transitive depen-dency Z. In detail, we start with the given dependency Z(ti; tj), e.g. vital dep�(ti; tj),which represents a collection of symbols for di�erent termination event combination,e.g. z(a;a) = �, z(a;c) =I, z(c;a) =J, and z(c;c) = �. The following general form of the

Chapter 4. Transitivity of Termination Dependencies 17formulas (4.2){(4.5) build the basis for the evaluation of the values of xa; yb; xc, and ydof the dependencies X and Y with a given symbol zm:((xa ^ yb) _ (xc ^ yd))) zmWe try to �nd the minimal set of values (symbols) for xa, yb, xc, and yd which ful�ll theformula above. Computing the transitive event combination zm is done for each symbolseparately in a step of the following algorithm:procedure Deriving Dependency Combinations

// Input: Transitive Dependency Z// Output: Set of Dependency Combinations X and Y which// imply Z

initialize;repeatrepeat

compute (invalid terms);compute � (valid terms);

until (no new results evaluated);compute � (symmetrical compensating terms);compute J (left-hand compensating terms);compute I (right-hand compensating terms);

until (no new results evaluated);compute consistent dependency combinations;

end;The algorithm mainly consists of a nested loop. In the inner loop the evaluation rulesfor valid (zm = �) and invalid terms (zm = ) are applied until no new results for xa ,yb, xc, and yd can be generated. Then the rules of the compensating terms (zm = �;J orI) are executed. If this leads to further results, the loop for the valid and invalid termsis executed again. After the nested loop the results have to be adjusted with respect tocompensation. In the following the single steps are described in detail:Initializing: We start with the initialization of x(a;a) and y(a;a) which are valid (�) byde�nition. There is no dependency where the abortion of both transactions is notvalid.After the initialization we continue with the steps of computing single terms for the fourzm. In these steps of the algorithm we have to consider the following general observationrules:1. Due to the fact that xa represents x(a;a) and x(c;a) and the de�nition of the termina-tion dependencies (cf. Table 4.1), there are only the three possible values ;�;Jfor xa. In contrast, yb stands for y(a;a) and y(a;c). Thus, there are the followingthree possible values ;�;I for yb.

18 4.2. Computing Valid Dependency Combinations2. The value � appears only within the exc� dependency in the case that both trans-actions commits. Therefore, only x(c;c) and y(c;c) are candidates for the value �.Compute Invalid Terms (zm = ): To guarantee that zm is invalid, the followingterm (xa ^ yb) _ (xc ^ yd)| {z }has to evaluated to the invalid value according to the rules presented in Table 4.41which is a reduced version of Table 4.3.x ^ y ^ ?? ^ � ^ JI ^ JI ^ �x _ y _ Table 4.4: Evaluation of Invalid TermsFrom the rules in Table 4.4 follows, both terms (xa ^ yb) and (xc ^ yd) have toevaluate to a invalid value in order to get as a result of the disjunction. Each ofthese terms is again , if one of its elements, e.g. xa or yb, is or xa is � and ybis J. We de�ne the following evaluation rules:� If an element of a conjunction is �, then the other one has to be .� If the �rst element of a term (xa or xc) is J, then the other one has to be .� If the �rst element of a term is I, then the other one has to be ;� orJ.� If the �rst element of a term is �, then the other one has to be or J.� If the second element of a term (yb or yd) is J, then the other one has to be, � or I.� If the second element of a term is I, then the other one has to be .� If the second element of a term is �, then the other one has to be or I.� From the general observation rules xa 2 f;�;Jg and yb 2 f;�;Ig followsthat either xa or yb has to be .Compute Valid Terms (zm = �): To guarantee that zm is valid, the term(xa ^ yb) _ (xc ^ yd)| {z }�

Chapter 4. Transitivity of Termination Dependencies 19x ^ y� ^ �� x _ y� _ ?? _ ��Table 4.5: Evaluation of Valid Termshas to be evaluated to the valid value � according to the rules presented in Ta-ble 4.5.As represented in Table 4.5, either term (xa^yb) or term (xc^yd) have to evaluateto a valid value (one of them or both) to get � as a result of the disjunction. Onthe other hand, each term is valid, if both of its elements (xa and yb and xc andyd, respectively) are �. Therefore, we de�ne the following evaluation rules:� If an element of a term is not �, then the other term has to be � and, thus,both elements of this term has to be �.� If an element of each term is �, then one of the other has to be �, too.Compute Symmetrical Compensating Terms (zm = �): To guarantee that zm iscompensatable in both directions, the term(xa ^ yb) _ (xc ^ yd)| {z }�has to be evaluated to the compensating value � using the rules presented inTable 4.6. x ^ y�, J ^ �, I� x _ yI _ �, JJ _ �, I� _ , �, J, I�Table 4.6: Evaluation of a Symmetrical Compensating TermFrom the results in Table 4.6 follows that one of the terms (xa ^ yb) and (xc ^ yd)has to evaluate to � and the other one to I, J, �, or , or the �rst term evaluatesto J (I) and the second one to I (J). Each term is �, if the �rst element is J or� and the other element is � or I.� If an element of a term is , then the other term has to be �.� If (xa^yb) is �, then xa is set to J and yb to I due to the general observationrules that xa 2 f;�;Jg and yb 2 f;�;Ig.1The ?-symbol stands for \don't care".

20 4.2. Computing Valid Dependency Combinations� If xa or yd is �, then the term evaluates to I or and the other term has tobe �.� If yb is �, then the term evaluates to J or and the other term has to be �or I.� If xc is �, then the term evaluates to I or and the other term has to be �or J.� If both yb and xc are valid (�), then the �rst term has to evaluate to J (setxa to J) and the second to I (set yd to I or �).Compute Left-hand Compensating Terms (zm =J): To guarantee that zm is validwith a compensatable transaction ti, the term(xa ^ yb) _ (xc ^ yd)| {z }Jhas to be evaluated to the compensating valueJ according to the rules in Table 4.7.x ^ y�, J ^ �, JJ x _ yJ _ J, _ JJTable 4.7: Evaluation of a Left-hand Compensating TermAs represented in Table 4.7, one of the terms (xa^yb) and (xc^yd) has to evaluateto J and the other one has to evaluate to J or . Each term is J, if its �rstelement is J or �, and the second element is J or �. Consequently, we derive thefollowing evaluation rules:� If an element of a term is and, thus, the whole term is , the other termhas to be J.� If (xa^yb) has to evaluate to J, then xa has to be set to J and yb to � becausexa cannot evaluate to � and yb cannot be J due to the general observationrules.� If element xa is �, then the term cannot evaluate to J and has to evaluateto . This is only possible if yb evaluates to .� If element yb is �, then xa may be either J or � (if the general observationrules are ful�lled). Additionally, xa may be when the other term (xc ^ yd)may evaluate to J.� If xc is �, then the term has to evaluate to and yd has to be or J.

Chapter 4. Transitivity of Termination Dependencies 21Compute Right-hand Compensating Terms (zm =I): To guarantee that zm isvalid with a compensatable transaction tj, the term(xa ^ yb) _ (xc ^ yd)| {z }Ihas to be evaluated to the right-hand compensatable value I according to the rulesin Table 4.8. x ^ y�, I ^ �, II x _ yI _ I, _ IITable 4.8: Evaluation of a Right-hand Compensating TermFrom the rules in Table 4.8 follows that one of the terms (xa^yb) and (xc^yd) hasto evaluate to I and the other one to I or . Each term is I, if the �rst element(xa or xc) is � or I and the other element (yb or yd) is � or I. Thus, we de�nethe following evaluation rules:� If an element of a term is , then the other term has to be I.� If (xa^yb) has to evaluate to I, then xa has to be set to � and yb to I becausexa cannot evaluate to a J and yb not to � due to the general observation rules.� If element yb is �, then the term cannot be evaluated to I and has to beevaluated to . This is only possible if xa is evaluated to .� If element xa is �, then yb may be either I or � (if the general observationrules are ful�lled). Additionally, yb may be when the other term (xc ^ yd)may evaluate to I.� If yd is �, then the term has to evaluate to and xc has to be or I.Compute Consistent Dependency Combinations: After the nested loop of the al-gorithm the results for the termination event combination of X and Y are com-bined to possible dependencies X(ti; tk) and Y (tk; tj). In this step, these set ofdependencies are adjusted with respect to the compensation property. In caseone of the involved transactions is compensatable, this property must be re ectedin all corresponding dependencies. For example, if the transactions ti and tk arecompensatable and vital-dependent for each other, then the related dependencyis vital dep�(ti; tk) and not vital depJ(ti; tk), vital depI(ti; tk), or vital dep(ti; tk).In conclusion, we can only build dependency combinations of X(ti; tk) and Y (tk; tj)where the compensation property of transaction tk is re ected in both dependen-cies. For example, a combination of vital dep�(ti; tk) and vital(tk; tj) is not valid.In contrast, vital depJ(ti; tk) and vital(tk; tj) is a valid dependency combination.In this case tk is non-compensatable.

22 4.3. Exemplary Application of the AlgorithmThe algorithm described in this section produces a set of rules (see Appendix A) includingall reasonable and consistent dependency combinations.4.3 Exemplary Application of the AlgorithmThe following example shall illustrate our algorithm for evaluating valid combinations ofdependencies for a given transitive dependency.Example 4.3.1 Let ti, tk, and tj be transactions and vital dep�(ti; tj) the given depen-dency Z. According to the Tables 4.1, z(a;a) is set to �, z(a;c) to I, z(c;a) to J, and z(c;c)to �. In this case we have to evaluate two valid terms, one right-hand and one left-handcompensating term. Below we demonstrate how our algorithm produces valid dependencycombinations for the given transitive dependency.1. Initializing: By de�nition the abortion of both transactions is allowed for alldependencies, i.e., x(a;a) and y(a;a) are always initialized with �. Thus, the followingformulas has to be ful�lled:(x(a;a)| {z }� ^ y(a;a)|{z}� ) _ (x(a;c) ^ y(c;a)) ) �(x(a;a)| {z }� ^ y(a;c)) _ (x(a;c) ^ y(c;c)) ) I(x(c;a) ^ y(a;a)|{z}� ) _ (x(c;c) ^ y(c;a)) ) J(x(c;a) ^ y(a;c)) _ (x(c;c) ^ y(c;c)) ) �2. Compute Valid Terms: Because there are no invalid terms we start with thevalid terms. The �rst valid term directly evaluates to � because the terms (x(a;a) ^y(a;a)) evaluates to � and the disjunction of a � and another value also evaluatesto �. Without any intermediate results for x(c;a), y(a;c), x(c;c), and y(c;c), we cannotderive whether the last formulas is valid or not. Thus, there are no new results andwe continue with the computation of the compensating terms.3. Compute Left-hand Compensating Term: The term (x(c;a) ^ y(a;a)) can onlybe evaluated to J, if x(c;a) is set to J or �. However, the second general observationrule says that only x(c;c) and not x(c;a) could evaluate to �. Furthermore, x(c;a) maybe set to when the other term (x(c;c) ^ y(c;a)) evaluates to J (see the evaluationrules for left-hand compensating terms):(x(c;a)|{z}J; ^ y(a;a)|{z}� ) _ (x(c;c) ^ y(c;a))| {z }J; ) J

Chapter 4. Transitivity of Termination Dependencies 234. Compute Right-hand Compensating Term: The evaluation of the right-handcompensating term is similar to the left-hand compensating term. The intermediateresults are as follows: (x(a;a)| {z }� ^ y(a;c)|{z}I; ) _ (x(a;c) ^ y(c;c))| {z }I; ) IWe cannot derive further values for the variables of the compensating terms. Thus,we leave this loop and return to the �rst loop where the valid and invalid terms areevaluated again.5. Compute Valid Term: The disjunction of the last formula evaluates only to �,if (x(c;a) ^ y(a;c)) or (x(c;c) ^ y(c;c)) evaluates to �. However, two steps before wederived that x(c;a) may only be either J or and y(a;c) either I or . Thus, theconjunction (x(c;c) ^ y(c;c)) has to be � (see evaluation rules for valid terms). Thisis done by setting both elements to �:(x(c;a)|{z}J; ^ y(a;c)|{z}I; ) _ (x(c;c)| {z }� ^ y(c;c)|{z}� )| {z }� ) �6. Compute Left-hand Compensating Term: We may derive further resultsfor the left-hand compensating term by considering the values determined in thestep before. The conjunction (x(c;c) ^ y(c;a)) cannot be evaluated to J because the�rst element x(c;c) is �. Thus, this term has to evaluate to and the other term(x(c;a)^y(a;a)) to J in order to �nally derive a J for the corresponding disjunction.For that x(c;a) is set to J. Furthermore, y(c;a) is set to or J to evaluate theconjunction to . In summary the following values are determined:(x(c;a)|{z}J ^ y(a;a)|{z}� )| {z }J _ (x(c;c)|{z}� ^ y(c;a)|{z}J; )| {z } ) J7. Compute Right-hand Compensating Term: The evaluation of the right-handcompensating term is again similar to the left-hand compensating term. The resultsare as follows: (x(a;a)| {z }� ^ y(a;c)|{z}I )| {z }I _ (x(a;c)| {z }I; ^ y(c;c)|{z}� )| {z } ) IThe result of the nested loop of the algorithm is represented in Figure 4.2. Thereare two possibilities for the dependencies X and Y . The dependency X may beeither vital depJ(ti; tk) or vital dep�(ti; tk) and the dependency Y may be eithervital depI(tk; tj) or vital dep�(tk; tj). Thus, there are four possible dependencycombinations for Z.

24 4.3. Exemplary Application of the Algorithmt

jivital_dep (t ,t )◆

vital_dep (t ,t ) i k▼

▼

▼

i j

i kvital_dep (t ,t ) X (t ,t )ki Y (t ,t )

t

k

t

◆

k

j ◆ kvital_dep (t ,t )

k▼vital_dep (t ,t )j

j

▼

▼

▼

▼Figure 4.2: Evaluating the Transitive Dependency vital dep�8. Compute Consistent Dependency Combinations: The combinationsvital dep�(ti; tk) with vital depI(tk; tj) and vital depJ(ti; tk) with vital dep�(tk; tj)are not valid because transaction tk is contradictory speci�ed with respect to thecompensation property. In one dependency tk is de�ned as compensatable whereasin the other dependency it is de�ned as non-compensatable. In conclusion, thefollowing two valid dependency combinations are evaluated for the transitive de-pendency vital dep�(ti; tj):vital dep�(ti; tk) ^ vital dep�(tk; tj) ) vital dep�(ti; tj)vital depJ(ti; tk) ^ vital depI(tk; tj) ) vital dep�(ti; tj)

Chapter 5. Application of the Transitivity Rules 25Chapter 5Application of the TransitivityRules in an Example ScenarioThe following examples are intended to clarify the application of transaction closuresand the derivation of transitive termination dependencies in such transaction closures.The transaction closure in our �rst example can be considered as a work ow with specialdependencies among the related transactions. Especially, there is a transaction which isexecuted outside the scope of its initiating transaction.Example 5.0.2 A commonly used example is a travel planning activity. In our examplethis activity consists of the recording of the customer's data, reserving a ight, bookinga room in the beach hotel including a diving course and a car, or booking a room in thecity hotel. This activity is modeled as transaction closure with the transactions t2, t3, t4,t5, t6, t7, and the coordinating root transaction t1.Transaction t2 represents the recording of the customer's data which is done inde-pendently whether the trip reservation is successful or not. The ight reservation (t3) isessential for the trip. Moreover, a room in the beach hotel (t4) may be reserved includinga diving course (t6). Furthermore, we may rent a car (t7) for traveling along the coast.If the diving course cannot be booked we also cannot book the beach hotel. An alternativeto the beach hotel is the city hotel (t5).From this scenario follows that the transactions t2, t3, and t4 which are child trans-actions of the root transaction t1 are connected to t1 by the following dependencies:indep(t1; t2) ^ vital depJ(t3; t1) ^ vitalI(t1; t4)The transactions t5, t6, and t7 are child transactions of transaction t4. These childtransactions are connected to their parent transaction by the following dependencies:exc�(t4; t5) ^ vital depJ(t4; t6) ^ depJ(t4; t7)As re ected by the dependencies, transactions t3, t4, t5, t6, and t7 are supposed to becompensatable.

26

(4)

(3)

(5)

(1)(2)

vital (t1,t4)

4

1

t

t

t

vita

l_de

p (

t3,t1

)

3t

6 7

indep (t1,t2

)

t

▲

Car RentalCity Hotel Reservation

Reservation Beach Hotel

t

FlightReservation ▲

dep (t4,t7)

compensatabletransaction

Book Diving Course

Record

Data

2t

5

▲

exc

(t4,

t5)

◆

vital_dep (t4,t6)

◆

Travel Planning

Customer’s

Figure 5.1: A sample Transaction ClosureOur example transaction closure is graphically illustrated in Figure 5.1 where the arrowsdenote the direction of the abort dependencies. For example, t1 �! t4 means that theabortion of transaction t1 leads to the abortion of t4. The termination dependencies aregraphically represented as follows:vital(ti; tj) corresponds to ti �! tjdep(ti; tj) corresponds to ti � tjvital dep(ti; tj) corresponds to ti ! tjexc(ti; tj) corresponds to ti 6 ! tjindep(ti; tj) corresponds to ti || tjFrom our dependency de�nitions, Theorem 3.1.6, and Theorem 3.2.9, and the rules inAppendix A we can now derive the transitive dependencies in the underlying transactionclosure. We are also able to investigate the in uence of the abortion of a certain trans-action on the whole closure. In the following, we discuss some interesting cases whichrefer to the dashed lines in Figure 5.1:(1) We start with the consideration of the transactions t1, t3, and t4. We know thatt1 is vital depJ on t3 and vitalI for t4. From these basic dependencies we canderive that transaction t3 is transitively vitalI for transaction t4 (see Rule A.39in Appendix A):vital depJ(t3; t1) ^ vitalI(t1; t4) Rule A:39=) vitalI(t3; t4)Hence, the abortion of transaction t3 (no ight can be reserved) leads to the abortionof the parent t1 (cancel of the trip) and of the sibling transaction t4 (we do not need

Chapter 5. Application of the Transitivity Rules 27a hotel reservation). In contrast, the abortion of t4 has no in uence on the othertransactions. In other words, in case there is no free room in the beach hotel,nevertheless, we may book the ight.(2) Transaction t2 is independent of its initiating transaction and, thus, it may betransitively independent of all other transactions of the transaction closure. Forexample, from Rule 3.5 of Theorem 3.1.6 and Rule A.75 of Appendix A we canderive that t2 is also independent of t3:indep(t1; t2) ^ vital depJ(t3; t1) Rule 3:5�indep(t2; t1) ^ vital depJ(t3; t1) Rule A:75=) indep(t2; t3)(3) An other interesting dependency is the exclusive dependency between the two hotelreserving transactions t4 and t5. The relationship between the transactions t5 andt1 can be derived from the vitalI dependency between t1 and t4.vitalI(t1; t4) ^ exc�(t4; t5) Rule A:102=) indep(t1; t5) _ vitalI(t1; t5) _ excI(t1; t5)Here, transaction t1 can be speci�ed by the transaction designer as eitherindep(t1; t5), vitalI(t1; t5), or excI(t1; t5). In this application scenario we wouldmodel this dependency as vitalI. Thus, the reservation of the city hotel is canceledin case the trip reservation is canceled. This may happen if we cannot book a ight.(4) Due to the speci�cation that transaction t5 is exclusive for transaction t6, the suc-cessful reservation of the city hotel leads to the abortion of the beach hotel reserva-tion including the diving course:exc�(t4; t5) ^ vital dep�(t4; t6) Rule 3:12�exc�(t5; t4) ^ vital dep�(t4; t6) Rule A:69=) exc�(t5; t6)(5) Finally, we consider transaction t7. Transaction t4 is dependent on t7. Thus, aroom in the beach hotel is only reserved in case we can rent a car. The dependencybetween the car rental and the diving course booking is evaluated by the followingrules: depJ(t4; t7) ^ vital dep�(t4; t6) Rule 3:11�vitalI(t7; t4) ^ vital dep�(t4; t6) Rule A:69=) vitalI(t7; t6)Transaction t7 is vital for t6 and, thus, the diving course can only be booked in casea car is rent.Example 5.0.2 showed that the abortion of a transaction may lead to the abortion ofparts of the closure. Often, dependencies between two arbitrary transactions of a trans-action closure may be complex and sometimes not obvious. However, the in uence of

28transaction abortion on a transaction closure can be simulated by the transitive depen-dencies. This may help also to detect super uous, redundant parts of a transactionclosure de�nition. The following Example 5.0.3 (see also Figure 5.2) is intended to showthe handling of inconsistent dependency speci�cations.kt

exc (t , t )i j

vital (t , t )

t

jk

i j

dep (t , t )i k

t

Figure 5.2: Example of a Contradicting Dependency Speci�cationExample 5.0.3 Suppose there are three transactions ti, tj, and tk with the followingdependencies: vital(ti; tk) ^ exc(ti; tj) ^ dep(tk; tj)The exclusive dependency only allows the commitment of one of the related transactionsti and tj or the abortion of both transactions:committi exc(ti;tj)) aborttj dep(tj ;tk)) aborttkcommittj exc(ti;tj)) abortti vital(ti ;tk)) aborttk(abortti ^ aborttj ) vital(ti ;tk)) aborttkIn case transaction ti commits, transaction tj has to abort because of the exclusive de-pendency. However, the abortion of tj leads to the abortion of transaction tk. In theopposite case, if transaction tj commits, then ti and tk have to abort. The case that thetransactions ti and tj abort leads to the abortion of tk. Due to the exclusive dependencythe commitment of the transactions ti and tj is not allowed. As a consequence, trans-action tk is aborted in any case. Thus, there is no rule which allows to specify such adependency combination. Rule A.97 on page 39 determines that the transitive depen-dency for vital(ti; tk) and dep(tk; tj) may be either independent, vital-dependent, vital,or dependent, but not exclusive:vital(ti; tk) ^ dep(tk; tj) ) indep(ti; tj) _ vital dep(ti; tj) _ vital(ti; tj) _ dep(ti; tj)Using the set of transitivity rules we are able to detect such contradictory dependencyspeci�cation.

Chapter 6. Conclusions and Outlook 29Chapter 6Conclusions and OutlookThe original model of nested transactions is not suitable for generalized transactionmodels where child transactions may survive the termination of the parent transaction.The proposed concept of transaction closures together with the dependencies introducedprovide an appropriate model for discussing such extended models (as proposed in e.g.[Elm92]). Transaction closures are collections of transactions where the connection isgiven by termination conditions between transactions and their immediate child trans-actions. Compensating transactions are also part of the model. The framework allowsto e�ectively compute derived termination conditions, and, thus, it builds the basis fortransaction design tools which can help in designing less failure-prone and more e�cientapplications. Besides termination dependencies, our framework also supports objectvisibility constraints and execution order constraints [STS98].Our future work will concentrate on the enforcement of termination conditions ingeneralized transaction management systems. Here, we will attempt to adopt the meth-ods proposed in [TV95, GHK93, GD94] to our framework and provide some extensionsto capture the transitive properties of transaction dependencies. Besides this, severalextended transaction models like ConTracts [WR92, RSS97] or S-transaction [VEH92]will be mapped onto our framework to show the practicability of the approach. More-over, we will use our framework for describing global transactions in federated databaseenvironments where the component systems support di�erent transaction types. We be-lieve that with our framework we are able to exactly formulate the di�erent relationshipsof the global child transactions which are executed by the possibly heterogeneous andautonomous component database systems.

30

BIBLIOGRAPHY 31Bibliography[BHG87] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control andRecovery in Database Systems. Addison-Wesley, Reading, MA, 1987.[B�OH+92] A. Buchmann, M. T. �Ozsu, M. Hornick, D. Georgakopoulos, and F. Manola.A Transaction Model for Active Distributed Object Systems. In A. K. El-magarmid, editor, Database Transaction Models for Advanced Applications,pages 123{151, Morgan Kaufmann Publishers, San Mateo, CA, 1992.[CR90] P. K. Chrysanthis and K. Ramamritham. ACTA: A Framework for Specifyingand Reasoning about Transaction Structure and Behavior. In H. Garcia-Molina and H. V. Jagadish, editors, Proc. of the 1990 ACM SIGMOD Int.Conf. on Management of Data, Atlantic City, NJ, ACM SIGMOD Record,Vol. 19, No. 2, pages 194{203, June 1990.[CR91] P. K. Chrysanthis and K. Ramamritham. A Formalism for Extended Transac-tion Models. In G. M. Lohmann, A. Sernadas, and R. Camps, editors, Proc. ofthe 17th Int. Conf. on Very Large Data Bases (VLDB'91), Barcelona, Spain,pages 103{112. Morgan Kaufmann Publishers, San Mateo, CA, September1991.[CR94] P. K. Chrysanthis and K. Ramamritham. Synthesis of Extended TransactionModels Using ACTA. ACM Transaction on Database Systems, 19(3):450{491,September 1994.[DHL91] U. Dayal, M. Hsu, and R. Ladin. A Transaction Model for Long-RunningActivities. In G. M. Lohmann, A. Sernadas, and R. Camps, editors, Proc. ofthe 17th Int. Conf. on Very Large Data Bases (VLDB'91), Barcelona, Spain,pages 113{122. Morgan Kaufmann Publishers, San Mateo, CA, September1991.[Elm92] A. K. Elmagarmid, editor. Database Transaction Models For Advanced Ap-plications. Morgan Kaufmann Publishers, San Mateo, CA, 1992.[Gar83] H. Garcia-Molina. Using Semantic Knowledge for Transaction Processing ina Distributed Database. ACM Transactions on Database Systems, 8(2):186{213, June 1983.

32 BIBLIOGRAPHY[GD94] A. Geppert and K. R. Dittrich. Rule-Based Implementation of TransactionModel Speci�cations. In N. W. Paton and M. H. Williams, editors, Rulesin Database Systems, Proc. of the 1st Int. Workshop, RIDS'93, Edinburgh,Scotland, August 1993, Workshops in Computing, pages 127{142. Springer-Verlag, London, 1994.[GHK93] D. Georgakopoulos, M. Hornick, and P. Krychniak. An Environment for theSpeci�cation and Management of Extended Transactions in DOMS. In H.-J.Schek, A. P. Sheth, and B. D. Czejdo, editors, Proc. of the 3rd Int. Workshopon Research Issues in Data Engineering: Interoperability in MultidatabaseSystems (RIDE-IMS'93), Vienna, Austria, pages 253{257, IEEE ComputerSociety Press, April 1993.[GHS95] D. Georgakopoulos, M. Hornick, and A. Sheth. An Overview of Work owManagement: From Process Modeling to Work ow Automation Infrastruc-ture. Distributed and Parallel Databases, 3(2):119{153, April 1995.[GR93] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques.Morgan Kaufmann Publishers, San Mateo, CA, 1993.[HLM88] M. Hsu, R. Ladin, and D. R. McCarthy. An Execution Model For ActiveData Base Management Systems. In C. Beeri, J. W. Schmidt, and U. Dayal,editors, Proc. of the 3rd Int. Conf. on Data and Knowledge Bases: ImprovingUsability and Responsiveness, Jerusalem, Israel, June, 1988, pages 171{179,Morgan Kaufmann Publishers, 1988.[KR96] M. U. Kamath and K. Ramamritham. Correctness Issues in Work ow Man-agement. Distributed Systems Engineering, 3(4), December 1996.[Mos85] J. E. B. Moss. Nested Transactions: An Approach to Reliable DistributedComputing. MIT Press, Cambridge, MA, 1985.[RC97] K. Ramamritham and P. K. Chrysanthis. Advances in Concurrency Controland Transaction Processing. IEEE Computer Society Press, Los Alamitos,California, 1997.[RKT+95] M. Rusinkiewicz, W. Klas, T. Tesch, J. W�asch, and P. Muth. Towards a Coop-erative Transaction Model | The Cooperative Activity Model. In U. Dayal,P. M. D. Gray, and S. Nishio, editors, Proc. of the 21st Int. Conf. on VeryLarge Data Bases (VLDB'95), Z�urich, Switzerland, pages 194{205, MorganKaufmann Publishers, September 1995.[RSS97] A. Reuter, K. Schneider, and F. Schwenkreis. ConTracts Revisited. In S. Ja-jodia and L. Kerschberg, editors, Advanced Transaction Models and Archi-tectures, chapter 5, Kluwer Academic Publishers, 1997.

BIBLIOGRAPHY 33[STS98] K. Schwarz, C. T�urker, and G. Saake. Analyzing and Formalizing Dependen-cies in Generalized Transaction Structures. In Proc. of the Int. Workshop onIssues and Applications of Database Technology (IADT'98), July 6-9, 1998,Berlin, Germany, 1998. To appear.[TV95] J. Tang and J. Veijalainen. Enforcing Inter-task Dependencies in Transac-tional Work ows. In S. Laufmann, S. Spaccapietra, and T. Yokoi, editors,Proc. of the 3rd Int. Conf. on Cooperative Information Systems (CoopIS'95),May 9{12, 1995, Vienna, Austria, pages 72{86, 1995.[VEH92] J. Veijalainen, F. Eliassen, and B. Holtkamp. The S-transaction Model. InA. K. Elmagarmid, editor, Database Transaction Models for Advanced Ap-plications, pages 467{513, Morgan Kaufmann Publishers, San Mateo, CA,1992.[WR92] H. W�achter and A. Reuter. The ConTract Model. In A. K. Elmagarmid,editor, Database Transaction Models for Advanced Applications, pages 219{263, Morgan Kaufmann Publishers, San Mateo, CA, 1992.

34 BIBLIOGRAPHY

Appendix A. Transitivity Rules of Termination Dependencies 35Appendix ARules for Transitive TransactionTermination DependenciesThe algorithm presented in Chapter 4 brings out a set of rules for deriving transitive de-pendencies. There are some cases where on the right side of the implication a disjunctionof possible dependencies occur, i.e, from two given dependencies we cannot determineonly exactly one correct transitive dependency. These are the cases where we | astransaction designer | have the option to choose among several possible dependencies.The corresponding transitivity rules are computed by considering the three dependenciesX, Y and Z in all possible combinations (X ^Y ) Z), (Y ^Z ) X), and (X ^Z ) Y )and under the requirement that the resulting rule set must be consistent.In the following, we list the resulting transitive dependency rules which have to holdfor three di�erent transactions ti, tk, and tj:Rules for vital dep(ti; tj):vital dep(ti; tk) ^ vital dep(tk; tj) ) vital dep(ti; tj) (A.1)vital depI(ti; tk) ^ vital depJ(tk; tj) ) vital dep(ti; tj) (A.2)Rules for vital(ti; tj):vital(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.3)vital(ti; tk) ^ vital dep(tk; tj) ) vital(ti; tj) (A.4)vital dep(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.5)vitalI(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.6)vitalI(ti; tk) ^ vital depJ(tk; tj) ) vital(ti; tj) (A.7)vital dep�(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.8)vital depJ(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.9)vital depI(ti; tk) ^ vital(tk; tj) ) vital(ti; tj) (A.10)

36Rules for dep(ti; tj): dep(ti; tk) ^ dep(tk; tj) ) dep(ti; tj) (A.11)vital dep(ti; tk) ^ dep(tk; tj) ) dep(ti; tj) (A.12)dep(ti; tk) ^ vital dep(tk; tj) ) dep(ti; tj) (A.13)dep(ti; tk) ^ depJ(tk; tj) ) dep(ti; tj) (A.14)vital depI(ti; tk) ^ depJ(tk; tj) ) dep(ti; tj) (A.15)dep(ti; tk) ^ vital dep�(tk; tj) ) dep(ti; tj) (A.16)dep(ti; tk) ^ vital depJ(tk; tj) ) dep(ti; tj) (A.17)dep(ti; tk) ^ vital depI(tk; tj) ) dep(ti; tj) (A.18)Rules for exc(ti; tj):vital dep(ti; tk) ^ exc(tk; tj) ) exc(ti; tj) (A.19)exc(ti; tk) ^ vital dep(tk; tj) ) exc(ti; tj) (A.20)dep(ti; tk) ^ exc(tk; tj) ) exc(ti; tj) (A.21)exc(ti; tk) ^ vital(tk; tj) ) exc(ti; tj) (A.22)vital depI(ti; tk) ^ excJ(tk; tj) ) exc(ti; tj) (A.23)excI(ti; tk) ^ vital depJ(tk; tj) ) exc(ti; tj) (A.24)dep(ti; tk) ^ excJ(tk; tj) ) exc(ti; tj) (A.25)excI(ti; tk) ^ vital(tk; tj) ) exc(ti; tj) (A.26)Rules for vital depJ(ti; tj):vital depJ(ti; tk) ^ vital dep(tk; tj) ) vital depJ(ti; tj) (A.27)vital dep�(ti; tk) ^ vital depJ(tk; tj) ) vital depJ(ti; tj) (A.28)Rules for vital depI(ti; tj):vital dep(ti; tk) ^ vital depI(tk; tj) ) vital depI(ti; tj) (A.29)vital depI(ti; tk) ^ vital dep�(tk; tj) ) vital depI(ti; tj) (A.30)Rules for vital dep�(ti; tj):vital dep�(ti; tk) ^ vital dep�(tk; tj) ) vital dep�(ti; tj) (A.31)vital depJ(ti; tk) ^ vital depI(tk; tj) ) vital dep�(ti; tj) (A.32)Rules for vitalI(ti; tj):vital(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.33)vital(ti; tk) ^ vital depI(tk; tj) ) vitalI(ti; tj) (A.34)

Appendix A. Transitivity Rules of Termination Dependencies 37vital dep(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.35)vitalI(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.36)vitalI(ti; tk) ^ vital dep�(tk; tj) ) vitalI(ti; tj) (A.37)vital dep�(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.38)vital depJ(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.39)vital depI(ti; tk) ^ vitalI(tk; tj) ) vitalI(ti; tj) (A.40)Rules for depJ(ti; tj):depJ(ti; tk) ^ dep(tk; tj) ) depJ(ti; tj) (A.41)vital depJ(ti; tk) ^ dep(tk; tj) ) depJ(ti; tj) (A.42)depJ(ti; tk) ^ vital dep(tk; tj) ) depJ(ti; tj) (A.43)depJ(ti; tk) ^ depJ(tk; tj) ) depJ(ti; tj) (A.44)vital dep�(ti; tk) ^ depJ(tk; tj) ) depJ(ti; tj) (A.45)depJ(ti; tk) ^ vital dep�(tk; tj) ) depJ(ti; tj) (A.46)depJ(ti; tk) ^ vital depJ(tk; tj) ) depJ(ti; tj) (A.47)depJ(ti; tk) ^ vital depI(tk; tj) ) depJ(ti; tj) (A.48)Rules for excJ(ti; tj):vital depJ(ti; tk) ^ exc(tk; tj) ) excJ(ti; tj) (A.49)excJ(ti; tk) ^ vital dep(tk; tj) ) excJ(ti; tj) (A.50)depJ(ti; tk) ^ exc(tk; tj) ) excJ(ti; tj) (A.51)excJ(ti; tk) ^ vital(tk; tj) ) excJ(ti; tj) (A.52)vital dep�(ti; tk) ^ excJ(tk; tj) ) excJ(ti; tj) (A.53)exc�(ti; tk) ^ vital depJ(tk; tj) ) excJ(ti; tj) (A.54)depJ(ti; tk) ^ excJ(tk; tj) ) excJ(ti; tj) (A.55)exc�(ti; tk) ^ vital(tk; tj) ) excJ(ti; tj) (A.56)Rules for excI(ti; tj):vital dep(ti; tk) ^ excI(tk; tj) ) excI(ti; tj) (A.57)exc(ti; tk) ^ vital depI(tk; tj) ) excI(ti; tj) (A.58)dep(ti; tk) ^ excI(tk; tj) ) excI(ti; tj) (A.59)exc(ti; tk) ^ vitalI(tk; tj) ) excI(ti; tj) (A.60)vital depI(ti; tk) ^ exc�(tk; tj) ) excI(ti; tj) (A.61)excI(ti; tk) ^ vital dep�(tk; tj) ) excI(ti; tj) (A.62)dep(ti; tk) ^ exc�(tk; tj) ) excI(ti; tj) (A.63)excI(ti; tk) ^ vitalI(tk; tj) ) excI(ti; tj) (A.64)

38Rules for exc�(ti; tj):vital depJ(ti; tk) ^ excI(tk; tj) ) exc�(ti; tj) (A.65)excJ(ti; tk) ^ vital depI(tk; tj) ) exc�(ti; tj) (A.66)depJ(ti; tk) ^ excI(tk; tj) ) exc�(ti; tj) (A.67)excJ(ti; tk) ^ vitalI(tk; tj) ) exc�(ti; tj) (A.68)vital dep�(ti; tk) ^ exc�(tk; tj) ) exc�(ti; tj) (A.69)exc�(ti; tk) ^ vital dep�(tk; tj) ) exc�(ti; tj) (A.70)depJ(ti; tk) ^ exc�(tk; tj) ) exc�(ti; tj) (A.71)exc�(ti; tk) ^ vitalI(tk; tj) ) exc�(ti; tj) (A.72)Rules for indep(ti; tj):indep(ti; tk) ^ vital dep(tk; tj) ) indep(ti; tj) (A.73)indep(ti; tk) ^ vital dep�(tk; tj) ) indep(ti; tj) (A.74)indep(ti; tk) ^ vital depJ(tk; tj) ) indep(ti; tj) (A.75)indep(ti; tk) ^ vital depI(tk; tj) ) indep(ti; tj) (A.76)indep(ti; tk) ^ vital(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _exc(ti; tj) _ excJ(ti; tj) (A.77)indep(ti; tk) ^ vitalI(tk; tj) ) indep(ti; tj) _ vitalI(ti; tj) _exc�(ti; tj) _ excI(ti; tj) (A.78)indep(ti; tk) ^ dep(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _depJ(ti; tj) (A.79)indep(ti; tk) ^ depJ(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _depJ(ti; tj) (A.80)indep(ti; tk) ^ exc(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _exc(ti; tj) _ excJ(ti; tj) (A.81)indep(ti; tk) ^ exc�(tk; tj) ) indep(ti; tj) _ vitalI(ti; tj) _exc�(ti; tj) _ excI(ti; tj) (A.82)indep(ti; tk) ^ excJ(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _exc(ti; tj) _ excJ(ti; tj) (A.83)indep(ti; tk) ^ excI(tk; tj) ) indep(ti; tj) _ vitalI(ti; tj) _exc�(ti; tj) _ excI(ti; tj) (A.84)vital dep(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) (A.85)vital dep�(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) (A.86)vital depJ(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) (A.87)vital depI(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) (A.88)vital(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _

Appendix A. Transitivity Rules of Termination Dependencies 39vitalI(ti; tj) (A.89)vitalI(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _vitalI(ti; tj) (A.90)dep(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _exc(ti; tj) _ excI(ti; tj) (A.91)depJ(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ depJ(ti; tj) _exc�(ti; tj) _ excJ(ti; tj) (A.92)exc(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _exc(ti; tj) _ excI(ti; tj) (A.93)exc�(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ depJ(ti; tj) _exc�(ti; tj) _ excJ(ti; tj) (A.94)excJ(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ depJ(ti; tj) _exc�(ti; tj) _ excJ(ti; tj) (A.95)excI(ti; tk) ^ indep(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _exc(ti; tj) _ excI(ti; tj) (A.96)vital(ti; tk) ^ dep(tk; tj) ) indep(ti; tj) _ vital dep(ti; tj) _vital dep�(ti; tj) _ vital depJ(ti; tj) _vital depI(ti; tj) _ vital(ti; tj) _vitalI(ti; tj) _ dep(ti; tj) _depJ(ti; tj) (A.97)vitalI(ti; tk) ^ depJ(tk; tj) ) indep(ti; tj) _ vital dep(ti; tj) _vital dep�(ti; tj) _ vital depJ(ti; tj) _vital depI(ti; tj) _ vital(ti; tj)vitalI(ti; tj) _ dep(ti; tj) _depJ(ti; tj) (A.98)vital(ti; tk) ^ exc(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _exc(ti; tj) _ excJ(ti; tj) (A.99)vital(ti; tk) ^ excI(tk; tj) ) indep(ti; tj) _ vitalI(ti; tj) _exc�(ti; tj) _ excI(ti; tj) (A.100)vitalI(ti; tk) ^ excJ(tk; tj) ) indep(ti; tj) _ vital(ti; tj) _exc(ti; tj) _ excJ(ti; tj) (A.101)vitalI(ti; tk) ^ exc�(tk; tj) ) indep(ti; tj) _ vitalI(ti; tj) _exc�(ti; tj) _ excI(ti; tj) (A.102)exc(ti; tk) ^ dep(tk; tj) ) indep(ti; tj) _ dep(ti; tj) _exc(ti; tj) _ excI(ti; tj) (A.103)excJ(ti; tk) ^ dep(tk; tj) ) indep(ti; tj) _ depJ(ti; tj) _

40 exc�(ti; tj) _ excJ(ti; tj) (A.104)exc�(ti; tk) ^ depJ(tk; tj) ) indep(ti; tj) _ depJ(ti; tj) _excJ(ti; tj) _ exc�(ti; tj) (A.105)excI(ti; tk) ^ depJ(tk; tj) ) indep(ti; tj) _ dep _exc(ti; tj) _ excI(ti; tj) (A.106)Furthermore, there are combinations of dependencies X(ti; tk) and Y (tk; tj) which donot imply any restrictions for the transitive dependency Z(ti; tj). In this case any ofthe dependencies introduced so far can be valid for Z(ti; tj). This is expressed by thepredicate any(ti; tj): dep(ti; tk) ^ vital(tk; tj) ) any(ti; tj) (A.107)exc(ti; tk) ^ exc(tk; tj) ) any(ti; tj) (A.108)dep(ti; tk) ^ vitalI(tk; tj) ) any(ti; tj) (A.109)depJ(ti; tk) ^ vital(tk; tj) ) any(ti; tj) (A.110)depJ(ti; tk) ^ vitalI(tk; tj) ) any(ti; tj) (A.111)exc(ti; tk) ^ excI(tk; tj) ) any(ti; tj) (A.112)exc�(ti; tk) ^ exc�(tk; tj) ) any(ti; tj) (A.113)exc�(ti; tk) ^ excJ(tk; tj) ) any(ti; tj) (A.114)excJ(ti; tk) ^ exc(tk; tj) ) any(ti; tj) (A.115)excJ(ti; tk) ^ excI(tk; tj) ) any(ti; tj) (A.116)excI(ti; tk) ^ exc�(tk; tj) ) any(ti; tj) (A.117)excI(ti; tk) ^ excJ(tk; tj) ) any(ti; tj) (A.118)indep(ti; tk) ^ indep(tk; tj) ) any(ti; tj) (A.119)any(ti; tk) ^ Y (tk; tj) ) any(ti; tj) (A.120)X(ti; tk) ^ any(tk; tj) ) any(ti; tj) (A.121)