Delegation: Efficiently Rewriting History

Transcription

1 Delegtion: Efficiently Rewriting History Cris Pedregl Mrtin nd Krithi Rmmrithm Deprtment of Computer Science University of Msschusetts Amherst, Mss cris, Abstrct Trnsction delegtion, s introduced in ACTA, llows trnsction to trnsfer responsibility for the opertions tht it hs performed on n object to nother trnsction. Delegtion cn be used to broden the visibility of the delegtee, nd to tilor the recovery properties of trnsction model. Delegtion hs been shown to be useful in synthesizing Advnced Trnsction Models. With n efficient implementtion of delegtion it becomes prcticble to relize vrious Advnced Trnsction Models whose requirements re specified t high level lnguge insted of the current expensive prctice of building them from scrtch. In this pper we identify the issues in efficiently supporting delegtion nd hence dvnced trnsction models, nd illustrte this with our solution in ARIES, n industril-qulity system tht uses UNDO/REDO recovery. Since delegtion is tntmount to rewriting history, nïve implementtion cn entil frequent, costly log ccesses, nd cn result in complicted recovery protocols. Our lgorithm chieves the effect of rewriting history without rewriting the log, resulting in n implementtion tht relizes the semntics of delegtion t miniml dditionloverhed nd incurs no overhed when delegtion is not used. Our work indictes tht it is fesible to build efficient nd robust, generl-purpose mchinery for Advnced Trnsction Models. It lso leds towrd mking recovery firstclss concept within Advnced Trnsction Models. 1 Introduction The trnsction model dopted in trditionl dtbse systems hs proven indequte for novel pplictions of growing importnce, such s those tht involve rective (endless), open-ended (long-lived), nd collbortive (interctive) ctivities. Vrious Advnced Trnsction Models (ATMs) hve been proposed [7, 17], ech custom built for the ppliction it ddresses; ls, no one extension is of universl pplicbility. To ddress this problem, we hve been investigting how to crete generl-purpose nd robust support for the specifiction nd implementtion of diverse ATMs. Our strtegy hs been to work from first principles, first identifying the bsic elements tht give rise to different models nd showing how to relize vrious ATMs using these elements, nd then proposing mechnisms for implementing these elements. A first step ws ACTA [6], tht identified, in forml frmework, the essentil components of ATMs. In more opertionl terms, ASSET [3] provided set of new lnguge primitives tht enble the reliztion of vrious ATMs in n object-oriented dtbse setting. In ddition to the stndrd primitives Initite (to initilize trnsction), Begin, Abort, nd Commit, ASSET provides three new primitives: form-dependency, toestblish structure-relted intertrnsction dependencies, permit, tollow for dt shring without forming inter-trnsction dependencies, nd delegte, which llows trnsction to trnsfer responsibility for n opertion to nother trnsction. Trditionlly, the trnsction invoking n opertion is lso responsible for committing or borting tht opertion. With delegtion the invoker of the opertion nd the trnsction tht commits (or borts) the opertion my be different. In effect, to delegte is to rewrite history, becuse delegtion mkes it pper s if the delegtee trnsction hd been responsible for the delegted object ll long, nd the delegtor hd nothing to do with it. Delegtion is useful in synthesizing ATMs becuse it brodens the visibility of the delegtee, nd becuse it controls the recovery properties of the trnsction model. The brodening of visibility is useful in llowing delegtor to selectively mke tenttive nd prtil results, s well s hints such s coordintion informtion, ccessible to other trnsctions. The control of the recovery mkes it possible to decouple the fte of n updte from tht of the trnsction tht mde the updte; for instnce, trnsction my delegte some opertions tht will remin uncommitted but live fter the delegtor trnsction borted. Exmples of ATMs tht cn be synthesized using delegte re Joint Trnsctions, Nested Trnsctions, Split Trnsctions, nd Open Nested Trnsctions [6, 8].

