A Reservation-Based Extended Transaction Protocol

Transcription

1 Clevelad State Uiversity Electrical Egieerig & Computer Sciece Faculty Publicatios Electrical Egieerig & Computer Sciece Departmet A Reservatio-Based Exteded Trasactio Protocol Webig Zhao Clevelad State Uiversity, w.zhao1@csuohio.edu Louise E. Moser Uiversity of Califoria-Sata Barbara, moser@ece.ucsb.edu P. Michale Melliar-Smith Uiversity of Califoria - Sata Barbara, pmms@ece.ucsb.edu Follow this ad additioal works at: Part of the Computer ad Systems Architecture Commos Publisher's Statemet 2008 IEEE. Persoal use of this material is permitted. Permissio from IEEE must be obtaied for all other users, icludig repritig/ republishig this material for advertisig or promotioal purposes, creatig ew collective works for resale or redistributio to servers or lists, or reuse of ay copyrighted compoets of this work i other works. Origial Citatio Webig, Z. Y., Moser, L. E., & Melliar-Smith, P. M. (.d.). A Reservatio-Based Exteded Trasactio Protocol. IEEE Trasactios o Parallel ad Distributed Systems, 19, 2, Repository Citatio Zhao, Webig; Moser, Louise E.; ad Melliar-Smith, P. Michale, "A Reservatio-Based Exteded Trasactio Protocol" (2008). Electrical Egieerig & Computer Sciece Faculty Publicatios. Paper This Article is brought to you for free ad ope access by the Electrical Egieerig & Computer Sciece Departmet at EgagedScholarship@CSU. It has bee accepted for iclusio i Electrical Egieerig & Computer Sciece Faculty Publicatios by a authorized admiistrator of EgagedScholarship@CSU. For more iformatio, please cotact library.es@csuohio.edu.

2 A Reservatio-Based Exteded Trasactio Protocol Webig Zhao, Member, IEEE, Louise E. Moser, Member, IEEE, ad P.M. Melliar-Smith, Member, IEEE Abstract With the advet of the ew geeratio of Iteret-based techology, i particular, Web Services, the automatio of busiess activities that are distributed across multiple eterprises becomes possible. Busiess activities are differet from traditioal trasactios i that they are typically asychroous, loosely coupled, ad log ruig. Therefore, exteded trasactio protocols are eeded to coordiate busiess activities that spa multiple eterprises. Existig exteded trasactio protocols typically rely o compesatig trasactios to hadle exceptioal coditios. I this paper, we idetify a umber of issues with compesatio-based exteded trasactio protocols ad describe a reservatio-based exteded trasactio protocol that addresses those issues. Moreover, we defie a set of properties, aalogous to the ACID properties of traditioal trasactios that are more appropriate for busiess activities that spa multiple eterprises. I additio, we compare our reservatio protocol with other exteded trasactio protocols for coordiatig busiess activities ad preset performace aalyses ad results. Idex Terms Busiess activity, cotiuous availability, exteded trasactio model, isolatio, relaxed atomicity, reservatio protocol, trasactio processig, Web services. Ç 1 INTRODUCTION THE automatio of busiess activities that are distributed commit protocol works well for the coordiatio of across multiple eterprises becomes possible with the trasactios withi a sigle eterprise, the use of the twoadvet of the ew geeratio of Iteret-based techology, phase commit protocol i distributed trasactios that spa i particular, Web Services. Busiess activities typically multiple eterprises uavoidably ivolves oe eterprise ivolve related tasks that are loosely coupled ad carried lockig a data record of aother eterprise. If the trasacout over a log period of time. The automatio of busiess tio coordiator fails, the lockig period might be too log activities, with direct computer-to-computer iteractios for the eterprise to tolerate. Eve if the trasactio ad without huma ivolvemet, ca provide substatial coordiator does ot fail, resources might be locked loger speed improvemets ad cost reductios for distributed tha the eterprise is willig to accept. Therefore, i eterprise computig. However, such eterprise applica- practice, distributed trasactios based o the two-phase tios must operate with a high degree of availability ad commit protocol are seldom used for busiess activities that performace. The resolutio of icosistecies amog the spa multiple eterprises. Istead, such busiess activities databases of multiple eterprises is difficult, expesive, are based o exteded trasactios [30], where each task of time cosumig, ad error proe, much more so tha the the busiess activity is executed as a sequece of oe or resolutio of icosistecies withi the databases of a sigle more local trasactios, ad whe a busiess activity is eterprise. Problems i the operatio of the applicatio rolled back, compesatig trasactios [7] are applied to services ca adversely affect the relatioships betwee a offset the effects of the committed local trasactios. eterprise ad its customers, suppliers, ad parters. Compesatig trasactios ca be difficult to desig ad May eterprise applicatios are programmed usig the program ad eve more difficult to test i a distributed trasactio processig programmig paradigm ad are Web Service eviromet, resultig i a rather high level of executed i the cotext of commercial trasactio proces- errors. Eve if the compesatig trasactios are desiged sig systems. Such systems typically employ trasactioal ad programmed correctly, it is difficult to esure that lockig ad the two-phase commit protocol for distributed whe they are eeded, the compesatig trasactios are trasactios, which ivolves a trasactio coordiator ad applied correctly (for example, the umber of retries must oe or more participats [12]. Although the two-phase be limited for practical purposes). The typical result of a error i the desig, programmig, or deploymet of a compesatig trasactio is icosistecy i the databases,. W. Zhao is with the Departmet of Electrical ad Computer Egieerig, either withi a sigle database or, more probably, betwee Clevelad State Uiversity, 2121 Euclid Ave., Clevelad, OH the databases of differet eterprises. It is difficult ad webig@ieee.org.. L.E. Moser ad P.M. Melliar-Smith are with the Departmet of Electrical expesive to resolve such icosistecies, particularly whe ad Computer Egieerig, Uiversity of Califoria, Sata Barbara, Sata the databases are spread across multiple eterprises, as is Barbara, CA {moser, pmms}@ece.ucsb.edu. the itetio of Web Services. We demostrate that the use of compesatig trasactios results i a much higher probability of database icosistecy tha does the reservatio protocol. Ideed, for etirely reasoable parameters, the probability of icosistecy approaches uity whe usig compesatig trasactios.

