Chapter 24: Advanced Transaction Processing

صفحه 1:
+ 052 اه( رد۱۱ ۲ عسطالطوط) امه م6 موه وتا ۲ اد رس من( و ‎Opsiews‏ هل و شمه ‎bon Ouwdica‏ © § Preewivr woe wed io ‏وود لش‎ سا0 لح 0 لا سواه 1 دوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 2:
+ Traweior Provessiay Quars DP oositers taitdly developed os wulitreded servers to support barge ‏ای‎ ‎FP terwtecds Pro o sine process. اما اوه لیلج را و مسا ‎Provide‏ ‎servers.‏ ول لجی اه چاه ای ها و اب وشوو ‎Processkny‏ © Prove serves suk ws? © Cresectaticg Povities to skopiPy creatay user ttierPaces: © Perstedt quevig oP choot requests vad server respowes © Routoy of cleo wessuges iy servers © Coordention oP twe-phuse count whe irneurioay uvess wutigle servers. 8 3 cd TP .: 01008 ‏ممصا‎ WO, Pathway Pr Pode, Dop Gad Pro DOR, od Coctoa Pow Presare سا0 لح 0 لا سواه 1 هوه ‎Od.‏ ,تن 6 تیه 

صفحه 3:
remote 5 remote server files clients clients (a) Process-per-client model (b) Single-process model Sass router servers files remote routers servers files clients (c) Many-server, single-router model (d) Many-server, many-router model 0 سا0 لح 0 لا سا6 1 هوه ‎Od.‏ ,تن سس 6 تیه 

صفحه 4:
+ TO Ovator Orokievtures (Ovd.) ۲ (Proves per cleat wodel - nsteud oF todvicudl loge sesziva per ‏,ممه‎ ‎Server process Do nindes wits the tected, ‏اجه ,له اج‎ ‏ارت مود‎ ۶ ‏نو تس‎ ore kids © Dubtashiag: bigs CPO ‏ساملس‎ swichtay between 1# Giente process wodel = ol rewote terwicak ‏وه و و اوه‎ server proves. © Osed ta chewtserver ewironvedis © Gener provess is unit edad; low cost Por teead suichiery اوه مها شم ‎Ov‏ © © Dot suited Por pordlel or ‏سل سا‎ سا0 لح 0 لا سواه 1 هوه ‎Od.‏ ,تن 6 تیه 

صفحه 5:
+ DP Ovubr Orokieviwres (Ovu.) © ‏ول - او مات مروت(‎ upphrdion server processes ‏اوه سا جات ی واه سل مرو و وه‎ ‏جوا‎ o sige ooumicaiza process thot routes requests. © ‏موی‎ server provesses Por wuts upphrctires © DOuhikrend server process: © Rosco pordlel or detrbuted ‏ول‎ © Oxy server woorrouier wodel = wulipke processes coacruaizate wits whet. © Cleo com nicdicn processes inieradt wih rier provesses that rate their requests to the appropriate server. ‎stots up vad supervises vier provesses.‏ سس مسیون و ‏سا0 لح 0 لا سواه 1 هوه ‎Od.‏ ,تن 6 تیه 

صفحه 6:
input queue ee authorization 1 lock manager 5 recovery manager application servers: log manager database and ‎resource managers‏ }| تک ‎ ‎ ‎ ‎output queue ‎ ‎network ‎ ‎ ‏سا0 لح 0 لا سواه 1 هوه ‎@eedrwr Gyetre Oocowytr, Oe.‏ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 7:
: a Qotded Orwiwe oP a TP Ovuior سس ی وا یی و ۲ ‏موی سجني یت‎ provide persisicat or durcble weseoye queue pontedts oP queue are sue eved P systecws Puke. B Ourbe quevetay of ‏اس سا موه موی‎ © oppiouion server umiies wessuce to durable queve os port oP a et © ower the tracsuntiog cows, the MP weaior quarndiers wessuye i eueuindly delevered, reqardess of praskes. © ۵010 propertes ure thus provided eve Por wessues seul uiside the ‏ول‎ ۲ Dey DP woators provide leche, logging, ond recovery services, 0 ‏اه‎ ‏نا موه موه‎ Koplewect (OTD properties by ‏را‎ ‎Od. 20 ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 8:
+ Q@pphoutra Ovvrdintiva Ostay TP Ovaiors ۲ ۵ ۵ ‏ی‎ reds cack subspstew us 0 resource wager thot provides: trocsunivodl access to svwe set oP resvurces. BD he tterPace between he DP woctor ond the resource warner & defied by fet Berne pera Bh Dhe resource wrenner tierce & dePiced by he X/Open Ditbued ‏اه متا مس‎ ۱ ۱ ‏لهس له ملس موس و مور وود وت‎ )6۱60( ‏موس‎ to herr service ۶ Drxeartond RPC proves vale to pucker a seres of ROC cole ‏محا‎ a یو ۶ ‏لح(‎ perPorwed by aa RPO ore canied ‏خن ورس ها طلست نی‎ the ‏سا لاو سا موی له رما‎ P there te ‏اه( بو‎ سا0 لح 0 لا سواه 1 هوه ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 9:


صفحه 10:
VTraswiodd OorlPows © OorPows oe ‏نما وت‎ evolve the coerced exertion oP anh: tester perPorwed by dPPercat provesstay eutiies. ۲ the growth of cetworhs, ood the existeue oP ‏حول موه ول‎ syste, workPlows provide ‏وی اه پوت موه و‎ ul eke that tavolve walliple systews. © Groope oP a workPow delivery of oo ewal wessuye, which yes throughs severd wus syetews to ‏او ام‎ © Gack woler perPorws ‏تاه و‎ Porwordiy of the woll ty the ced woller. © acter rant delver wal, Poke wast be handed search (delvery ۳ weve). ۲ ‏رای و(‎ evolve huevos! ey. loon provessteny, or purchase order Provessiny. سا0 لح 0 لا سواه 1 مدمه ‎Od.‏ ,تن 6 تیه 

صفحه 11:
Grawples oP OorkPows Workflow Typical Typical processing application task entity electronic-mail routing | electronic-mail message | mailers humans, loan processing form processing application software humans, application purchase-order processing | form processing software, DBMSs سا0 لح 0 لا سواه 1 موه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 12:
loan application © tote post, worhPows were horded by ‏روط( اجه بو‎ © Cowputerzed workHows ice tp cuiccwote wooy oF the tasks. (But he buco stl play role ex. fer opprovicry kore. سا0 لح 0 لا سواه 1 هده ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 13:
Traswirrd! OorlPows ۲ Qhet ukhess Poly boues tp oowpuierize ‏سامت و‎ © GpecPicaivn oP workRbwe - detahey the tasks thot wast be carted mut ced ‏موه | را‎ requireweus. ۱ aby provider ‏سا له‎ soPequards retited ty the correvivess oP © oy: Loos uppicdica should ot vet lost even P systeu Pek. © @xtedd recsurion couvepts te the ‏.وسنص مت اه جومت‎ Bl Gre oF 0 workPow - cows of the ookeriva of skies of tr oocettvect kesh, ond hor oites (he. udkes) oF ol varcbles ta the executions pho. سا0 لح 0 لا سواه 1 وده ‎Od.‏ ,تن 6 تیه 

صفحه 14:
QOorlkPow GpevPodiva 4 © Gtaic Spenco oP task ‏تس‎ © Dashes vod depeudeuries ucopay thew ore dePioed bePore the exerutice oP the workAlous starts. © Occ establish precoutioas Por exevuizg oP pack tock! sks are exevued voy whe their prevowdiizgs are suttePed. © DePoed prevoudicas trough ‏مس‎ ‎* Gxenuica states oF otter tasks. “rah pean tart veal Ribs yum excel” ۱0 oP other tasks. ‎start P tosh jreturas o vole yreuter thar OS”‏ تا ‎* Cxterad vartubles, thot are wodPied by extercad eves. ‎“rake punt be vtred wihia OP houry ‏جاسم خا مرت تا ان‎ ‎Od.‏ ,تن 6 تیه 

صفحه 15:
+ QorkPow OpsvPraioa (Ovd.) © Oywowt tek coordnatoa (E.4. Cleciroue wal routes syetec ‏و‎ uhick the tex to be schedule Por o gives ww were depeuds 70 the destoaiod address ‏نات مج ای‎ renters ore سا0 لح 0 لا سواه 1 وده ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 16:
سم صده مه ماس وا عونا یرجه ما و افو مت ‎BO 0C10‏ اوه تاو كلا ولمم ترا سوه اوه اس وا روا ‎B‏ ‏اه اس و جا اها امم سا موم و وم ۲ ‏تاه مشحت تهج مه بویت‎ a workAous wil ‏و‎ for ‏جح جما بط ماو افو واه( سا موه اعد و‎ ۶ ‏لاه مسا عم نطو هه ماه - لمموین‎ ۱ state io whick « uorkPlow kes Pulled to ahieve ts vbevives. © workhow west reach oo ‏اماد ما وه‎ eve tothe presewe ‏له و و و‎ سا0 لح 0 لا سواه 1 موم ‎Od.‏ ,تن 6 تیه 

صفحه 17:
‎oP OorlPows‏ مطلیی<) ‎ ‏تعاس سوه یطوط ‎B® ‏عون وله با توت ور و‎ tasks Poe ‏عاص هد جا لماج ولج مه لجه ره صحو روا حور‎ depeutewies ‎BO Pxsh oyecis - coin the executive oP o tosh by ‏رات بت و‎ ‎© Qeckeaisw 7 query to state of the workPow sysiew. ‎Od. eon? ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

صفحه 18:
مس جس ی ی ی ی + وه رای أن ۳ یو سا له ری و و لاه ۱ و ول ام و و اوه ول سا ارت مرو توت و ای ۶ سوه هن ده سا اه ما ما نا وه ۶ سوت ی و دنه ( و اه سو) عن ‏ - اد راو ۲ Pip detribuied - kas on svkeduer, bul the tek oqeuis ovordioaie their exevuiza by ‏رصم مور‎ wits Pak viker io suiePy tock depeudeuries ocd pier workPow EET require EUs. © eed ‏و‎ skoplest worhPbw exevution systeus © based vo elevirvdic wail سا0 لح 0 لا سواه 1 وده ‎Od.‏ ,تن 6 تیه 

صفحه 19:
QOorlkPlow Goleeduler ۲ Wledly scheduler should exevuie o WworkPw coy oPier easuricy thot it wil lenin ‏اه ارات و و‎ یط ۳ سای ام اه مد اه یی امس هت( ۱ ‎of the subtracsuniiows shoukt‏ لت ی نا اه فا سا افو موه موی سا © Cuppore sysiews exerninny G, rd Ga de ot provide preparteoowt ‏مس موه ماه وق بو من سب‎ © Vie then possible to reach a ste where ‏اه امه ها لهس‎ the other uberted. (Bots cadant thea be brought to the score state. ار سا لاله له ری جا متام روط © ۲ ‏اه مب(‎ sche by the scheduler te oot possible to yecrrdl, ood ty usury fet to the desiqaer of the workPiow. سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 20:
+ Qevovery oP a OorkPlow سوت با اه رو ‎ooours fa‏ اه ‎Goswe thot is o‏ ۲ ماما ریت ‎oo‏ مور مه توت با موی 355 © Cohie-recwvery rouioes ‏جمساجوموثما جمد جما جمصاوجت صا لججد‎ oF the ‏سا هلر‎ tive of ‏ماج سا ماه و ما او‎ states oP rack ‏جات ساره منطو اه عدبا .كاعم‎ Bondo? of ‏ی تراسج له عون وا ی‎ it spite of ‏ما‎ ۲ ‏من ما رم( اد‎ recovery way lead to duplicate exeruiod ‏یو با لها رو ال بو تلم ام‎ oot beter exerted. © Coho: Persistent wessuieny sys سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 21:
4 Qevovery oP a DorkPlow (Ova.) ersten ‏ویو او و اوه و و میسن‎ queur ond therePore ont lost fe case oP Pohure. © Deserted ts etal is Ohopter (9 (Deirbuted Durbar) © eh oo aed cows, tutes to he persisted wessuye queue whoever ‏مج‎ werd ty be seo mut. ۲ Vhe persistent wees sysiew west wohe sure he wessuges yet delvered eurcidly Pood gov P the trocesurion cous. BV he weseup systew verds i reseod u wessue wheo the site recovers, Pie wes oot hana ty have ‏و وا لا‎ © Qessuges wet be bogged int stable storage of the reveiviey eu to detect oli ‏مج و تن رتور‎ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 22:


صفحه 23:
مسر از و سوه وا مور له وله تا ۲ توصممم او نا یاه وا لنچ و لح محر جوا © Ok VO ‏ود 1 اساسا و ی‎ (10 wilisevoeds) bos oo deoreused oto rote powpordble ty the toorewse tt processor sperds. © Corde ‏لو وا امه رون مب‎ or uric the Sucve data tea, resultcn to dota cooPticts thot reduce ePPerive porcietsa: B® Oe coo reduce the deuree to whick o dotdbose syste is dist bowed by ‏صما‎ the size oP the database buPPer. سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 24:
Oucr-Dewory Ounbwe © Cowwernnd OF bt systews coo support wold wewories oP teas oP ‏تسام‎ اس اه رح ‎data dlows Paster‏ لو رس( ۲ تسا سا ۲ 8 ‏مایت مالسا ها بمپم‌ورا‎ irasurtion rate is hich. ۰ 0 ‏جطله صذ و موی‎ of nlp ‏اجه لا( سوه‎ to ‏سويد‎ chard) © AB tke update rote Por woodPied buPPer blocks is hicfs, the dist cate ‏تام‎ rote coud becowe o botleoect. ۶ ۳ the systew oreshes, ol oP wats wewory ‏.لوصا جا‎ سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 25:
QavrODewory Ounbwe Opicwtzdiow Do reduce space overheads, wokrwewory dotubuses cod usr stiruckires wih potters crvssiay wuligie pages. la disk databases, the VO vst to ‏جوا‎ walliple pages would be excessively high. Oo weed ty pic buPPer pages te wewory before data are uovessed, sie baPPer pages wil over be repkiced. ‎quen-processioy techaiques to wtikeize spare overhead - avoid‏ موه( ماه بو رد او ‎exceed soto wewory‏ ‎hope ecaicg oP pperdiccs suck os locktes cod hatches, 507 they:‏ سوم ‎do ot bevowe botlewerks.‏ ‎Opteize recovery dkpriheos, store paves rarely oped ty be writes out i swoke space Por vier pos. ‏سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 26:
Grow Ovwwi Bleu! desteud oF perPorwiey culgut oP lrg records to stuble siorage us suv oS inxeunivg & ready to cori, uci cl © oy baer block ip Pull, or © tremeartod hor bra wii subsea bro Pier bey recy to ocr له رو له ‎Resuls it Fewer ouipul operates per‏ ا ‎porrespoedady ot higher throughput.‏ تس اه مت ‎AWoawever, coi ore delayed vail a suPPiciealy harye‏ 198 رای وا مج مها مت ما وا ما و او وا رل و ‎ieorewed respoure thre.‏ ۲ ‏با‎ dehy uveptible to hith-perPorwoare trnsuriva systews store oy buPPer blocks vill Pilup quickly. سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 27:
حمل عامجا ناويد ی ما اس مه * امد هن مشاه سا اجه وحطصمی لت لاو ‎P task i ut‏ سوه رو لام صصه۵ - عمط ‎Ward‏ © د امد © Creo ‏عمط‎ - The tush hus zero value Pit cowpleted oPier ‏الیل سا‎ ۶ ‏ی‎ deudiee ~ The tosh hos dhevinishtog value Pits coepleted Pier the deudtoe. BD he wide votoore oP ‏با موم‎ Por read ood write ‏من سوه‎ dishes ‏ام مت شم | وروی‎ Por ieoe-coustraced syste ۱ © Dats Por lochs, trexnsurivd uberis, ovdieuicg Por resvurces rewurr us probews eve P dota is in waka wer 19 Qestqs of a rechioe spstew ‏نمی امه‎ thot puruyh provesskny power exists 7 sweet deudkoe wikout requiden) excessive hardware resvurves. @eedrwr Gyetre Oocowytr, Oe. 00.0? ©Sbervehnts, Cork ced Cnakershe 

صفحه 28:
جهاصوصهت ۳" مسق( ‎boa‏ 4 ‎techotques deat words‏ امه وی لو ‎wel wheo user toterantion te required:‏ ‎Loog duection! Design edt sesso ore very kn Cxpoewe oP eoowtied cts! (B.<., part urckte to a deskar ‏سس‎ supper portal rolbacts ‎crash state shod be restored eved Por pettorbe‏ من ترطف سوه ‎rented dota, so user work ts ot bot. ۲ PerPorwaws: Post respousr tive is essed so wer fee is ot ‎20.00 ‏اور ‎|۱۳ Gyetre Oocowytr, Oe. 

صفحه 29:
‎Traswirw‏ یپ مور ‎ero‏ لت وب ویو ‎dexnie dacbose operdioas (readiurte) of a lowest level.‏ © ‎BAB ianexnton Babs, ood) anive short-huratog trexeurtoces cbr.‏ ‏سمل تسه ‎cay‏ وه مور وت ما سم ۲ ‎hove recovered.‏ ‎© Ve ef hited worngewed of Irop-durdicg wats, ood the posstiliy oP aborts. ‎© Deed theruives ty wots wed uberis; hercaive techoiques wet eure 00 ‏,اوه شوه الجكلانب ججعوامج‎ ‎ ‏سا0 لح 0 لا سواه 1 مومه ‎Gyetre Oocowytr, Oe.‏ 00 

صفحه 30:
Cowwrewy Opdrol © ‏,اوه مات ون‎ ۱ depeuds on the sper Pir coeistewy coesirais Por the ‏وال‎ ‎© Conetiess depeuds va he properties oP opersiizas perPorwed by: puck ‏او‎ © Ose dotcbose cowsisteuy coustraicis us te spit he dtabase fair ‏ها موه رو موجه مات من ماهلا‎ wocaged sepordicl. © Pred ‏لا و و‎ reud od write os Puadoeectdl low-level ‏ترجه تمه لو هون‎ ovoid ty del wis thew. سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 31:
read(B) B:=B-10 write(B) read(A) A:=A+10 write(A) ©Sbervehnts, Cork ced Cnakershe read(A) ۸ :< ۸ - 0 write(A) read(B) B:=B+50 write (B) ممه 00 Gyetre Oocowytr, Oe. 

صفحه 32:
+ QOesed ond Duilevel Prawn © OO vested ‏مج ابرطلی ب‎ Tip represecied by o set P= {by boy oy 1) OP ‏سای‎ ood a port order Poa ۰ BO sbreneuios fi Poy obort without Porctay To bon. Desert eras eer vee ety ‏ال سك‎ 0 2 ۳ ‏مس با | سس له بو ما مه بط‎ ot ‏امه( ۰ و با ,مه( و0‎ ay ol cbort (or rece ‏(مسو‎ ۵ ۱ ‏سم بط و بو‎ raph, hea fj eaet ot be ia he trowive oboe PE. سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 33:
+ Qevied aad Dullevel Trawastow (Ova) © Gibesunives con thewerbes be cested/ultlevel troasuriion. © bowest level oP cestie: stredacd read oad write ppercivas. © este coo oredr higher-level pperuicas thot way eohoue powurrewy. BD pee oF vested ‏تمس اسان‎ © Ouhbvel rxeuston! subexeniva oP Ps perwited i releuse bohs va risa, © Gags: walievel lbocpduraion tnneavia. © Dested ‏لاه مامتا میت‎ by u subinneuios | oP Pane ‏رخات ماو مه با موجه راو‎ سا0 لح 0 لا سواه 1 مومه ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 34:
و و مج + 0 ‏ویو و و بو‎ «۰ 1 ‏سس‎ of ۱ 1 ‏له ات‎ SO Prow @ ١ ‏ات رن‎ ake SO ‏و‎ 0 ۱ ‏مر لو مه مر مس را‎ perPore ‏سیم و و سور‎ © Py cows oF thick subirare: (D Brow @ wwhick ackts 40 ‏و‎ © Op orderkn & sper Ped oa abinne aris) coy ExeTiod ‏د سس‎ ‏سوه‎ rem. Posy ۰ ‘v0 سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 35:
صدصامه هده !1 بده 5م000 + ام ماس جات ال سس را من ول وا رما ۱ لاه لصو ۱ ۲ ‏علانب ,قاطا موم ماه ین‎ ‏,رم سا لت ان 1 موه‎ 7... whick reserves rectd cars, ond 7), whick ‏اه رم‎ © Note maces he resent. © ‏ححص‎ oF edo ol oP, the Paine of ‏او وا‎ by diesen he od hotel reservation ood smokin 0 ew oa. © Roques er of euro of the Poked traearton. سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 36:
حصحها؟ نموم + ۲ ‏مرو فصو و ما لا و‎ crashes, we ant boy wot oly ‏راد با وا وم‎ but doe ‏و و مد موه امس و اه‎ ‏یر‎ ۱ ای ‎bok of ond ce‏ سوه وا یط روط Ber ‏دسجي‎ 7 rechten he overhead of eerie he recovercbliy of kare comin! © Opercticn loci. Ouly the operaiva perPorwed oo the date teu oad the cata few weve ore sipred ia the log. © Locngen) ord shadow pages. Ose baggy Prow sul dota ews; use shadows pasta Por forge dota tec. Ouly wodPied pages ord to be stored ta duplicate. مومه ‎Od.‏ ,تن 6 تیه 

صفحه 37:
Trawwiod Qacanewedt ta Dulidacbuse Opsews © Trosuios woongewed is cowphoded ft wulidctabase systews berause of the ‏وه که موجه‎ © Cbd CCL ‏دهع اما امد‎ 000 (bche or reewed ot he pend); lochs set oe a result of a ‏موم ام‎ ore released may whe tt emer ratte tere ‏سوه لا مه‎ هط لمج سوت موی باه رو وله باس © ‎corres) voir sche‏ وین ‎CPL‏ اوه سا ول هم سس ۵ ‎any‏ جد و ‎١‏ تست ۲ عه ,اجه مسج اه ‎prod very bow level‏ © رو مها ‎ee‏ © @eedrwr Gyetre Oocowytr, Oe. 000? 

صفحه 38:
مسر دوه () رو زور جر ]7 ۱ ‏اوه را‎ ore executed by ack lord OBOG, vuside oF he DOGG ‏اه مود‎ © lbbd ‏موی‎ ore exevuied under wultdutazase orci, وحم طايه و امس وی ‎Loed nicwwy - bod OBOGs cerca‏ © ‎over boot‏ ای و الم سا اجه شوه مها مان 9 سوه 000)(62) ما عمجت و اولح سوه او روج من سا ‎ts sertatzable‏ © raver oF bookie, DOO cnet be uble to quard ‏سح سا سنوی‎ © eed uddiiogd werhuniows to eusure qobd seridtzabhiy: سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 39:
ات۵ ۷) امولمی؟ ۲ 00۵0 ‏لوا سا پوت اوه اما عصصی‎ rocsurtivas, tactuday those thot re pat oF ‏سس ال و‎ © Uke ‏ی رتاو ی ان‎ yobal trocsurioas ‏نس واه‎ the ordertogs tacuced by lord tracructives. 18 ‏را‎ dees wt eer dobdl serichzobiliy, however, fico PUP require wenis Por strvay correvtiess. 0. reserve cousisteuny us speed by a yued set oP ‏موی‎ ‎©. Guonnier thot the set oP dota ews read by euck tracsunivg is ooasisteot © @bbdhredd proboot : Glbdl ‏سوه‎ coo read, but ot update, focal dott tecs; local ‏مس‎ do ont have ‏مه و و( ول ماو ما میت‎ ‏لت اما مورا وه رون‎ otal dota teas. سا0 لح 0 لا سواه 1 مومه ‎Od.‏ ,تن 6 تیه 

صفحه 40:
+ Two-level Owridirdbliy (Oo) © Locotredd proteont : boo trrasunious have read uovess to ‏سا رل لام‎ dh coves to loool data by ‏علطم‎ 19 0 trowsuntiva hos 0 voke depeudeury iP the value thot varies too dot tec ot woe site depeads ‏لو زا سا و من‎ Por a date tec ‏عاك اه مس‎ © Por sony correchess: (Do rresuniiva way hove 0 vole ‏بط حول‎ © @bbdhreudrtelbrdedd proton); Lord trowsuntives hove read ures tr ‏ای لا وی موه الما رل ماما‎ arte: ol data; .عمجا دل أجامل اجه اما متا موی موی( ۲ ‎hove vole depeudteuy.‏ ۱ سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 41:
راب6 طط) © vec Pw ‏مه‎ & woloble oowerciag he structure oP the various nue oid schewes, 0 very resiricive protocol trot eurures vertaizubhiy te ovalobe. ‎aie‏ اجه مه مس ‎obo‏ رما سس ای ‏موه ۲ ‎3321 ‎1 95 ‏صلب لطس‎ )17, 08 ( exces PTs wae ot vie G,, ‏سوه ای مد جدمممت جاورسن_ و صصص خا لجسف جه جا با طلعصاد جد ادحاطا) ‎00 6 ‏,تن‎ Od. 

صفحه 42:
راب6 ت09 پوت + Be Bork ote ©, hos o spent chia few, ole thet ۱ ‏و هم سم زوس‎ G, wrtes 7 te tobet ot ote G, © Gxsurs yobd trowsuctives ore sertdized of puck site, reqardess oF fovdl ‏مج‎ coil wethod, sv loop os the wethod ‏له اما هی‎ ۲ ‏من منم لا‎ decides serial orderieg oP yobd tracsuctions by ‏اب وا لس بآم هی‎ tickets ore accessed 18 4 Wowever, cbove proiocol results to bw corey betweed soba ‏سور‎ |۱۳ Gyetre Oocowytr, Oe. 00.40 ©Sbervehnts, Cork ced Cnakershe 

صفحه 43:
: 8 Gad oP Okaper 

صفحه 44:
+ Ovck bevels ‏رون‎ © Ose dernive wives oP coceisteary thot dy oo ‏وا اوه عمج‎ perfor. ۲ ‏ریپ‎ mrettewy woids vesrutoy oborts wihoul vevessuny ecurtery ‏رابود‎ ۱ bochie, G-bohks woy be releused of coy tee, ood hohe swe be aquired of cop ioe. له سوه یه ‎vier‏ مسا سا ی لا سا بل © سا0 لح 0 لا سواه 1 مومو ‎Gyetre Oocowytr, Oe.‏ ۱۳| 

صفحه 45:
+ ‏لو‎ Oohedue wk OrgeeTue Orwstray ‎schedule wih dewrrrtor cousisteuy (Pipe OO.S) where T.,‏ اوه( 417 با توص ‎reads the due P GQ bePore ood oPter thot‏ ‎ ‏سا0 لح 0 لا سواه 1 مومه ‎@eedrwr Gyetre Oocowytr, Oe.‏ 

صفحه 46:
Cursor Oinbiiy ۲ Pow oP ‏لب رم موب‎ Por progres writes ta : reorhoriccied hroguages (e.y., Pascal, O, Ovbrl, ever purpose, PLM, Porm). Bl Roker thaw bohion the eutire rebtiog, cursor ‏هجا مسحب تاماك‎ © Dhe tuple hot & curredily betay processed by the tierciza is locked i shared wode. © @oy wodhied tuples ore locked to exchusive wode nil the trocrurtiva pois. رحص وه مه اه جمدم و و ‎Osed oo hel ovessed retiives‏ © تسه رنه طممه چرت و له با ات ‎Ose‏ © ‎Od. 0040 ©Sbervehnts, Cork ced Cnakershe‏ ,تن 6 تیه 

Chapter 24: Advanced Transaction Processing  Transaction-Processing Monitors  Transactional Workflows  High-Performance Transaction Systems  Main memory databases  Real-Time Transaction Systems  Long-Duration Transactions  Transaction management in multidatabase systems Database System Concepts, 5th Ed. 25.1 ©Silberschatz, Korth and Sudarshan Transaction Processing Monitors  TP monitors initially developed as multithreaded servers to support large numbers of terminals from a single process.  Provide infrastructure for building and administering complex transaction processing systems with a large number of clients and multiple servers.  Provide services such as:   Presentation facilities to simplify creating user interfaces  Persistent queuing of client requests and server responses  Routing of client messages to servers  Coordination of two-phase commit when transactions access multiple servers. Some commercial TP monitors: CICS from IBM, Pathway from Tandem, Top End from NCR, and Encina from Transarc Database System Concepts, 5th Ed. 25.2 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures Database System Concepts, 5th Ed. 25.3 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.)   Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions.  Memory requirements are high  Multitasking- high CPU overhead for context switching between processes Single process model - all remote terminals connect to a single server process.  Used in client-server environments  Server process is multi-threaded; low cost for thread switching  No protection between applications  Not suited for parallel or distributed databases Database System Concepts, 5th Ed. 25.4 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.)   Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.  Independent server processes for multiple applications  Multithread server process  Run on parallel or distributed database Many server many-router model - multiple processes communicate with clients.  Client communication processes interact with router processes that route their requests to the appropriate server.  Controller process starts up and supervises other processes. Database System Concepts, 5th Ed. 25.5 ©Silberschatz, Korth and Sudarshan Detailed Structure of a TP Monitor Database System Concepts, 5th Ed. 25.6 ©Silberschatz, Korth and Sudarshan Detailed Structure of a TP Monitor  Queue manager handles incoming messages  Some queue managers provide persistent or durable message queueing contents of queue are safe even if systems fails.  Durable queueing of outgoing messages is important   application server writes message to durable queue as part of a transaction  once the transaction commits, the TP monitor guarantees message is eventually delevered, regardless of crashes.  ACID properties are thus provided even for messages sent outside the database Many TP monitors provide locking, logging and recovery services, to enable application servers to implement ACID properties by themselves. Database System Concepts, 5th Ed. 25.7 ©Silberschatz, Korth and Sudarshan Application Coordination Using TP Monitors  A TP monitor treats each subsystem as a resource manager that provides transactional access to some set of resources.  The interface between the TP monitor and the resource manager is defined by a set of transaction primitives  The resource manager interface is defined by the X/Open Distributed Transaction Processing standard.  TP monitor systems provide a transactional remote procedure call (transactional RPC) interface to their service  Transactional RPC provides calls to enclose a series of RPC calls within a transaction.  Updates performed by an RPC are carried out within the scope of the transaction, and can be rolled back if there is any failure. Database System Concepts, 5th Ed. 25.8 ©Silberschatz, Korth and Sudarshan Workflow Systems Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use 9 Transactional Workflows  Workflows are activities that involve the coordinated execution of multiple tasks performed by different processing entities.  With the growth of networks, and the existence of multiple autonomous database systems, workflows provide a convenient way of carrying out tasks that involve multiple systems.  Example of a workflow delivery of an email message, which goes through several mails systems to reach destination.   Each mailer performs a tasks: forwarding of the mail to the next mailer.  If a mailer cannot deliver mail, failure must be handled semantically (delivery failure message). Workflows usually involve humans: e.g. loan processing, or purchase order processing. Database System Concepts, 5th Ed. 25.10 ©Silberschatz, Korth and Sudarshan Examples of Workflows Database System Concepts, 5th Ed. 25.11 ©Silberschatz, Korth and Sudarshan Loan Processing Workflow  In the past, workflows were handled by creating and forwarding paper forms  Computerized workflows aim to automate many of the tasks. But the humans still play role e.g. in approving loans. Database System Concepts, 5th Ed. 25.12 ©Silberschatz, Korth and Sudarshan Transactional Workflows  Must address following issues to computerize a workflow.  Specification of workflows - detailing the tasks that must be carried out and defining the execution requirements.  Execution of workflows - execute transactions specified in the workflow while also providing traditional database safeguards related to the correctness of computations, data integrity, and durability.  E.g.: Loan application should not get lost even if system fails.  Extend transaction concepts to the context of workflows.  State of a workflow - consists of the collection of states of its constituent tasks, and the states (i.e. values) of all variables in the execution plan. Database System Concepts, 5th Ed. 25.13 ©Silberschatz, Korth and Sudarshan Workflow Specification  Static specification of task coordination:  Tasks and dependencies among them are defined before the execution of the workflow starts.  Can establish preconditions for execution of each task: tasks are executed only when their preconditions are satisfied.  Defined preconditions through dependencies:  Execution states of other tasks. “task ti cannot start until task tj has ended”  Output values of other tasks. “task ti can start if task tj returns a value greater than 25”  External variables, that are modified by external events. “task ti must be started within 24 hours of the completion of task tj” Database System Concepts, 5th Ed. 25.14 ©Silberschatz, Korth and Sudarshan Workflow Specification (Cont.)  Dynamic task coordination E.g. Electronic mail routing system in which the text to be schedule for a given mail message depends on the destination address and on which intermediate routers are functioning. Database System Concepts, 5th Ed. 25.15 ©Silberschatz, Korth and Sudarshan Failure-Automicity Requirements  Usual ACID transactional requirements are too strong/unimplementable for workflow applications.  However, workflows must satisfy some limited transactional properties that guarantee a process is not left in an inconsistent state.  Acceptable termination states - every execution of a workflow will terminate in a state that satisfies the failure-atomicity requirements defined by the designer.   Committed - objectives of a workflow have been achieved.  Aborted - valid termination state in which a workflow has failed to achieve its objectives. A workflow must reach an acceptable termination state even in the presence of system failures. Database System Concepts, 5th Ed. 25.16 ©Silberschatz, Korth and Sudarshan Execution of Workflows Workflow management systems include:  Scheduler - program that process workflows by submitting various tasks for execution, monitoring various events, and evaluation conditions related to intertask dependencies  Task agents - control the execution of a task by a processing entity.  Mechanism to query to state of the workflow system. Database System Concepts, 5th Ed. 25.17 ©Silberschatz, Korth and Sudarshan Workflow Management System Architectures  Centralized - a single scheduler schedules the tasks for all concurrently executing workflows.  used in workflow systems where the data is stored in a central database.  easier to keep track of the state of a workflow.  Partially distributed - has one (instance of a ) scheduler for each workflow.  Fully distributed - has no scheduler, but the task agents coordinate their execution by communicating with each other to satisfy task dependencies and other workflow execution requirements.  used in simplest workflow execution systems  based on electronic mail Database System Concepts, 5th Ed. 25.18 ©Silberschatz, Korth and Sudarshan Workflow Scheduler  Ideally scheduler should execute a workflow only after ensuring that it will terminate in an acceptable state.  Consider a workflow consisting of two tasks S1 and S2. Let the failureatomicity requirement be that either both or neither of the subtransactions should be committed.   Suppose systems executing S1 and S2 do not provide prepared-to-commit states and S1 or S2 do not have compensating transactions.  It is then possible to reach a state where one subtransaction is committed and the other aborted. Both cannot then be brought to the same state.  Workflow specification is unsafe, and should be rejected. Determination of safety by the scheduler is not possible in general, and is usually left to the designer of the workflow. Database System Concepts, 5th Ed. 25.19 ©Silberschatz, Korth and Sudarshan Recovery of a Workflow  Ensure that is a failure occurs in any of the workflow-processing components, the workflow eventually reaches an acceptable termination state.  Failure-recovery routines need to restore the state information of the scheduler at the time of failure, including the information about the execution states of each task. Log status information on stable storage.  Handoff of tasks between agents should occur exactly once in spite of failure.  Problem: Repeating handoff on recovery may lead to duplicate execution of task; not repeating handoff may lead to task not being executed.  Solution: Persistent messaging systems Database System Concepts, 5th Ed. 25.20 ©Silberschatz, Korth and Sudarshan Recovery of a Workflow (Cont.)  Persistent messages: messages are stored in permanent message queue and therefore not lost in case of failure.  Described in detail in Chapter 19 (Distributed Databases)  Before an agent commits, it writes to the persistent message queue whatever messages need to be sent out.  The persistent message system must make sure the messages get delivered eventually if and only if the transaction commits.  The message system needs to resend a message when the site recovers, if the message is not known to have reached its destination.  Messages must be logged in stable storage at the receiving end to detect multiple receipts of a message. Database System Concepts, 5th Ed. 25.21 ©Silberschatz, Korth and Sudarshan High Performance Transaction Systems Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use 22 High-Performance Transaction Systems   High-performance hardware and parallelism help improve the rate of transaction processing, but are insufficient to obtain high performance:  Disk I/O is a bottleneck — I/O time (10 milliseconds) has no decreased at a rate comparable to the increase in processor speeds.  Parallel transactions may attempt to read or write the same data item, resulting in data conflicts that reduce effective parallelism We can reduce the degree to which a database system is disk bound by increasing the size of the database buffer. Database System Concepts, 5th Ed. 25.23 ©Silberschatz, Korth and Sudarshan Main-Memory Database  Commercial 64-bit systems can support main memories of tens of gigabytes.  Memory resident data allows faster processing of transactions.  Disk-related limitations:  Logging is a bottleneck when transaction rate is high.  Use group-commit to reduce number of output operations (Will study two slides ahead.)  If the update rate for modified buffer blocks is high, the disk datatransfer rate could become a bottleneck.  If the system crashes, all of main memory is lost. Database System Concepts, 5th Ed. 25.24 ©Silberschatz, Korth and Sudarshan Main-Memory Database Optimizations  To reduce space overheads, main-memory databases can use structures with pointers crossing multiple pages. In disk databases, the I/O cost to traverse multiple pages would be excessively high.  No need to pin buffer pages in memory before data are accessed, since buffer pages will never be replaced.  Design query-processing techniques to minimize space overhead - avoid exceeding main memory limits during query evaluation.  Improve implementation of operations such as locking and latching, so they do not become bottlenecks.  Optimize recovery algorithms, since pages rarely need to be written out to make space for other pages. Database System Concepts, 5th Ed. 25.25 ©Silberschatz, Korth and Sudarshan Group Commit  Idea: Instead of performing output of log records to stable storage as soon as a transaction is ready to commit, wait until  log buffer block is full, or  a transaction has been waiting sufficiently long after being ready to commit  Results in fewer output operations per committed transaction, and correspondingly a higher throughput.  However, commits are delayed until a sufficiently large group of transactions are ready to commit, or a transaction has been waiting long enough-leads to slightly increased response time.  Above delay acceptable in high-performance transaction systems since log buffer blocks will fill up quickly. Database System Concepts, 5th Ed. 25.26 ©Silberschatz, Korth and Sudarshan Real-Time Transaction Systems    In systems with real-time constraints, correctness of execution involves both database consistency and the satisfaction of deadlines.  Hard deadline – Serious problems may occur if task is not completed within deadline  Firm deadline - The task has zero value if it completed after the deadline.  Soft deadline - The task has diminishing value if it is completed after the deadline. The wide variance of execution times for read and write operations on disks complicates the transaction management problem for time-constrained systems  main-memory databases are thus often used  Waits for locks, transaction aborts, contention for resources remain as problems even if data is in main memory Design of a real-time system involves ensuring that enough processing power exists to meet deadline without requiring excessive hardware resources. Database System Concepts, 5th Ed. 25.27 ©Silberschatz, Korth and Sudarshan Long Duration Transactions Traditional concurrency control techniques do not work well when user interaction is required:  Long duration: Design edit sessions are very long  Exposure of uncommitted data: E.g., partial update to a design  Subtasks: support partial rollback  Recoverability: on crash state should be restored even for yet-to-be committed data, so user work is not lost.  Performance: fast response time is essential so user time is not wasted. Database System Concepts, 5th Ed. 25.28 ©Silberschatz, Korth and Sudarshan Long-Duration Transactions  Represent as a nested transaction  atomic database operations (read/write) at a lowest level.  If transaction fails, only active short-duration transactions abort.  Active long-duration transactions resume once any short duration transactions have recovered.  The efficient management of long-duration waits, and the possibility of aborts.  Need alternatives to waits and aborts; alternative techniques must ensure correctness without requiring serializability. Database System Concepts, 5th Ed. 25.29 ©Silberschatz, Korth and Sudarshan Concurrency Control  Correctness without serializability:  Correctness depends on the specific consistency constraints for the databases.  Correctness depends on the properties of operations performed by each transaction.  Use database consistency constraints as to split the database into subdatabases on which concurrency can be managed separately.  Treat some operations besides read and write as fundamental low-level operations and extend concurrency control to deal with them. Database System Concepts, 5th Ed. 25.30 ©Silberschatz, Korth and Sudarshan Concurrency Control (Cont.) A non-conflict-serializable schedule that preserves the sum of A + B Database System Concepts, 5th Ed. 25.31 ©Silberschatz, Korth and Sudarshan Nested and Multilevel Transactions  A nested or multilevel transaction T is represented by a set T = {t1, t2, ..., tn} of subtransactions and a partial order P on T.  A subtransaction ti in T may abort without forcing T to abort.  Instead, T may either restart ti, or simply choose not to run ti.  If ti commits, this action does not make ti, permanent (unlike the situation in Chapter 15). Instead, ti, commits to T, and may still abort (or require compensation) if T aborts.  An execution of T must not violate the partial order P, i.e., if an edge ti  ti appears in the precedence graph, then ti  ti must not be in the transitive closure of P. Database System Concepts, 5th Ed. 25.32 ©Silberschatz, Korth and Sudarshan Nested and Multilevel Transactions (Cont.)  Subtransactions can themselves be nested/multilevel transactions.  Lowest level of nesting: standard read and write operations.  Nesting can create higher-level operations that may enhance concurrency.  Types of nested/ multilevel transactions:  Multilevel transaction: subtransaction of T is permitted to release locks on completion.  Saga: multilevel long-duration transaction.  Nested transaction: locks held by a subtransaction ti of T are automatically assign to T on completion of ti. Database System Concepts, 5th Ed. 25.33 ©Silberschatz, Korth and Sudarshan Example of Nesting  Rewrite transaction T1 using subtransactions Ta and Tb that perform increment or decrement operations:    T1,1, which subtracts 50 from A  T1,2, which adds 50 to B Rewrite transaction T2 using subtransactions Tc and Td that perform increment or decrement operations:   T1 consists of T2 consists of  T2,1, which subtracts 10 from B  T2,2, which adds 10 to A No ordering is specified on subtransactions; any execution generates a correct result. Database System Concepts, 5th Ed. 25.34 ©Silberschatz, Korth and Sudarshan Compensating Transactions  Alternative to undo operation; compensating transactions deal with the problem of cascading rollbacks.  Instead of undoing all changes made by the failed transaction, action is taken to “compensate” for the failure.  Consider a long-duration transaction Ti representing a travel reservation, with subtransactions Ti,1, which makes airline reservations, Ti,2 which reserves rental cars, and Ti,3 which reserves a hotel room.  Hotel cancels the reservation.  Instead of undoing all of Ti, the failure of Ti,3 is compensated for by deleting the old hotel reservation and making a new one.  Requires use of semantics of the failed transaction. Database System Concepts, 5th Ed. 25.35 ©Silberschatz, Korth and Sudarshan Implementation Issues  For long-duration transactions to survive system crashes, we must log not only changes to the database, but also changes to internal system data pertaining to these transactions.  Logging of updates is made more complex by physically large data items (CAD design, document text); undesirable to store both old and new values.  Two approaches to reducing the overhead of ensuring the recoverability of large data items:  Operation logging. Only the operation performed on the data item and the dataitem name are stored in the log.  Logging and shadow paging. Use logging from small data items; use shadow paging for large data items. Only modified pages need to be stored in duplicate. Database System Concepts, 5th Ed. 25.36 ©Silberschatz, Korth and Sudarshan Transaction Management in Multidatabase Systems  Transaction management is complicated in multidatabase systems because of the assumption of autonomy  Global 2PL -each local site uses a strict 2PL (locks are released at the end); locks set as a result of a global transaction are released only when that transaction reaches the end.   Due to autonomy requirements, sites cannot cooperate and execute a common concurrency control scheme   Guarantees global serializability E.g. no way to ensure that all databases follow strict 2PL Solutions:  provide very low level of concurrent execution, or  use weaker levels of consistency Database System Concepts, 5th Ed. 25.37 ©Silberschatz, Korth and Sudarshan Transaction Management  Local transactions are executed by each local DBMS, outside of the MDBS system control.  Global transactions are executed under multidatabase control.  Local autonomy - local DBMSs cannot communicate directly to synchronize global transaction execution and the multidatabase has no control over local transaction execution.  local concurrency control scheme needed to ensure that DBMS’s schedule is serializable  in case of locking, DBMS must be able to guard against local deadlocks.  need additional mechanisms to ensure global serializability Database System Concepts, 5th Ed. 25.38 ©Silberschatz, Korth and Sudarshan Two-Level Serializability  DBMS ensures local serializability among its local transactions, including those that are part of a global transaction.  The multidatabase ensures serializability among global transactions alone- ignoring the orderings induced by local transactions.  2LSR does not ensure global serializability, however, it can fulfill requirements for strong correctness. 1. Preserve consistency as specified by a given set of constraints 2. Guarantee that the set of data items read by each transaction is consistent  Global-read protocol : Global transactions can read, but not update, local data items; local transactions do not have access to global data. There are no consistency constraints between local and global data items. Database System Concepts, 5th Ed. 25.39 ©Silberschatz, Korth and Sudarshan Two-Level Serializability (Cont.)  Local-read protocol : Local transactions have read access to global data; disallows all access to local data by global transactions.  A transaction has a value dependency if the value that it writes to a data item at one site depends on a value that it read for a data item on another site.  For strong correctness: No transaction may have a value dependency.  Global-read-write/local-read protocol; Local transactions have read access to global data; global transactions may read and write all data;  No consistency constraints between local and global data items.  No transaction may have value dependency. Database System Concepts, 5th Ed. 25.40 ©Silberschatz, Korth and Sudarshan Global Serializability  Even if no information is available concerning the structure of the various concurrency control schemes, a very restrictive protocol that ensures serializability is available.  Transaction-graph : a graph with vertices being global transaction names and site names.  An undirected edge (Ti, Sk) exists if Ti is active at site Sk.  Global serializability is assured if transaction-graph contains no undirected cycles. Database System Concepts, 5th Ed. 25.41 ©Silberschatz, Korth and Sudarshan Ensuring Global Serializability  Each site Si has a special data item, called ticket  Every transaction Tj that runs at site Sk writes to the ticket at site Si  Ensures global transactions are serialized at each site, regardless of local concurrency control method, so long as the method guarantees local serializability  Global transaction manager decides serial ordering of global transactions by controlling order in which tickets are accessed  However, above protocol results in low concurrency between global transactions. Database System Concepts, 5th Ed. 25.42 ©Silberschatz, Korth and Sudarshan End of Chapter Database System Concepts ©Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use 43 Weak Levels Consistency  Use alternative notions of consistency that do not ensure serializability, to improve performance.  Degree-two consistency avoids cascading aborts without necessarily ensuring serializability.  Unlike two-phase locking, S-locks may be released at any time, and licks may be acquired at any time.  X-locks be released until the transaction either commits or aborts. Database System Concepts, 5th Ed. 25.44 ©Silberschatz, Korth and Sudarshan Example Schedule with Degree-Two Consistency Nonserializable schedule with degree-two consistency (Figure 20.5) where T3 reads the value if Q before and after that value is written by T4. T3 T4 lock-S (Q) read (Q) unlock (Q) lock-X (Q) read (Q) write (Q) unlock (Q) lock-S (Q) read (Q) unlock (Q) Database System Concepts, 5th Ed. 25.45 ©Silberschatz, Korth and Sudarshan Cursor Stability  Form of degree-two consistency designed for programs written in general-purpose, record-oriented languages (e.g., Pascal, C, Cobol, PL/I, Fortran).  Rather than locking the entire relation, cursor stability ensures that  The tuple that is currently being processed by the iteration is locked in shared mode.  Any modified tuples are locked in exclusive mode until the transaction commits.  Used on heavily accessed relations as a means of increasing concurrency and improving system performance.  Use is limited to specialized situations with simple consistency constraints. Database System Concepts, 5th Ed. 25.46 ©Silberschatz, Korth and Sudarshan