2 Biliris et l. [3] gve high-level description of how to relize the three new ASSET primitives. Briefly, permit is done by suitbly dding the permittee trnsction to the object s ccess descriptor. Form-dependency is done by dding edges to the dependency grph, fter checking for certin cycles. Wheres the reliztion of permit nd formdependency re rther stright-forwrd, close ttention must be pid to logging nd recovery issues in the presence of delegtion. This is becuse recovery usully keeps some kind of system history (e.g., log) nd delegtion is tntmount to rewriting history ( delegted object s opertions pper to hve been done by the delegtee). Our gol in this pper is to develop robust nd efficient implementtion of delegtion tht tkes dvntge of existing, industril-strength technology. To this end, we consider log-bsed systems becuse logs re feture of mny prcticl systems, which rely on logs for uditing nd other functions besides recovery. We do not consider lterntive pproches requiring new, d-hoc infrstructure tht my be esier to chieve, but does not integrte with existing technology. To further the gol of providing generl purpose mchinery to support the specifiction nd implementtion of rbitrry ATMs, we hve developed efficient implementtions of delegtion on two log-bsed recovery systems. For lck of spce we present here only our ARIES[13] -bsed solution. In longer version of this pper [15] we demonstrte the correctness of the implementtion nd lso discuss how to implement delegtion on EOS [4]. Our dditions llow the efficient Rewriting of History, so we cll our protocol ARIES/RH. By providing delegtion, we dd substntil semntic power to conventionl Trnsction Mngement System (TMS), llowing it to cpture vrious ATMs. We efficiently chieve this expressiveness by crefully piggy-bcking the delegtion-relted processing onto the routine processing. During recovery, our lgorithm neither dds costly log sweeps to the recovery lgorithm, nor does it demnd the rewriting of the log. In this pper we rgue tht: Delegtion is powerful, importnt primitive for relizing ATMs. We describe its properties nd show how it cn be used to mnipulte visibility nd recovery properties of trnsctions. It is possible to implement delegtion in n industrilstrength trnsction mngement system such s ARIES, such tht when delegtion is not used no overheds re incurred. Development of provbly correct nd efficient implementtion is very importnt contribution becuse it shows tht generic, flexible, nd prcticl ATM fcility cn be produced. The reminder of the pper is orgnized s follows. In section 2 we describe the properties of delegtion nd show how it cn be used to synthesize some well-known ATMs. In section 3 we develop delegtion in the context of robust, industril-grde trnsction mngement system. First we explin delegtion s semntics in terms of rewriting history. We then discuss the needed dt structures nd describe how we modify both the norml processing nd the recovery phses to support delegtion, nd explin how to pply our lgorithm to ARIES. In section 4 we discuss why our lgorithm efficiently implements delegtion. In section 5 we review relted work; in section 6 we present our conclusions nd discuss future work. 2 Delegtion: Properties nd Exmples In this section, first we introduce some nottion, then we explin delegtion in terms of visibility nd recovery, nd then point out its importnt properties. Finlly, we present exmples of ATMs nd show how to synthesize one of them using delegtion. 2.1 Wht: Concepts nd Properties Here we describe the properties of delegtion, introduce nottion nd stte our ssumptions. t t 0 t 1 t 2 ::: denote trnsctions; ob b ::: denote objects in the dtbse. updte is generic opertion on dtbse objects. We write updt[ob] nd leve other detils of the updte unspecified. Updtes re done in-plce on the updted object. Note tht not ll updte opertions conflict with ech other. delegte(t 1 t 2 updt[ob]) denotes delegtion by t 1 to t 2 of updt[ob]. Invoking trnsction. We cll the trnsction tht invoked the updte on the object the invoking trnsction. We write updt[t ob] when we wish to indicte tht t is the invoking trnsction for tht updte. H denotes the history of the dtbse, which contins events such s delegte nd updte, with prtil order indicted! 0 where precedes 0. Opertion invoctions re events. ResponsibleTr. A trnsction responsible for n updte is in chrge of committing or borting it, unless it delegtes it: ResponsibleTr(updt[ob]) = t holds from when t performs updt[ob] or t is delegted updt[ob] until t either termintes or delegtes updt[ob]. 1 Op List. The dul of ResponsibleTr is the Op List. It contins the opertions trnsction is responsible for: Op List(t) = = fupdt[ob] j ResponsibleT r(updt[ob]) = tg: Pre- nd Postconditions. When t 1 executes delegte(t 1 t 2 updt[ob]), wesy tht t 1 trnsfers its responsibility for updt[ob] to trnsction t 2, i.e., pre(delegte(t 1 t 2 updt[ob])) ) (ResponsibleT r(updt[ob]) = t 1) t 1 must be the trnsction responsible for updt[ob] in order to delegte the updte. 1 Notice tht without delegtion, the trnsction responsible for n updte is lwys the invoking trnsction.

3 post(delegte(t 1 t 2 updt[ob])) ) (ResponsibleT r(updt[ob]) = t 2) After t 1 delegtes updt[ob] to t 2, t 2 becomes the responsible trnsction for the updte. Opertion delegte(t 1 t 2 updt[ob]) is well formed when t 1 nd t 2 re initited nd not terminted, nd t 1 is responsible for updt[ob]. Commit/Abort of Updtes. In the presence of delegtion, the fte of updtes to n object is tht of the trnsction to which the opertion ws lst delegted. For instnce, if t 0 does updt[ob], then delegtes updt[ob] to t 1, nd t 0 subsequently borts, the chnges t 0 mde to ob vi updt[ob] will still survive if t 1 commits while it is still responsible for updt[ob]: (Commit(t) 2 H) () (8updt[ob] 2 Op List(t) :(commit t(updt[ob]) 2 H)) Tht trnsction t commits mens tht ll of the updtes in its Op List must be committed. Notice tht these re the updtes for which t is responsible. (Abort(t) 2 H) () (8updt[ob] 2 Op List(t) (bort t(updt[ob]) 2 H)) Tht trnsction t borts requires tht ll of the updtes it is responsible for (i.e., those in its Op List) will be borted. The events Commit(t) nd Abort(t) denote the commit nd bort of trnsction t, nd commit t (updt[ob]) nd bort t (updt[ob]) indicte the permnence or oblitertion of the chnges done by updt[ob]. Inthe presence of delegtion, the chnges my hve been mde by either t or other trnsction(s) which eventully delegted updt[ob] to t. Grnulrity: delegting one opertion vs. set of opertions. In wht we hve discussed, trnsction delegtes single opertion with ech invoction of delegte. Delegtion of set of opertions in single invoction cn be considered s the tomic invoction of multiple delegtions, one for ech of the opertions in the set. Delegting n object is tntmount to delegting ll the opertions on tht object. In our implementtion we consider the delegtion of objects becuse in mjority of prcticl situtions tht we hve come cross, delegtion occurs t the grnulrity of objects. Also, in the exmples discussed in the next subsection, trnsctions delegte objects. Other Properties of Delegtion. An opertion cn be delegted only by the trnsction tht is responsible for it. Since ResponsibleT r(updt[ob]), istny given time, unique, only one trnsction cn delegte n opertion t ny point. Thus, while history my contin two or more delegtions of the sme opertion by different trnsctions, the delegtions for the sme opertion cnnot occur concurrently. Note tht it is possible for severl trnsctions to updte n object concurrently (sy, when the updtes commute). Delegtion of one such opertion by one of the concurrent trnsctions only delegtes tht trnsction s opertion on the object. The other trnsctions opertions re not ffected. Similrly, when trnsction delegtes n object, only tht trnsction s opertions on the object re delegted. Also note tht trnsction cn perform opertions on n object even fter it hs delegted (n opertion on) tht object. Of course, since fter delegtion the system considers the delegted opertions to hve been done by the delegtee, trnsction s new opertion my conflict with one of its own one which hs been delegted. 2.2 Why: Synthesizing ATMs Exmples In this section we motivte delegtion through exmples of its ppliction in the synthesis of ATMs. Other exmples cn be found in [6, 5]. Inheritnce in Nested Trnsctions [14] is n instnce of delegtion. It is chieved through the delegtion of ll the chnges the child trnsction t c is responsible for to its prent t p when t c commits. A trnsction cn delegte t ny point during its execution, not just when it borts or commits. For instnce, in Split Trnsctions [16], trnsction t 1 my split into two trnsctions, t 1 nd t 2,tny point during its execution. Opertions invoked by t 1 on objects in set ob set re delegted to t 2. t 1 nd t 2 cn now commit or bort independently. (Thus, split trnsction cn ffect objects in the dtbse by committing nd borting the delegted opertions even without invoking ny opertion on the objects.) Consider the following code used by t 1 to split off trnsction t 2 (the code for t 2 is tht of function f.) t2 = initite(f); delegte(self(), t2, ob_set); // self returns t1 begin (t2); t 2 cn join t 1 by executing: wit (t2); delegte (t2,t1); // t2 delegtes *ll* objects 3 How: Rewriting History Efficiently In this section we discuss how to efficiently implement delegtion nd present our lgorithm RH (rewrite history), s follows. In 3.1 we give the opertionl semntics of delegtion. In 3.2 we exmine lterntive solutions nd give n overview of our lgorithm. In 3.3 we set the stge with n overview of ARIES, whose UNDO/REDO protocol requires two psses, one forwrd nd one bckwrd, over the log. The followingsubsections explin the lgorithm ARIES/RH in detil: we present the dt structures involved in 3.4, then we describe in 3.5 wht ARIES/RH does during norml processing. In 3.6 we discuss how ARIES/RH s recovery relizes delegtion efficiently using the sme psses over the log s ARIES. 3.1 Opertionl Semntics In generic Dtbse System the log is the system s history, s it contins the records of ll updtes nd trnsctionl opertions. The ide of delegtion is to rewrite history, selectively ltering the log. Suppose tht delegte(t 1 t 2 ob) is the first delegtion of ob by t 1. Applying this delegtion