3 Fig. 1. Example busiess activity. (a) I the distributed trasactios with compesatig trasactios approach, each task of the busiess activity is executed as a traditioal ACID trasactio withi a sigle eterprise, with compesatig trasactios applied whe a fault occurs. (b) I the reservatio protocol approach, each task is executed as two subtasks, a reservatio subtask ad a cofirmatio/cacellatio subtask; oe of several possible iterleavigs of the tasks is show i the figure. The existig Web Services stadards offer two alteratives:. classical distributed trasactios based o the twophase commit protocol [4] ad. exteded trasactios with compesatig trasactios [5]. Apparetly, the advocates of those strategies are uaware of the high probability of database icosistecy ad the poor performace of those strategies. I this paper, we describe a reservatio-based exteded trasactio protocol that is compatible with ad easily implemeted usig Web Services, that is easy to program ad use, ad that does ot deped o compesatig trasactios. I our reservatio protocol, except for readoly tasks, each task withi a busiess activity is executed as two subtasks. The first subtask ivolves a explicit reservatio of resources accordig to the busiess logic. The secod subtask ivolves the cofirmatio or a cacellatio of the reservatio. Each subtask is executed as a separate traditioal short-ruig ACID trasactio. For example, the task of makig a purchase of a certai amout of goods i a procuremet busiess activity is executed as two subtasks. The first subtask reserves a amout of the goods to be purchased, ad the secod subtask coverts the reservatio ito a purchase or a cacellatio of the reservatio. The reservatio at the ed of the first subtask becomes visible to other busiess activities, because fewer resources are available for them to reserve. However, this visibility does ot compromise the isolatio property, because the reservatio ca be cofirmed or cacelled, ad the other busiess activities caot make ay assumptios about resources that have ot bee reserved for them. For the duratio of the reservatio, the supplier grats a exclusive right to the cliet for the amout of goods reserved. Durig the secod subtask, the reservatio is cofirmed oly if the busiess activity ca be completed successfully. Fig. 1 shows a example busiess activity, highly simplified, of purchasig a product (resource) that requires shippig. I the compesatig trasactios approach show i Fig. 1a, the buyer (that is, iitiator) proceeds with the purchase oly if both the product ad the shippig are available. The buyer first places a order for the product ad the arrages for shippig. However, if the shipper caot deliver the product i time (for example, o trucks are available), the buyer must reverse the previous purchase, ad the, a compesatig trasactio is applied. I the reservatio protocol approach show i Fig. 1b, each task is executed as two subtasks, a reservatio subtask ad a cofirmatio/cacellatio subtask, without the eed for compesatig trasactios. If the shipper caot deliver the product i time, the buyer simply cacels the reservatio of the product. Despite the apparet similarity of our reservatio protocol to the traditioal two-phase commit protocol, there are sigificat differeces, which we discuss later i this paper. I fact, our reservatio protocol resembles more closely the escrow trasactioal method [23]. The similarity ad the differeces betwee our reservatio protocol ad the escrow trasactioal method are elaborated i depth. We also compare our reservatio protocol with other exteded trasactio strategies. I additio, we preset performace aalyses ad results, which idicate that the protocol performs similar to or better tha other exteded trasactio strategies. 2 MODEL A trasactio is a set of operatios o the applicatio state that satisfies the followig ACID properties [12]:. Atomicity. Either all of the operatios of the trasactio succeed, i which case the trasactio commits, or oe of the operatios is carried out, i which case the trasactio aborts.