4 K currlsn (LSN of delegte record ) while LOG[K] is not the initite record for t 1 if LOG[K] is n updte to ob by t 1 then settrnsid(k,t 2) now looks s if done by t 2 K prevlsn(k,t 1) follow t 1 s BC Figure 1. Op. Semntics of delegte(t 1 t 2 ob) cn be visulized s iterting through the log into the pst, modifying the records pertining to ob, so tht ech record of n ccess to ob by t 1 will now show tht the ccess ws done by t 2. Figure 1 gives the opertionl description of delegtion in terms of the log, for scenrio where K indictes the LSN being operted on in the current itertion. Records hve PrevLSN field, tht contins the LSN of the previous record for the sme trnsction. The chin formed by the previous LSN pointers of log records of trnsction is clled Bckwrd Chin (see section 3.3). The delegte record is new type of log record for delegtion, with pointers to the previous records of both the delegtor nd delegtee (see section 3.4). In figure 1 we use the following opertions on the log: prevlsn(k, t 1) which returns the Log Sequence Number of the previous (most recent) log record written by t 1 (i.e., before, or to the left of K). settrnsid(k,t 2), which does LOG[K].TrnsID t 2, mking the record pper s if it hd been written by the trnsction t 2. The fields in log record re: LSN (log-sequence number), Type (updte, delegtion, commit, etc.), Trns-ID (the ID of the trnsction the record pertins to), nd Dt. For delegte records there lso exist two LSN pointers, one to the delegtor nd nother to the delegtee (see section 3.4). Exmple 1. Consider the log frgment (see fig. 2): updt[t 1 ] updt[t 2 x] updt[t 2 ] updt[t 1 b] updt[t 1 ] updt[t 2 y] After the ppliction of delegte(t 1 t 2 ), the log looks like: updt[t 2 ] updt[t 2 x] updt[t 2 ] updt[t 1 b] updt[t 2 ] updt[t 2 y] before rewriting updte updte t 1 t 2 x updte t 2 updte updte updte delegte t 1 b t 1 t 2 y t1 t 2 fter rewriting time updte updte updte updte updte updte delegte t 1 t 2 t 2 x t 2 t 1 b t 1 t 2 t 2 y t1 t 2 Figure 2. Log in Exmple Implementing Delegtion Efficiently The ide of rewriting history by modifying the log is simple, but its implementtion is not. The nïve implementtion of the lgorithm in figure 1 (pply ech delegtion to the log s the delegtion is issued) crries high performnce costs, due to the per-delegtion rndom-ccess to the log, nd is lso hrd to prove correct becuse we mnipulte the log outside the usul ppend-only mode, complicting the model with extr dt. 2 The observtion tht during norml processing the log is not consulted suggests n lgorithm tht keeps trck of the effect of delegtions in voltile dt structures, nd logs the delegtions. After crsh the delegtions cn be pplied by modifying the log rewriting history during recovery. Still, one must ddress issues of performnce nd correctness in the fce of filure, becuse the log is ccessed/modified rndomly. Correctness is ensured if ech BC switch is done tomiclly. 3 Performnce, however, is hostge to the wy the log is ccessed. In generl, the log does not fit wholly into voltile storge, resulting in thrshing, s the lgorithm needs to jump over possibly lrge sections of the log to follow bckwrd chin pointers. To void these pitflls, we propose RH, lzy lgorithm for rewriting history tht does not modify the log, s follows. During norml processing, we use voltile tble to keep trck of which objects re updted by which trnsctions. When delegtion hppens, we chnge the corresponding object binding, nd log delegtions to be ble to reproduce the chnge fter the crsh. During recovery, on encountering delegtions during the log sweeps, we reconstruct the bindings between opertions on objects nd trnsctions, but do not ctully rewrite the log records. Thus we rewrite the history of the system not by modifying the log, but by interpreting the log during recovery ccording to the delegtions. 3.3 Conventionl Recovery: ARIES We review ARIES to estblish context nd terminology. ARIES uses n UNDO/REDO protocol, which mens tht fter crsh, updtes by loser (uncommitted) trnsction will be undone nd those by winner (committed) redone. ARIES scns the log in three psses, see figure 3. 4 The (forwrd) Anlysis pss updtes the informtion on ctive trnsctions nd determines the loser trnsctions. The (forwrd) Redo pss repets history, writing to the dtbse those logged updtes tht hd not been pplied to the dtbse before the crsh; this re-estblishes the DB stte t filure time, including uncommitted updtes. The 2 Extr dt: informtion ccessed by trnsctions tht is not prt of the dtbse schem; for exmple, the log, the system clock, wit-for grph. Gehni et l. [8] discuss the issues of correctness with extr dt. 3 It is esier to tolerte unusul log mnipultions during recovery thn during norml processing. 4 Some vrints of ARIES merge the two forwrd psses into one, thus we lso use only one forwrd pss.