4 . Cosistecy. If the applicatio state is cosistet at the begiig of the trasactio, the applicatio state remais cosistet after the trasactio commits.. Isolatio. The trasactio does ot read or overwrite itermediate results produced by aother trasactio, that is, the trasactios appear to execute serially.. Durability. The updates to the applicatio state become permaet (or persist) oce the trasactio is committed, eve if a fault occurs. A local trasactio is a trasactio with the above ACID properties that is executed at a sigle site. A task is a short-duratio uit of work that is executed as a sequece of oe or more local trasactios. A task ca be modeled as a operatio o oe or more resources ad typically modifies some of the attributes of those resources. For example, the task of purchasig/sellig certai kids of goods (applicatio-defied resources) such as automobiles ca be modeled as a operatio i which the ower attribute of the resource is chaged from the supplier to the buyer. A operatio ca be read-oly, i which case the task is a read-oly task. Examples of read-oly tasks are tasks that obtai iformatio such as a UPS or FEDEX shippig charge or a federal or state tax rate. A busiess activity is a uit of work that cosists of oe or more tasks ad that spas oe or more eterprises, with messages set betwee those eterprises. The tasks i a busiess activity are partially ordered. Tasks that are ot causally related ca be executed cocurretly, ad causally related tasks are executed accordig to the partial order. As i Fig. 1a, we use T1, T2, etc., to deote differet tasks of a busiess activity. The correspodig compesatio tasks are represeted as CT1, CT2, etc. As i Fig. 1b, we use Ti R to deote the reservatio subtask for the ith task of the busiess activity, ad Ti C, the correspodig cofirmatio/ cacellatio subtask. A busiess activity has a umber of participats; the participat that iitiates the activity is called the iitiator. The iitiator is ofte the cliet of the other participats i the activity. We assume that the participats i a busiess activity are subject to crash faults but ot arbitrary (Byzatie) faults. We preset more details o faults withi the participats i a busiess activity ad discuss how those faults are hadled later as part of the descriptio of the reservatio protocol istatiatio. Moreover, we assume that the commuicatio betwee differet participats i a busiess activity is reliable. A implemetatio of a specificatio such as the Web Services Reliable Messagig (WS-RM) specificatio [16] ca be used to achieve reliable commuicatio. I a busiess activity, the ACID properties of a traditioal trasactio are ot appropriate for the followig reasos. First, it is ot ecessary that all of the participats see the same result, a observatio that has bee well recogized i practice. For example, if reservatios are requested from several alterative participats, typically, oe participat will see a cofirmatio, ad the other participats will see a cacellatio. The Web Services Busiess Activity (WS-BA) specificatio [5] defies two outcome types, atomic outcome ad mixed outcome, to support differet kids of busiess activities, icludig those where oly some of the participats agree o the same outcome. Thus, the failure of oe task does ot eed to result i the rollback of the etire busiess activity. Moreover, the effect of executig a busiess activity might ot be completely reversible, because of the busiess logic. Aalogous to a trasactio that satisfies the ACID properties, a busiess activity satisfies a correspodig set of properties that we ame the D4 properties ad defie below:. Distributed atomicity. Each busiess activity defies a set of permissible outcomes ad must reach oe of those outcomes whe it completes. These outcomes are classified as 1) defied-commit outcomes, for which the goal of the busiess activity is fulfilled either completely or partially, ad 2) defied-abort outcomes, for which the goal of the busiess activity is ot fulfilled.. Defied cosistecy. At the ed of each trasactio withi a busiess activity, the trasactio must leave its data i a state that is ot oly locally cosistet but also cosistet with the data of other eterprises that are accessed by other busiess activities, which we refer to as iter-eterprise cosistecy. Both local cosistecy ad iter-eterprise cosistecy are determied by the applicatio logic, that is, busiess rules.. Disjoit resource isolatio. Disjoit sets of resources are assiged to cocurret busiess activities. A busiess activity ca see whether its ow requests for resources are grated or refused, but it caot see the details of the requests of trasactios withi other cocurret busiess activities. Moreover, the ability of the trasactio of a busiess activity to complete the processig of that busiess activity, withi the resources that have bee reserved for it, caot be impeded by the trasactios of other cocurret busiess activities.. Durability. The results of a completed trasactio withi a busiess activity are persistet ad caot be udoe accidetally by faults or other trasactios. 3 THE RESERVATION PROTOCOL I this sectio, first, we provide a abstract descriptio of the reservatio protocol. Next, we elaborate a istatiatio of the reservatio protocol, after presetig specific assumptios o which it is based. Fially, we establish iformally the D4 properties for the reservatio protocol istatiatio. 3.1 Abstract Descriptio of the Reservatio Protocol Cosider a busiess activity ivolvig tasks T1;T2;...;T ad m participats P1;P2;...;Pm. Each task Ti ivolves k i participats, 1 - k i - m. A participat may be ivolved i more tha oe task. The reservatio protocol is executed i two phases, as described below. Durig the first phase, for each task Ti, each of its k i participats is cotacted to execute the reservatio subtask Ti R. Let Ti R j deote the reservatio subtask executed by participat Pj. At the ed of the first phase, the iitiator decides the outcome of the busiess activity based o the results of the first phase ad the busiess logic. A ecessary but ot sufficiet coditio for the completio of the busiess activity is that at least oe participat has grated the reservatio for each task, that is, for all Ti R, there exists Pj such that Ti R j is executed successfully with the reservatio grated. If the decisio is to proceed with the busiess activity, the iitiator selects a set of subtasks, oe for each task, to cofirm the reservatios grated. Durig the secod phase, for each subtask Ti R j i the set, participat Pj is cotacted to cofirm the reservatio

5 (deoted as cofirmatio subtask Ti C j ), ad the rest of the participats are cotacted to cacel the reservatio. If the decisio is ot to proceed with the busiess activity, all of the participats that have grated a reservatio are cotacted to cacel the reservatios durig the secod phase. Note that cofirmig a reservatio is differet from committig a trasactio, ad cacelig a reservatio is differet from abortig a trasactio. Read-oly tasks do ot require separate reservatio ad cofirmatio/cacellatio subtasks. 3.2 Specific Assumptios for the Reservatio Protocol Istatiatio We assume a flat busiess activity model; a hierarchical busiess activity model ca be costructed based o the flat model. We assume that each task ivolves a sigle type of resource ad that for each type of resource, oe or more competig alterative participats are available to provide resources from which the iitiator ca choose. We assume that each subtask (that is, Ti R j or Ti C j ) is performed as a local trasactio, that the result of the trasactio, whether it is committed or aborted, is commuicated to the ivoker, ad that the committed local trasactios are durable. As metioed earlier, we assume that process crash faults are possible ad that commuicatio faults are ot. A process crash fault might happe durig either phase of the reservatio protocol, ad it might occur at a participat or at the iitiator. If a participat fails after it has grated a reservatio, we regard the failure as a secod-phase failure (as far as the busiess activity is cocered). If a participat fails after it has processed the cacellatio/cofirmatio request, it has o effect o the busiess activity. We assume that all faults are repaired i a timely maer to allow the fulfillmet of busiess obligatios. The reservatio protocol is drive by the iitiator of a busiess activity. Most of the trasactioal logic that cotrols the progress ad outcome of the busiess activity is i the iitiator process. After each reservatio or cacellatio/cofirmatio subtask (that is, Ti R or Ti C ), the iitiator records the subtask ad its result i a persistet log. Whe the busiess activity is completed, the logged records for that activity ca be removed from the log (as far as the reservatio protocol is cocered, though it would be good practice to preserve such records for other purposes). If the iitiator recovers after it has failed i the middle of executig a protocol istace, it examies the logged records for all ufiished busiess activities ad cotiues the protocol istaces util they are completed. We assume that the iitiator is also protected by other appropriate high-availability mechaisms (see, for example, [3], [20], [32]) i order for it to recover quickly from faults, particularly durig the secod phase of the reservatio protocol, so that it does ot miss a deadlie for a reservatio that it placed durig the first phase. If the iitiator caot satisfy this requiremet, the D4 properties might ot be satisfied. We assume that all cofirmatio/cacellatio messages are timestamped ad are stored i a message log (either locally at or remotely from the iitiator). I particular, o recovery from a fault, a participat ca obtai such a message from the log. A participat determies the charge for the reservatio based o the timestamp of the cofirmatio/cacellatio message. A participat must hoor a grated reservatio, based o the timestamp of the message, eve if the deadlie (for a timed reservatio) has passed at the time of recovery. 3.3 Istatiatio of the Reservatio Protocol For each task, durig the first phase of the reservatio protocol, the reservatio request is set to the participats that provide the same service. The protocol proceeds forward oly if at least oe participat grats the reservatio request for each task. Otherwise, the first phase is termiated ad the iitiator seds a cacellatio request to each participat for which it grated a reservatio. The busiess activity is the defied abort. The reservatio of a resource is categorized as oe of the followig two types:. Utimed reservatio. The resource is reserved idefiitely for as log as it takes.. Timed reservatio. The resource is reserved for a certai period of time. If the reservatio deadlie expires, the reservatio is cacelled automatically by the resource holder. The timed reservatio has bee a commo practice i may busiesses, for example, for airlie seat ad car retal reservatios. I some cases, a surcharge is imposed by the resource holder if the reservatio is ot cacelled or cofirmed by the deadlie, for example, most hotels charge for a oe-ight stay if a reservatio is ot cacelled i time. We cosider this surcharge to be part of the reservatio cost. The timed reservatio ca lead to race coditios, for example, the resource ower might have timed out ad cacelled the reservatio by the time the user s cofirmatio message arrived. It is importat for the user to cofirm the reservatio as early as possible to avoid this situatio. Durig the reservatio period, the reserved resources are held exclusively for the cliet that made the reservatio util the cliet cofirms or cacels the reservatio or the deadlie has passed. I exchage for this service, the ower of the resources ca charge the cliet a reservatio fee. The reservatio fee is either quoted by the resource ower or egotiated betwee the cliet ad the resource ower prior to the reservatio phase. By explicitly reservig the resources ivolved i a task, the applicatio has the flexibility of goig forward or backward after the first subtask, without cocer for the effects of the trasactio, because a reservatio allows either outcome. Eve if other trasactios see the itermediate result of the reservatio (such as a reductio i the amout of available resources), those trasactios caot make ay assumptios about the future of the resources that have ot bee reserved for them. At the ed of the first phase, the iitiator determies which reservatios to cofirm ad which to cacel, based o the applicatio logic. For the subtasks to be executed durig the secod phase, the iitiator sorts them based o their priorities ad executes them i the followig order: 1. cofirmatio of timed reservatios, 2. cofirmatio of utimed reservatios, 3. cacellatio of timed reservatios, ad 4. cacellatio of utimed reservatios. The subtasks i each of these four categories are sorted based o their priorities, ad the subtasks are executed i the secod phase accordig to that order. The cacellatio subtasks release ay resources that have bee reserved ad, thus, make them available to the iitiators of other reservatios withi the same or differet busiess activities.

6 3.4 Maiteace of the D4 Properties by the Reservatio Protocol Istatiatio I the followig, we establish iformally that the reservatio protocol istatiatio described above maitais the D4 properties, durig both fault-free ad fault coditios Distributed Atomicity Uder fault-free coditios, the reservatio protocol istatiatio maitais the distributed atomicity property, because each busiess activity defies its ow set of permissible outcomes. Moreover, each reservatio subtask ad each cofirmatio/cacellatio subtask is itself a trasactio that satisfies the traditioal ACID atomicity property. Now, suppose that the iitiator fails durig the reservatio phase. If the iitiator ca recover quickly eough to make reservatios for all of the resources eeded to complete the busiess activity, the outcome is defied commit. If the iitiator caot recover quickly eough to cofirm some of the reservatios before they expire, the iitiator cacels all of its other reservatios, ad the outcome is defied abort. If a participat fails ad the iitiator caot reserve a resource from that participat, the iitiator tries to fid the resources from the alterative participats. If the iitiator ca fid the resources from the alterative participats ad successfully reserve them, a defied-commit outcome results uless the applicatio logic madates a defiedabort outcome. If the iitiator fails durig the secod phase ad it ca recover quickly eough to cofirm or cacel all of the reservatios, the failure has o effect o the outcome of the busiess activity ad, thus, distributed atomicity is satisfied. Recall that we assumed that the iitiator ca recover promptly. If this assumptio is violated ad timed reservatios are used i the busiess activity, the iitiator is forced ito a defied-abort outcome. Now, suppose that a participat fails durig the secod phase ad that as a result, the iitiator caot get immediate feedback from its cofirmatio or cacellatio request for the reservatio it placed with that participat. Accordig to our assumptios, the participat must retrieve the cofirmatio/cacellatio request from a message log ad determie the reservatio charge based o the timestamp icluded i the message. I particular, if a cofirmatio request is foud with a timestamp before the deadlie for a timed reservatio, the request must be hoored. Therefore, the failure of a participat durig the secod phase does ot affect the outcome of the busiess activity. Cosequetly, the defied atomicity will be maitaied Defied Cosistecy The reservatio protocol istatiatio also maitais the defied cosistecy property of the busiess activity. The data are left i a cosistet state, both locally withi a sigle eterprise ad distributed across multiple eterprises, because of the coordiatio of the reservatio subtask ad the cofirmatio/cacellatio subtask ad because the traditioal ACIDcosistecyproperty holds for each such subtask Disjoit Resource Isolatio Because the resources are held exclusively for the cliet that made the reservatio, the reservatio protocol istatiatio esures that disjoit sets of resources are assiged to cocurret busiess activities, regardless of faults. The protocol allows a busiess activity to see whether its ow requests for resources are grated or deied withi the reservatio subtask, but it caot see the details of requests or reservatios by other cocurret busiess activities. This visibility does ot compromise the disjoit resource isolatio property, because the other busiess activities caot make ay assumptios about the future of the resources that have ot bee reserved for them. Furthermore, the ability to complete the processig of a busiess activity, withi the resources that have bee reserved for it, caot be impeded by the trasactios of other cocurret busiess activities. Whe the cacellatio subtask releases resources that have bee reserved, those resources are made available to the iitiators of other reservatios withi the same or differet busiess activities. Thus, the resource protocol istatiatio satisfies the disjoit resource isolatio property Durability Each trasactio withi a busiess activity satisfies the ACID durability property. I particular, the reservatio subtask ad the cofirmatio/cacellatio subtask are trasactios that satisfy the ACID durability property. This fact, together with the loggig at the iitiator after each subtask, esures that the reservatio protocol istatiatio satisfies the durability property. 4 COMPARISON WITH OTHER TRANSACTIONAL MODELS I this sectio, we provide a i-depth compariso of our reservatio protocol with other trasactioal models. We start by comparig our reservatio protocol with the escrow trasactioal method, because of the strog similarities betwee the two. We the compare our reservatio protocol with other exteded trasactio models. We coclude this sectio by briefly comparig our reservatio protocol with distributed trasactios based o the two-phase commit protocol to avoid ay cofusio betwee the two. 4.1 Reservatio Protocol versus Escrow Trasactioal Method The escrow trasactioal method [23] allows cocurret updates from differet trasactios o some types of fields (typically aggregate fields) of the database records, ad the reservatio protocol also does so. The update operatios are icremetal or decremetal i ature. The method ivolves some field quatities (referred to as resources i the reservatio protocol), a applicatio-supplied test of the quatity o had (related to resource owers i the reservatio protocol), ad a fial update of the field quatities (referred to as cofirmatio or cacellatio i the reservatio protocol). However, there are both fudametal ad egieerig differeces betwee the escrow trasactioal method ad the reservatio protocol. The escrow trasactioal method is iteded for both log-ruig local trasactios ad distributed trasactios. For distributed trasactios, it uses the two-phase commit protocol, with the associated risk of log delays i the evet of coordiator failure. I cotrast, the reservatio protocol ivolves the use of a reservatio phase ad a cofirmatio/cacellatio phase to coordiate the tasks of a busiess activity across multiple eterprises.