5 LOG Checkpoint Anlysis Redo All Undo Losers Filure Figure 3. ARIES psses over the log. PASSES (bckwrd) Undo pss rolls bck ll the updtes by loser trnsctions in reverse chronologicl order strting with the lst record of the log. ARIES keeps, for ech trnsction, Bckwrd Chin (BC, see figure 4). All the log records pertining to one trnsction form linked list BC, ccessible through Tr List, which points to the most recent one. ARIES inserts compenstion log records (CLRs) in the BC fter undoing ech log record s ction. 5 Applying delegte(t 1 t 2 ob) is tntmount to removing the subchin of records of opertions on ob from BC(t 1 ) nd merging it with BC(t 2 ). But this is not vible implementtion s it would demnd uncceptbly frequent, rndom ccesses nd updtes to the log; insted, we hve devised efficient lgorithms tht support delegtion without modifying the log, which we discuss next. First we present the dt structures, nd we explin the norml processing. We then exmine recovery processing, first the forwrd (nlysis & redo) pss nd then the bckwrd (undo) pss updte updte updte updte updte updte delegte t 1 t 2 x t 2 t 1 b t 1 t 2 y t1 t 2 time Figure 4. Bckwrd Chins in the log. BC(t1) BC(t2) 3.4 Dt Structures We must know which opertions on which objects ech trnsction t is responsible for, i.e., its Op List(t) (see section 2.1). For tht we use the Trnsction List nd expnd ech trnsction s Object List found in conventionl Dtbse Systems; we lso dd delegte type log record. Tr List. The Trnsction List [2, 10, 13] contins, for ech Trns-ID, the LSN for the most recent record written on behlf of tht trnsction, nd, during recovery, whether trnsction is winner or loser. 6 Ob List. For ech trnsction t there is n Ob List(t) (In figure 7, Ob List(t 1 ) contins the objects t 1 is ccessing 5 To void undoing n updte repetedly should crshes occur during recovery. 6 For ech trnsction t, Tr List(t) contins the hed of the BC(t). field nme LSN tor torbc tee teebc function position within the LOG trnsction id of delegtor delegtor s bckwrd chin trnsction id of delegtee delegtee s bckwrd chin Figure 5. Fields of the delegte log record fter the delegtion.) In terms of Op List: Ob List(t) = fob j 9updt[t 0 ob] 2 Op List(t)g, i.e., the objects for which there is n updte for which t is responsible. The updte my hve been invoked by t 0 nd the responsibility trnsferred to t vi delegtion. When trnsctions re responsible for specific updtes (not whole object), certin object my pper in more thn one Ob List (but the ssocited updtes will be different). 7 We identify the updtes tht trnsction is responsible for by introducing the notion of scope. object b Scopes ( t 1, 100, 104) ( t 1, 102, 106) Ob_List (t 1 ) object x y Scopes (t 2, 102, 102) ( t 2, 101, 101) ( t 2, 105, 105) Ob_List (t 2 ) Figure 6. Ob Lists before delegtion, Ex. 1. For ech object ob in Ob List(t 1 ) there is set of scopes Scopes, tht covers the updtes to ob for which t 1 is currently responsible. A scope is tuple (t 0 l 1 l 2 ) where t 0 is the trnsction tht ctully did the opertions (the invoking trnsction), l 1 is the first, nd l 2 the lst LSN in the rnge of log records tht comprise the scope. This indictes tht t 1 is responsible for ll updtes to ob (by t 0 ) between nd including the two LSNs. 8 See figure 7. Delegte Log Records. We dd new log record type: delegte. Its type-specific fields (see figure 5) store the two trnsctions nd object involved in the delegtion. 3.5 Norml Processing We describe ARIES/RH in terms of how different events re processed, focusing on the differences with ARIES. (The current vlue of the log sequence number is CurrLSN.) begin(t) 1. INITIALIZE. Add t to Tr List; crete Ob List(t). updt[t ob] 1. ADJUST SCOPES. If this is the first updte of t to ob since either t strted or lst delegtedob we must open new scope. Otherwise, there is n ctive scope of t on ob tht we must extend. 7 For exmple, this cn occur in the cse of non-conflicting updtes, such s increments of counter. 8 This llows us to compute ResponsibleT r (nd Op List) without hving to store/updte it with ech updte.