7 I the escrow trasactioal method, oce the database system has decided that the quatity-o-had test is successful ad has iformed the applicatio, it holds the escrow amout idefiitely util the applicatio evetually performs the update operatio ad commits the trasactio. The test-ad-escrow operatio is equivalet to the utimed reservatio i the reservatio protocol. However, realworld busiess rules typically do ot allow the holdig of resources idefiitely, especially if they are held for other eterprises. For practical applicatios, timed reservatios must be supported. The reservatio protocol specifies how the tasks are coordiated, ad the redudacy level of the resources specifies how to achieve the D4 properties of the busiess activities. Because of the cotext i which it was itroduced, the escrow trasactioal method does ot (ad does eed to) cosider the recoverability of the applicatios that drive a log-ruig trasactio (the applicatio ca simply abort all outstadig trasactios o recovery). For the reservatio protocol, this is ot the case. The applicatio that drives the reservatio protocol must be made highly available, ad all successful reservatios must belogged, whichimpliesthatthe failure of a local trasactio ca be accommodated by retryig that trasactio or by selectig a alterative participat. For the escrow trasactioal method, the failure of a participat causes the etire distributed trasactio to abort ad be retried. Cosequetly, the risk of icosistecy for the escrow trasactioal method is similar to the risk of icosistecy for compesatig trasactios, show i Fig. 4a. The reservatio protocol ad the escrow trasactioal method also differ i their implemetatios. The escrow trasactioal method is implemeted iside the database system as a additioal mechaism to eable cocurret updates to some fields of the database records. The database system must maitai escrow records i a escrow joural. For this model to work, the applicatio must idicate the test criteria ad the desired update operatios through SQL-like statemets. For each escrow type field, the database system must maitai a extra data structure to store iformatio eeded for the recovery of the database system, such as a timestamp ad the rage of the quatity o had (the lower limit is the origial quatity mius the escrow amout, ad the higher limit is the origial quatity mius the committed amout). If the escrow test succeeds, the database system flushes the escrow record from the escrow joural. The reservatio strategy elimiates the eed for the database system to be a expert o which fields are escrow types ad to perform the associated escrow jouralig tasks. I the reservatio protocol, the applicatio developers are resposible for determiig which fields are escrow type fields ad for itroducig ay additioal fields that are ecessary to perform the reservatio ad cofirmatio/cacellatio subtasks. This approach is sesible, because the applicatio developers kow the data sematics best, ot the database system, which is iteded to carry out geeric database services. The reservatio protocol approach makes it uecessary to itroduce a proprietary extesio to stadard SQL, which the escrow trasactioal method requires. 4.2 Reservatio Protocol versus Other Exteded Trasactio Models Due to the limitatios of traditioal ACID trasactios, other exteded trasactio models have bee developed. Followig the classificatio of Weikum [30], there are two major types of exteded trasactio models: 1) the trasactioal workflow model [1], [17], [31], which regards a busiess activity as a umber of tasks executed as idepedet trasactios, ad 2) the sematic trasactio model, which aims to preserve the ACID properties as much as possible while improvig the performace of trasactios by exploitig applicatio sematics (for example, to allow relaxatio of the atomicity ad isolatio properties). The sematic trasactio model ca be further differetiated ito two kids of models: 1) the trasactio iterleavig model ad 2) the ope ested trasactio model. The trasactio iterleavig model exploits the compatibility of differet trasactios to allow the cocurret executio of some trasactios while esurig the serializability of those trasactios. I cotrast, the ope ested trasactio model focuses o the compatibility of operatios o abstract data types. Ope ested trasactios are aturally hierarchical. If a operatio o a certai data type is ope, a ew sphere of cotrol ca be spawed. Such a operatio is ofte executed as a subtrasactio, ad its result ca be viewed by other subtrasactios before the top-level trasactio is committed. Operatios withi the subtrasactio ca be further mapped to lower-level subtrasactios. The multilevel trasactio model of Weikum [29] is a special case of the ope ested trasactio model i that its trasactio tree is strictly layered. I cotrast, the traditioal multilevel trasactio model of Lych [19] ca be regarded as closed ested trasactios i which the sphere of cotrol of a closed operatio is its paret operatio. A comprehesive discussio of ested trasactios ca be foud i [22]. The well-kow exteded trasactio protocol sagas [7] ca be categorized as a ope ested trasactio strategy where the operatios o the data types ivolved i a trasactio are compatible with other trasactios. However, sagas are also widely used i workflows as a meas of coordiatig differet trasactios withi a busiess activity, i which case the operatios o some data types might ot be fully compatible with those of other trasactios. Similarly, the reservatio protocol ca be regarded as a special ope ested trasactio strategy (specifically, a two-level ope ested trasactio strategy), ad it ca also be used i the cotext of workflows. However, there exist subtle differeces betwee the reservatio protocol ad typical ope ested trasactio strategies. The reservatio protocol always requires two phases of executios, whereas other ope ested trasactio protocols ivolve oly a sigle phase if the trasactio is successful. I a sese, the reservatio protocol ivolves some loss of efficiecy to gai the ease of cacellatio of the reservatio operatios executed i the first phase. All of the above exteded trasactio models rely o the use of compesatig trasactios to cacel (partially) the effects of some earlier committed trasactios to esure (partial) atomicity. For the sematic trasactio model, this approach works well if the operatios (or trasactios) ca be compesated. Ufortuately, that is ot always the case. Some operatios either caot be compesated or are too expesive to compesate. I workflows, because the operatios from differet trasactios o some data types caot be guarateed to be fully compatible, there is the additioal risk of cascadig compesatios. These problems are well recogized i the literature [11], [28]. However, o effective solutios have bee proposed to address them. For the

8 sematic trasactio model, uless appropriate cocurrecy cotrol is idetified ad eforced cosistetly to preserve the atomicity of a trasactio, such operatios must be deferred to commit time, which essetially forces the model to behave like the traditioal trasactio model [28]. I workflows, oce such a operatio is executed, the workflow must commit, which might lead to oatomicity [11]. 4.3 Reservatio Protocol versus Trasactioal Lockig ad Two-Phase Commit Distributed trasactios based o trasactioal lockig ad two-phase commit ivolve both the lockig of database records withi a sigle eterprise ad the two-phase commit protocol. At a abstract level, resource reservatio ad lockig of a resource are similar i that, i both, the resource is put o hold temporarily. Furthermore, like the two-phase commit protocol, our reservatio protocol ivolves two phases. Despite the apparet similarity of our reservatio protocol to trasactioal lockig ad twophase commit, there are a umber of differeces, which we discuss below. I our protocol, the reservatio of a resource is executed as a traditioal ACID trasactio. The applicatio has full cotrol over the reservatio ad how log the resource is reserved, whereas, i the two-phase commit protocol, the lockig of a resource is iteral to the database system ad is trasparet to the applicatio, which has o cotrol over how log the resource is locked. Note that this property is ot uique to the reservatio protocol may other exteded trasactio protocols possess it as well. Aother differece betwee our reservatio protocol ad lockig is the effect o other trasactios that eed to access the resource. If a resource is reserved ad aother trasactio wats to access it, the trasactio ca acquire a lock o the resource, ad the applicatio ca be iformed immediately of the state of the resource (that is, some of the resource has bee reserved, but a sufficiet quatity of the resource remais to satisfy the reservatio). Thus, the applicatio ca take a appropriate actio without delay. However, if the resource is locked by the database system ad aother trasactio wats to access it, the ew trasactio must wait util the lock is released. The waitig time might be log, i which case the applicatio caot take immediate actio. Oce agai, this characteristic is ot uique to the reservatio protocol. The escrow trasactioal method also has this characteristic. I the two-phase commit protocol, a fault at a participat might cause the rollback of the trasactio, i which case that participat decides uilaterally to abort the trasactio. I cotrast, i our reservatio protocol, oly the iitiator is authorized to commit or roll back the busiess activity. A fault at other participats might affect the iitiator s decisio ad, thus, the outcome of the busiess activity; however, it does ot ecessarily result i the rollback of the etire busiess activity. Agai, this characteristic is ot uique to our reservatio protocol. There exist other exteded trasactio protocols such as the busiess agreemet protocols described i the WS-BA specificatio [5] that have this characteristic. However, they are based primarily o compesatig trasactios. 5 AVAILABILITY AND CONSISTENCY ANALYSES For the purposes of the availability ad cosistecy aalyses, we model a busiess activity as a sequece of oe or more tasks, each of which is a traditioal ACID trasactio. The cocurrecy of tasks withi the busiess activity has o effect o our availability ad cosistecy aalyses. We cosider oly faults that are detected immediately so that a trasactio ca be aborted ad retried immediately. Detectio might ivolve the operatig system, the database, the trasactio or commuicatio middleware, ad customcoded applicatio data validity checks. We do ot cosider faults that allow a trasactio to appear to complete eve though they yield icorrect results that were ot detected. Followig the detectio of a fault i a trasactio, the trasactio or the etire busiess activity is aborted ad retried. We assume that the stadard trasactio commit ad abort mechaisms operate correctly. We cosider oly a sigle retry of the busiess activity ad a sigle retry of compesatig trasactios whe they are used. 5.1 Architectures For compariso ad evaluatio, we cosider four architectures:. No Fault Recovery Architecture. There are o attempts at recovery from faults.. Sigle Distributed Trasactio Architecture. A busiess activity is modeled as a sigle distributed trasactio usig the two-phase commit protocol. If ay part of the busiess activity fails, the etire distributed trasactio is aborted ad the busiess activity is the retried oce oly.. Abort of Trasactios with Compesatig Trasactios Architecture. A busiess activity is still modeled as a sigle distributed trasactio. If ay subtrasactio fails, every completed subtrasactio is aborted by a compesatig trasactio, ad the etire busiess activity is retried oce oly.. Reservatio Protocol Architecture. A busiess activity is modeled as a sequece of idividual trasactios that comprise pairs of reservatio ad cofirmatio/ cacellatio trasactios. If a trasactio withi the busiess activity fails, the trasactio is aborted ad is retried idividually, rather tha the etire busiess activity beig retried. We allow oly oe trasactio withi the busiess activity to be retried. This restrictio is imposed to yield a fair compariso with the other architectures i which the sigle distributed trasactio is retried oce oly. We cosider the effect that each of these architectures has o the availability of the busiess applicatio ad the cosistecy of the databases, particularly whe it ivolves multiple eterprises. I particular:. We ivestigate the probability that all or a large umber of busiess activities will complete successfully. May busiesses must process thousads or millios of activities every day. Each activity that does ot complete successfully ca ivolve difficult ad expesive maual itervetio.. We ivestigate the probability that the databases of the busiess activity might be left i a icosistet state, a icosistecy that might spread across multiple eterprises. Eve a potetial icosistecy ca require difficult ad expesive maual itervetio. There is o itetio that the calculatios preseted here provide accurate probabilities for ay particular busiess applicatio. They are iteded oly to ivestigate the effects