6 object b Scopes ( t 1, 100, 104) ( t 1, 102, 106) Ob_List (t 1 ) object x y Scopes (t 2, 102, 102) ( t 1, 100, 104) ( t 2, 101, 101) ( t 2, 105, 105) Ob_List (t 2 ) Figure 7. Ob Lists fter delegtion, Ex. 1. if ob =2 Ob List(t) then Ob List(t) Ob List(t) [fobg ; if (t ) 9 =2 Ob List(t)[ob] then Ob List(t)[ob]:Scopes (t, CurrLSN,CurrLSN) crete new scope else Ob List(t)[ob]:Scopes (,,CurrLSN) extend existing scope delegte(t 1 t 2 ob) 1. WELL-FORMED? Verify tht ob 2 Ob List(t 1), which tests, for this cse, the precondition in 2.1: pre(delegte(t 1 t 2 updt[ob])) ) (ResponsibleT r(updt[ob]) = t 1). 2. PREPARE LOG RECORD(S). () Record delegtor, delegtee: Rec:tor t 1; Rec:tee t 2; (b) Link record into t 1 s nd t 2 s bckwrd chins: Rec:torBC BC(t 1) BC(t 1) Rec Rec:teeBC BC(t 2) BC(t 1) Rec. 3. TRANSFER RESPONSIBILITY. Move opertions on ob from Op List(t 1) to Op List(t 2). () Add ob to delegtee s Ob List nd record tht ob ws delegted by t 1: Ob List(t 2) Ob List(t 2) [ fobg ; Ob List(t 2)[ob]:deleg t 1. (b) Pss delegtor s Scopes for ob to the delegtee: Ob List(t 2)[ob]:Scopes Ob List(t 2)[ob]:Scopes [ Ob List(t 1)[ob]:Scopes ; (c) Remove ob from the delegtor s Ob List: Ob List(t 1) Ob List(t 1) ;fobg: Remrk: We use union becuse t 2 my lredy be responsible for some opertions on ob before receiving the delegtion. Therefore, the Scopes field my ctully contin severl scopes: contiguous rnges of LSNs on the log, ech tgged with the trnsction tht initilly ws responsible for tht scope, which is the invoking trnsction for those updtes. (Notice tht the scopes my overlp on the log segment they cover but then cnnot shre the sme invoking trnsction.) 4. WRITE DELEGATION LOG RECORD(S). Write log record nd mrk it s the current hed of the bckwrd chins of delegtor nd delegtee. LOG[CurrLSN] Rec; BC(t 1) CurrLSN; BC(t 2) CurrLSN. 9 denotes field tht we do not chnge or re not interested in. commit(t) 1. COMMIT OPERATIONS. Write to the log the opertions for which t is responsible. 2. WRITE COMMIT RECORD. Write commit record to the log fter the opertions. 3. FLUSH LOG. Write to stble storge ll records in the log, from the previous flush point up to the commit record inclusive. bort(t) 1. ABORT OPERATIONS. Undo the updtes for which t is responsible. (Recll tht ny object previously delegted by the borting trnsction is no longer in the trnsction s Ob List, unless it updted it fter the delegtion.) Obtin minlsn = min fbegin j Ob List(t)[ob]:Scopes = ( begin )g on objects in Ob List(t). For ech object in Ob List(t), undo ll updtes contined in its Scopes, writing to the log the compenstion log records, going bckwrds in the log until minlsn is reched. 2. WRITE ABORT RECORD. Write bort log record to log. 3. FLUSH LOG. Flush log up to bort record. We process other trnsctionl events s usul [10, 13]. Note: The preceding lgorithm ssumes tht delegtion is used often, but the overhed for trnsctions tht do not use delegtion cn be reduced to minimum with the following optimiztion. We dely cretion of n object s entry in trnsction s Ob List until the trnsction either delegtes or is delegted some opertions on tht object. We cn do tht becuse we cn ssume tht the first scope for n object (i.e., the scope for the first time the object is delegted) without n entry in Ob List spns from the begin LSN to the delegte LSN of the delegting trnsction, insted of strting t the first updte of the trnsction to tht object. Furthermore, when trnsction delegtes n object it removes the ssocited scopes but keeps n empty entry in its Ob List, sotht it knows to open new scope when nd if it ccesses the object lter. Without the retention of this entry it could erroneously ssume tht the scope strts t the begin LSN. If the lgorithm is modified in ccordnce with this chnge, when delegtion is not used it reduces to the trditionl lgorithm. (This lso reduces the size of the object lists mintined in min memory since only entries pertining to delegted objects need be mintined.) Thus, the only extr work for non-delegted objects during norml processing is checking whether they hve n entry in Ob List. For detils see [15]. 3.6 Crsh Recovery After crsh, the trnsction system must recover to consistent stte, restoring the stte from checkpoint (retrieved from stble storge), nd using the log (lso from stble storge) to reproduce the events fter the checkpoint ws tken. For simplicity of presenttion, we ignore checkpoints from now on, but it is esy to see how dt structures

7 cn be rebuilt using checkpoints insted of going bck to the beginning. 10 In the rest of this section,we present the recovery phse of ARIES/RH, which includes forwrd pss nd bckwrd pss. Here Crsh is the event tht represents filure; RecoveryComplete indictes tht the recovery is complete. W inners nd Losers re s described in Forwrd Pss Before the first pss of recovery strts, W inners = Losers =. Atthe end of the forwrd pss Winners, Losers, nd Object Lists re up to dte, including the scopes of the updtes. 11 begin(t) 1. INITIALIZE. Add t to Tr List; crete Ob List(t). 2. LOSER BY DEFAULT. Consider t loser by defult. Losers Losers [ftg. updt[t ob] 1. ADJUST SCOPES. This is done just s in step (1) of updte in norml processing. 2. REDO. Redo updt[t ob]. delegte(t 1 t 2 ob) 1. TRANSFER RESPONSIBILITY. This is done just s in step (3) of delegte in norml processing. commit(t) 1. COMMIT. Declre t committed. Notice tht t s updtes were redone during this forwrd pss. 2. WINNER. Declre t s winner. Winners Winners [ftg; Losers Losers ;ftg. After the Forwrd Pss the stte is s follows. Ob Lists re restored to their stte before the crsh, for ll trnsctions. Winners hs ll the trnsctions whose updtes must survive (i.e., which hd committed before the crsh). Losers hs those whose updtes must be obliterted. LsrObs includes ll objects in the Ob Lists ofloser trnsctions. We compute it fter the forwrd pss ends, s [ LsrObs = Ob List(t): t2losers Bckwrd Pss To undo loser trnsctions, ARIES continully undoes the updte with mximum Log Sequence Number (LSN), ensuring monotoniclly decresing (by LSN) ccesses to the log, with the ttendnt efficiencies. ARIES undoes ll the updtes invoked by loser trnsction. In the presence of delegtion, wht we need insted is to undo ll the updtes tht were ultimtely delegted to loser trnsction. Notice tht by undoing the loser updtes 10 For instnce, the scope informtion is sved t checkpoints. 11 We only describe the tretment of the logrecords relevnt to delegtion; other records re processed s usul. beglsrscopes no loser scopes loser scopes begcluster current cluster K lredy done bckwrd sweep Figure 8. Loser scope clusters in the log. insted of the updtes invoked by loser trnsctions, we re in fct pplying the delegtions, s we undo ccording to the fte of the finl delegtee of ech updte. 12 An extension nlogous to ARIES involves constructing nd mintining bckwrd chins of loser updtes, n expensive solution. Or one could scn ll log records bckwrds, identifying the loser updtes (to be undone), which re the updtes whose responsible trnsction is loser. This is lso undesirble s it unnecessrily inspects mny winner updtes. Fortuntely, the informtion of updte scopes suffices to efficiently undo loser updtes. In the rest of the section we discuss how undo nd delegtion re integrted in the bckwrd pss. Updte nd delegtion re the only records tht require specil processing. Recll tht scopes keep trck of updtes tht were delegted together (see section 3.4). It is enough to inspect records within the loser trnsction scopes to find ll loser updtes. To do it efficiently, we introduce the notion of cluster of scopes. Scopes my overlp; cluster of scopes is mximl set of overlpping scopes. (We only cre bout loser clusters of scopes, so we omit loser from now on.) Within ech cluster we must exmine every log record, but between clusters we exmine none. For instnce, in figure 8 there re three clusters; the middle one contins four overlpping loser scopes. The lst cluster hs lredy been processed, nd we re processing the middle cluster (K indictes the current log record). The current cluster begins t begcluster; the first (i.e., to be processed lst) cluster in the log begins t beglsrscopes. We cn now outline the lgorithm for the bckwrd pss of ARIES/RH. 13 Within loser cluster we exmine ll records, undoing loser updtes. We lso djust the current cluster by dding or deleting scopes, closing it when we rech its first record, t begcluster. The lgorithm ends when we rech the beginning of the first cluster, t beglsrscopes. We begin by computing LsrScopes, the set of ll the scopes covering loser updtes. LsrScopes contins 4- tuples: 14 the object, the invoking trnsction, nd the two LSN vlues for the rnge of updte records. We compute 12 In ARIES, ll loser updtes re those invoked by loser trnsctions, so ARIES/RH reduces to ARIES when there is no delegtion. 13 References in prentheses correspond to the lgorithm in figure The scopes of section 3.4 plus the object id.

8 beglsrscopes which mrks the beginning of the leftmost (oldest) loser scope in the log. We strt sweeping the log bckwrds (i.e., right-to-left in figure 8) from the end of the rightmost loser scope, nd end t beglsrscopes (see while loop). This sweep consists of two steps: we identify cluster nd undo ll the loser updtes in its component scopes (); nd we move to the next cluster once the current one is exhusted (). We process cluster () infour steps. First, we check whether the current record is the right end of scope, in which cse we dd the scope to the current cluster (1). Then we check if the record is loser updte, nd if so we undo it (2). A record is loser updte if it is within the ends of loser scope whose invoking trnsction is the sme s the updte s invoking trnsction. Then we check if scope ended in the record just processed, in which cse we remove it from the current cluster, becuse the scope hs lredy been treted (3). Finlly we move K (left) to the next record (4). The next cluster to process begins t the end of the now rightmost scope in LsrScopes (), becuse when we dd scope to Cluster we remove it from LsrScopes (1). The repet loop ends becuse we decrement K by t lest one on ech itertion, nd lthough () s limit begcluster my decrese, it my never go below beglsrscopes (becuse beglsrscopes is the minimum of scope begins), so eventully K reches it. The while loop ends becuse we decrement K by t lest one ech time () (nd more when we skip between clusters ()). Notice tht we visit ech log record t most once nd in monotoniclly decresing wy. This reduces the cost of bringing the log from disk. We construct the set of scopes LsrScopes once nd deplete it in the reverse order of scopes, so it cn be kept in priority queue (on hep) sorted by right end of scopes, with the lrgest vlue first. We follow invoking trnsctions to process the set of scopes Cluster; we dd scopes on the left nd delete scopes on the right. A binry tree keyed on trnsction ids is resonble implementtion. Trnsction Rollbck In the preceding we discussed how to support the more complex recovery from Crsh, which forces the bortion of mny in-progress trnsctions. Rolling bck single trnsction (borted becuse of logicl error, dedlock, etc.) is similr. As before, we must undo only the (loser) updtes for which the trnsction t is responsible t bort time. We only sketch the lgorithm here in the interest of spce. For ech object in Ob List(t), wemust ensure the updtes re undone. We construct the set of loser object scopes (see figure 9) nd we process it undoing the updtes in reverse chronologicl order. The min issue is the mnipultion of the log in the buffer, which must be done crefully to preserve consistency in the fce of filures. We dopt strtegy See sections 3.4 nd nd figure 8 for explntions of the vribles used in this lgorithm. LsrScopes fob, scope j9ob 9t 2 Losers : ll loser scope 2 Ob List(t)[ob]:Scopesg scopes if LsrScopes 6= then beglsrscopes min {left j (,, left, ) 2 LsrScopes } strt of erliest scope K mx {right j (,,, right) 2 LsrScopes } end of ltest scope Cluster ; begcluster K while beglsrscopes K K sweeps bckwrds to left end of erliest loser scope () repet identify & process overlp g scopes cluster (1) dd to Cluster the loser scope tht ends in K if 9 (,, left, K) 2 LsrScopes then Cluster Cluster [ {(,, left, K)} put in Cluster LsrScopes LsrScopes ; {(,, left, K)} begcluster nd remove from LsrScopes min (left, begcluster) updting where cluster strts (2) undo if it is loser updte if LOG[K] = updt[t ob] nd 9 (ob, t,, ) 2 Cluster then undo(updt[t ob]) CLR.PrevLSN LOG[K].PrevLSN (3) discrd scope tht begins t new record LOG[K] if 9 (,, left, ) 2 Cluster nd K = left then lredy processed, so discrd Cluster Cluster ; {(,, left, )} (4) processed record LOG[K], next (left) K K ;1 (end ) until K < begcluster finished this cluster (sweep bckwrds) () find next cluster of scopes K mx {right j (,,, right) 2 LsrScopes} RecoveryComplete Figure 9. Bckwrd pss of ARIES/RH similr to tht of ARIES/NT [18], writing CLRs s we undo the updtes. 4 ARIES/RH is efficient ARIES/RH, presented in sections 3.5 nd 3.6, is correct nd efficient. To ensure correctness in recovery protocol, we must gurntee tht, fter recovery, ll updtes by loser trnsctions hve been rolled bck completely (their effects obliterted) nd ll updtes by winner trnsctions hve been committed (their effects mde permnent). Conventionl ARIES complies by using the UNDO/REDO protocol. With delegtion, we must lso ensure tht opertions ultimtely delegted to loser trnsctions will be borted, nd opertions ultimtely delegted to winner trnsctions will be committed. For lck of spce we omit the proof here, which cn be found in our technicl report [15].

9 The rest of this section rgues tht ARIES/RH is efficient. No delegtion: negligible overhed. With the optimiztion outlined in the note in 3.5, in the bsence of delegtion ARIES/RH reduces to the originl lgorithm plus test: t updtes, checking whether there is n entry for the object in the Ob List. Thus the penlty when the delegtion functionlity is not used is negligible. Norml processing: low overhed. Posting one delegtion during norml processing hs the cost of dding log entry nd updting the object bindings. The cost of delegtions is liner in the number of opertions delegted. For instnce, the updting of Object Lists for delegtion is liner in the length of the Ob Lists. Recovery: low overhed. The costs of the recovery psses re similr to those of conventionl ARIES; ARIES/RH does not dd ny extr psses. For ll opertions, supporting delegtion only entils costs t most liner in the number of delegted opertions (see previous item). Also, recovery costs re dominted by disk log ccesses, which ARIES/RH does s efficiently s ARIES. For instnce, on the bckwrd pss, log records re visited t most once nd in strict decresing order, s in ARIES, llowing for the usul optimiztions. The first two points follow from the fct tht ARIES/RH only dds some fields to dt structures tht re similr to those used by the conventionl lgorithm. When there is no delegtion, these extr fields re not used. Delegting dds the constnt time of logging the delegtion opertion nd updting the Ob Lists of the delegtor nd delegtee trnsctions by moving s mny scopes s objects re delegted (hence the linerity), ffecting Ob Lists, which reside in min memory nd cn be orgnized for efficient lookup/updte. (At trnsction termintion the Ob List cn be simply discrded.) As for recovery, ARIES/RH s forwrd pss incurs the sme overhed s ARIES does to reconstruct trnsctionl dt structures nd redo updtes. No specil sweep of the log is required becuse ARIES/RH does the sme ccesses s ARIES. Specificlly, the forwrd pss of recovery is only different from tht of ARIES in its processing of updte (there is n extr check for ob 2 Ob List(t)) nd delegte (sme check nd the move from one Ob List to the other). Thus, ARIES/RH dds neither extr log sweeps, nor costs proportionl to the length of the log, s it uses the sme sweeps of the log s ARIES to reconstruct the delegtion informtion. We expect the Ob List to be much smller thn the log being nlyzed, nd to wholly reside in min memory, especilly becuse it only hs objects tht re delegted. Thus the cost of ccessing Ob List is smll compred to bringing the log from stble storge, the dominnt cost during recovery. The bckwrd pss of recovery reds the log in much the sme wy s ARIES, by continully tking the mximum Log Sequence Number tht must be undone (in ARIES) or the scope clusters within which updtes must be undone (in ARIES/RH). In ARIES/RH we exmine log records in clusters formed by loser scopes, but, s in ARIES, we do it in monotoniclly decresing wy. To compre with ARIES, we need only exmine the costs for processing updte records (the other cost in ARIES). For ech updte, we do lookup in Cluster for check of delegtion scope (to decide whether to undo it), nd possibly write Compenstion Log Record. Otherwise, we just dd or remove scopes from the Cluster nd the LsrScopes sets. In summry, ARIES/RH dds only miniml overhed to ARIES to support delegtion. 5 Relted Work Previous work hs produced mny Advnced Trnsction Models (ATMs), but ech hs its own tilor-mde implementtion. For instnce, both Argus [12] nd Cmelot [19] ech supports its ATM (vrints of nested trnsctions). Split- Trnsctions [16] llows the commitment of prtil results but in wy tht is less generl thn delegtion (see section 2.2). Thus, lthough efficient, these systems re limited in the models they cn synthesize. Delegtion, by llowing chnges in the visibility nd recovery properties of trnsctions, is powerful primitive for synthesizing ATMs. Our work builds on the forml foundtion provided by ACTA [6, 5], nd the primitives introduced in ASSET [3]. With delegtion (nd the other two ASSET primitives, permit nd form-dependency [3]) we believe we cn offer the flexibility to synthesize wide rnge of ATMs. Given the efficient implementtion of delegtion presented in this pper, we believe we cn chieve this flexibility t performnce comprble to tht of tilor-mde implementtions. Our reserch lso builds on the substntil work in ARIES [13], in prticulr ARIES/NT [18], n extension of ARIES tht supports nested trnsctions [14]. Rewriting history is nturl extension of the repeting history prdigm of ARIES, nd it hs served s powerful bstrction to guide our efforts. More specificlly, in order to support the rewriting of history, we extended the ide of chining bck log records introduced in ARIES to smller grnulrity: the sub-chin of the log pertining to prticulr set of object updtes. ARIES/NT extends the bckwrd chin to tree (reflecting the nested trnsction structure). Our method is more generl: by keeping informtion bout which trnsction is responsible for individul updtes, we cn support not just Nested Trnsctions, but mny ATMs, such s Split Trnsctions, Co-Trnsctions, nd Reporting Trnsctions. Thus our extension of ARIES, while including it, goes beyond the

10 functionlity provided in ARIES/NT, nd llows the efficient synthesis of rbitrry ATMs, not just nested trnsctions. Work relted to ours includes the Trnsction Specifiction nd Mngement Environment (TSME, [9]), in which specifictions re mpped to certin configurtions of prebuilt components, so it pproches the problem t corser grin. This my llow for initil gins in performnce, but we believe tht the use of lnguge primitives is richer nd more flexible pproch. Brg nd Pu [1] explore nother modulr pproch, bsed on metobject protocols [11], nd incorporte some elements of the TSME pproch nd some of our lnguge-bsed pproch. Also relted is the Con- Trct model [20], where set of steps define individul trnsctions; script is provided to control the execution of these trnsctions. But ConTrct scripts introduce their own control flow syntx, while ASSET introduces smll set of trnsction mngement primitives tht cn be embedded in host lnguge. 6 Conclusions The min contribution of this pper is the concept of rewriting history (RH), designed to chieve the semntics of delegtion in n efficient nd robust mnner. We believe tht this work forms crucil step towrds the flexible synthesis of ATMs: By csting delegtion in terms of rewriting history, we were ble to express the issues of delegtion in terms menble to the specifiction of recovery lgorithm. We showed how to chieve RH in the context of prcticl system (ARIES) nd we hve lso discussed elsewhere [15] how to pply it to nother (EOS), suggesting the prcticl implementbility of delegtion. As indicted in section 4, the cost of delegtion in ARIES/RH is very low, nd its support incurs no cost t ll when delegtion is not used. We hve lso demonstrted (elsewhere, [15]) the correctness of our implementtion, showing tht it stisfies the desired trnsction properties in the presence of delegtion. We re exploring the issues of delegting components of complex objects. We will continue investigting the broder issues of providing robust, efficient, nd flexible trnsction processing. In prticulr, we re interested in mking recovery first-clss concept within trnsction mngement nd in providing vriety of recovery primitives to trnsction progrmmer so tht different recovery requirements nd recovery semntics cn be chieved flexibly. References [1] R. S. Brg nd C. Pu. A prcticl nd modulr implementtion of extended trnsction models. In Proc. of the 21st Int l Conf. on Very Lrge Dt Bses,Zürich, Sept [2] P. A. Bernstein, V. Hdzilcos, nd N. Goodmn. Concurrency Control nd Recovery in Dtbse Systems. Addison- Wesley, Reding, Mss., [3] A. Biliris, S. Dr, N. Gehni, H. V. Jgdish, nd K. Rmmrithm. ASSET: A system for supporting extended trnsctions. In Proc. of the ACM SIGMOD Int l Conf. on Mngement of Dt, Minnepolis, Minn., June [4] A. Biliris nd E. Pngos. EOS User s Guide. AT&T Bell Lbs, My [5] P. K. Chrysnthis nd K. Rmmrithm. Delegtion in ACTA s mens to control shring in extended trnsctions. IEEE Dt Eng. Bull., 16(2):16 19, June [6] P. K. Chrysntis nd K. Rmmrithm. Synthesis of extended trnsction models using ACTA. ACM Trns. on Dtbse Systems, Sept [7] A. K. Elmgrmid, editor. Dtbse Trnsction Models for Advnced Applictions. Morgn Kufmnn, Sn Mteo, Clif., [8] N. Gehni, K. Rmmrithm, nd O. Shmueli. Accessing extr dtbse informtion: Concurrency control nd correctness. Technicl Report , University of Msschusetts, Amherst, Mss., [9] D. Georgkopoulos, M. Hornick, P. Krychnik, nd F. Mnol. Specifiction nd mngement of extended trnsctions in progrmmble trnsction environment. In Proc. IEEE Int l Conf. on Dt Eng., pge 462, Houston, Tex., Feb [10] J. Gry nd A. Reuter. Trnsction Processing: Concepts nd Techniques. Morgn Kufmnn, Sn Mteo, Clif., [11] G. Kiczles, J. des Rivières, nd D. G. Bobrow. The Art of the Metobject Protocol. MIT Press, Cmbridge, Mss., [12] B. Liskov nd R. W. Scheifler. The Argus Lnguge nd System. In Lecture Notes on Computer Science Springer Verlg, volume 190, Berlin, [13] C. Mohn, D. Hderle, B. Lindsy, H. Pirhesh, nd P. Schwrz. ARIES: A trnsction recovery method supporting fine-grnulrity locking nd prtil rollbcks using write-hed logging. ACM Trns. on Dtbse Systems, 17(1):94 162, Mr [14] J. E. B. Moss. Nested Trnsctions: An pprochto relible distributed computing. PhD thesis, Msschusetts Institute of Technology, Cmbridge, Mss., Apr [15] C. Pedregl Mrtin nd K. Rmmrithm. Delegtion: Efficiently rewriting history. Technicl Report , University of Msschusetts, Amherst, Mss., Dec [16] C. Pu, G. Kiser, nd N. Hutchinson. Split-trnsctions for open-endedctivities. In Proc. of the 14th Int l Conf. on Very Lrge Dt Bses, pges 26 37, Los Angeles, Clif., Sept [17] Krithi Rmmrithm nd Pnos K. Chrysnthis Advnces in Concurrency Control nd Trnsction Processing. IEEE Computer Society Press, Los Almitos, Clif., [18] K. Rothermel nd C. Mohn. ARIES/NT: A recovery method bsed on write-hed logging for nested trnsctions. In Proc. of the 15th Int l Conf. on Very Lrge Dt Bses, Amsterdm, Aug [19] A. Z. Spector, R. Pusch, nd G. Bruell. Cmelot: A flexible, distributed trnsction processing system. In Proc. of Compcon, Feb [20] H. Wächter nd A. Reuter. The ConTrct Model. InElm- grmid [7], 1991.