9 Fig. 2. The Markov models for the four architectures. (a) No Fault Recovery Architecture. (b) Sigle Distributed Trasactio Architecture. (c) Compesatig Trasactio Architecture. (d) Reservatio Protocol Architecture. o availability ad cosistecy for the particular architecture chose. 5.2 Markov Models ad Parameters We estimate the probability that all of the trasactios i a busiess activity complete successfully ad the probability that the databases might have bee left i a icosistet state. We use a discrete-time Markov model for each architecture. The parameters of the Markov models are give as follows:. : the umber of trasactios i a busiess activity.. m: the umber of busiess activities over the period of iterest (per hour, per day, etc.).. f: the probability that a sigle trasactio does ot complete successfully, 0 < f<1.. g: the probability that a compesatig trasactio does ot complete successfully, 0 < g<1. Thus, we assume that each trasactio has the same probability f of failure ad that each correspodig compesatig trasactio has the same probability g of failure. I the illustratios of the Markov models, for coveiece of presetatio, we show oly ¼ 6 trasactios. The illustratios of the Markov models ca be easily exteded to more trasactios. Real busiess activities typically ivolve more tha six trasactios, as do the busiess activities show i our results below No Fault Recovery Architecture Fig. 2a shows the Markov model for calculatig the probability that a busiess activity with trasactios

10 completes successfully with o attempts at recovery from faults. This architecture is icluded as a baselie. The probability that all of the m busiess activities complete successfully is give by m ð1 - fþ : Sigle Distributed Trasactio Architecture Fig. 2b shows the Markov model for a busiess activity that is processed as a sigle distributed trasactio usig the two-phase commit protocol. If a subtrasactio fails, the etire busiess activity is aborted ad retried oce oly. We assume that the abort is correct ad, thus, that there is o risk that the databases are left i a icosistet state. The probability of success o the first attempt of the busiess activity is ð1 - fþ, ad the probability of abortig the first attempt of the busiess activity is 1 -ð1 - fþ. The probability of success of the retry of the busiess activity is ð1 - fþ. The overall probability of success of the busiess activity is give by ð1 - fþ þð1 -ð1 - fþ Þ*ð1 - fþ ¼ð1 - fþ ð2 -ð1 - fþ Þ: Thus, the probability that all of the m busiess activities complete successfully is give by ( ) m ð1 - fþ ð2 -ð1-fþ Þ : Abort of Trasactios with Compesatig Trasactios Architecture Fig. 2c shows the Markov model for this architecture, where a busiess activity is still processed as a sigle trasactio, but if a subtrasactio fails, each completed subtrasactio is aborted by a compesatig trasactio. The etire busiess activity is retried oce oly, ad each compesatig trasactio is retried oce oly. If a compesatig trasactio caot be completed successfully, eve after a retry, the potetial exists that databases are left i a icosistet state ad that maual itervetio is required. This model is also appropriate for the distributed escrow trasactioal method, although the value of g will be less because for the distributed escrow trasactioal method, the compesatios are simple rather tha arbitrarily complex as they might be for the geeral compesatig trasactios architecture. The probability of success o the first attempt of the busiess activity is give by ð1 - fþ : If a fault occurs i the secod subtrasactio ad the first trasactio is compesated, the probability that the first attempt of the compesatio fails ad the retry of that attempt fails is g 2, ad the probability that either the first attempt of the compesatio or the retry of that attempt succeeds is 1 - g 2. If a fault occurs i the third subtrasactio, the first ad secod subtrasactios are compesated. The probability that the compesatios of both the first ad 2 secod subtrasactios succeed is ð1 - g 2 Þ, ad the probability that oe or the other of those compesatios does ot 2 succeed is 1 -ð1 - g 2 Þ. Thus, the probability that a fault occurs durig the first attempt of the busiess activity so that the first attempt is aborted ad the successful trasactios of the first attempt are compesated successfully to allow the retry of the busiess activity is give by 2 2 f þð1 - fþfð1 - g 2 Þþð1 - fþ fð1 - g 2 Þ þ...þ -1-1 ð1 - fþ fð1 - g 2 Þ ( ) 1 -ð1-fþ ð1 - g 2 Þ ¼ f ; 1 -ð1-fþð1 - g 2 Þ usig the formula for the sum of a fiite geometric series. The probability of success o either the first or the secod attempt of the busiess activity is give by ( ( )) 1 -ð1-fþ ð1 - g 2 Þ ð1 - fþ þð1-fþ f 1 -ð1-fþð1 - g 2 Þ ( ( )) 1 -ð1-fþ ð1 - g 2 Þ ¼ð1-fÞ 1 þ f : 1 -ð1-fþð1 - g 2 Þ Cosequetly, the probability that all of the m busiess activities complete successfully is give by ( ( ( ))) m 1 -ð1-fþ ð1 - g 2 Þ ð1 - fþ 1 þ f : 1 -ð1-fþð1 - g 2 Þ If a compesatig trasactio fails ad the retry of the compesatig trasactio also fails, the databases are left i a potetially icosistet state, ad maual itervetio is required. The potetial icosistecy might arise due to a fault i the first attempt of the busiess activity ad the failure to compesate the first attempt with probability Þ ð1 - fþfð1 -ð1 - g 2 ÞÞþð1 - fþ fð1 -ð1 - g Þ ð1 - fþ fð1 -ð1-g Þ ( ) 2-1 ¼ f 1 þð1-fþþð1-fþ þ...þð1-fþ ( Þþ...þ f 1 þð1-fþð1 - g 2 Þþð1-fÞ ð1 - g Þ þ...þ ) -1 2 Þ -1 ð1 - fþ ð1 - g ( ) 1 -ð1-fþ 1 -ð1-fþ ð1 - g 2 Þ ¼ f - ; 1 -ð1-fþ 1 -ð1-fþð1 - g 2 Þ usig the sum of a fiite geometric series twice. The potetial icosistecy might also arise due to a fault i the first attempt that is successfully compesated, followed by a retry of the etire busiess activity, durig which a further fault occurs for which compesatio is ot successful. The probability that a fault occurs i the first attempt ad is successfully compesated is give by ( ) 1 -ð1-fþ ð1 - g 2 Þ f : 1 -ð1-fþð1 - g 2 Þ The probability that a fault occurs i the secod attempt ad caot be compesated is the same as the probability that a fault occurs i the first attempt ad caot be compesated. Thus, the probability of a potetial icosistecy i either attempt is give by

11 ( ) 1 -ð1-fþ 1 -ð1-fþ ð1 - g 2 Þ f - 1 -ð1-fþ 1 -ð1-fþð1 - g 2 Þ ( ) 1 -ð1-fþ ð1 - g 2 Þ þ f 1 -ð1-fþð1 - g 2 Þ ( ) 1 -ð1-fþ 1 -ð1-fþ ð1 - g 2 Þ x f - 1 -ð1-fþ 1 -ð1-fþð1 - g 2 Þ ( ) 1 -ð1-fþ ð1 - g 2 Þ ¼ f 1 þ f 1 -ð1-fþð1 - g2 Þ ( ) 1 -ð1-fþ 1 -ð1-fþ ð1 - g 2 Þ x - : 1 -ð1-fþ 1 -ð1-fþð1 - g 2 Þ Cosequetly, the probability that withi m busiess activities, the databases are left i a potetially icosistet state is give by ( ( ) 1 -ð1-fþ ð1 - g 2 Þ f 1 þ f 1 -ð1-fþð1 - g2 Þ ( )) m 1 -ð1-fþ 1 -ð1-fþ ð1 - g 2 Þ x - : 1 -ð1-fþ 1 -ð1-fþð1 - g 2 Þ Reservatio Protocol Architecture Fig. 2d shows the Markov model for this architecture, where each trasactio of the busiess activity is retried idividually, rather tha the etire busiess activity beig retried. We assume that oly oe trasactio i a busiess activity ca be retried to yield a fair compariso with the distributed trasactio architecture, where the etire distributed trasactio is retried oce oly. If that retry also fails, the busiess activity fails, ad all of its reservatios are cacelled. Those cacellatios ca be either explicit cacellatios or expiratios of reservatios. I both cases, the cacellatio requires the executio of a trasactio that might ot complete, ad the model icludes the probability of such a fault. Oe retry is allowed for each explicit cacellatio or expiratio of a reservatio. The probability that the busiess activity completes successfully with o trasactios failig is ð1 - fþ. The probability that exactly oe of trasactios failed ad the succeeded whe retried while the other - 1 trasactios succeeded is fð1 - fþ. Thus, the probability that a busiess activity completes successfully is give by ð1 - fþ þ fð1 - fþ ¼ð1 - fþ ð1 þ fþ: Cosequetly, the probability that all of the m busiess activities complete successfully is give by m ðð1 - fþ ð1 þ fþþ : The probability that two trasactios or oe trasactio ad its retry have failed is give by -1 f 2 þ 2f 2 ð1 - fþþ3f 2 ð1 - fþ 2 þ... þ f 2 ð1 - fþ : I this case, all successfully completed reservatios must be cacelled. Two attempts are allowed for each cacellatio trasactio. The probability that oe of the reservatios is ot cacelled (because the local trasactio for a reservatio cacellatio failed eve whe retried) is give by Þ 2f 2 ð1 - fþð1 -ð1 - g 2 ÞÞ þ 3f 2 ð1 - fþ ð1 -ð1 - g Þ f 2 ð1 - fþ ð1 -ð1-g ÞÞ ( ) 2-1 ¼ f 2 1 þ 2ð1 - fþþ3ð1 - fþ þ... þ ð1 - fþ ( Þþ... þ 2 - f 2 1 þ 2ð1 - fþð1 - g 2 Þþ3ð1 - fþ 2 ð1 - g 2 Þ þ... þ ) -1-1 ð1 - fþ ð1 - g 2 Þ! þ1 1 -ð þ 1Þð1 - fþ þ ð1 - fþ ¼ f 2 2 ð1 -ð1-fþþ! þ1 þ1 1-ðþ1Þð1-fÞ ð1-g 2 Þ þð1-fþ ð1-g 2 Þ - f 2 ; 2 ð1 -ð1-fþð1 - g 2 ÞÞ where we have applied the followig formula twice: -1 ¼ 1 -ð þ 1Þx þ x 1 þ 2x þ 3x 2 þ... þ x 2 ð1 - xþ Cosequetly, the probability that for m busiess activities, the reservatio cacellatios succeed is give by! 1 -ð þ 1Þð1 - fþ þ ð1 - fþ 1 - f 2 2 ð1 -ð1 - fþþ þ1 þ1 þ1 þ1 1-ðþ1Þð1-fÞ ð1-g 2 Þ þð1-fþ þf 2 2 ð1-ð1-fþð1-g 2 ÞÞ ð1-g 2 Þ :!! m ad, thus, the probability that withi m busiess activities, the databases are left i a potetially icosistet state is give by! þ1 1 -ð þ 1Þð1 - fþ þ ð1 - fþ f 2 ð1 -ð1-fþþ 2!! þ1 þ1 m 2 Þ þ f 2 1-ðþ1Þð1-fÞ ð1-g 2 Þ þð1-fþ ð1-g : 2 ð1 -ð1-fþð1 - g 2 ÞÞ 5.3 Compariso of Availability ad Cosistecy For this compariso, we assume that there are ¼ 20 trasactios per busiess activity for the No Fault Recovery Architecture, the Sigle Distributed Trasactio Architecture, ad the Abort of Trasactios with Compesatig Trasactios Architecture. For the Reservatio Protocol Architecture, we assume that there are ¼ 40 trasactios per busiess activity, that is, 20 tasks, each of which ivolves two subtasks (reservatio ad cofirmatio/ cacellatio), each of which is a trasactio. I all of the graphs, the x-axis represets the umber m (from 1 to 10 9 ) of busiess activities withi a hour, day, week, moth, year, or whatever time period is of iterest. Each curve o the graph represets the probability (from to 10-6 ) that a idividual trasactio fails. Here, we assume that the probability g that a compesatig trasactio or a reservatio cacellatio (or expiratio) trasactio fails is the same as the probability f that a regular trasactio fails. Fig. 3a shows the probability that all of the m busiess activities complete successfully whe there is o attempt to recover from faults. Note that because there is o attempt to