TransakΦnφ zpracovßnφ, tak jak bylo dosud v DatabßzovΘ abeced∞ zmi≥ovßno, bylo zalo₧eno na p°edpokladu jednoho procesoru sdφlenΘho vφce procesy. Pro °adu aplikacφ je dnes takovß architektura nep°ijatelnß. D∙vodem m∙₧e jednak vysokß cena zpracovßnφ (procesor pro vysok² provoz transakcφ nestaΦφ), nebo fakt ₧e transakce vy₧aduje data p°irozen∞ umφst∞nß na vφce poΦφtaΦφch. ╪eÜenφm tedy jsou architektury vyu₧φvajφcφ vφce procesor∙. Prvnφ mo₧nostφ jsou paralelnφ systΘmy, kterΘ je nutno odliÜovat od dalÜφho typu architektur - distribuovan²ch systΘm∙. Zatφmco v p°φpad∞ paralelnφch architektur jde o vφce CPU fyzicky spojen²ch do kompaktnφho celku, u distribuovan²ch architektur jsou CPU obvykle distribuovßny geograficky. Paralelnφ systΘmy p°edstavujφ pokus konstruovat rychlejÜφ a takΘ levn∞jÜφ centralizovan² poΦφtaΦ, distribuovanΘ systΘmy specißln∞ v databßzφch vychßzejφ z pot°eby nabφdnout lokßln∞ autonomnφ systΘmy s mo₧nostφ globßlnφho Φi integrovanΘho pohledu na distribuovanß data. V distribuovan²ch databßzφch se dotazy a dalÜφ po₧adavky na manipulaci s daty provßd∞jφ nezßvisle v r∙zn²ch mφstech a ΦßsteΦnΘ v²sledky na zßklad∞ komunikace mezi mφsty p°ispφvajφ k vytvo°enφ celkovΘho v²sledku.

Budeme uva₧ovat architekturu, kdy n∞kolik procesor∙ je provozovßno paraleln∞, p°iΦem₧ ka₧d² z nich mß svou vlastnφ vnit°nφ a vn∞jÜφ pam∞¥. Jde o architekturu v souvislosti s paralelnφmi databßzov²mi servery naz²vanou ôsdφlenφ niΦehoö, v p°φpadech, kdy procesory a data jsou umφst∞ny v uzlech obvykle geograficky distribuovanΘ sφt∞, se hovo°φ o distribuovan²ch databßzov²ch systΘmech.

ProblΘm zpracovßnφ transakce je v obou p°φpadech podobn². Transakce vyvolanß v jednom uzlu je rozd∞lena na podtransakce, kterΘ se provßd∞jφ na dalÜφch uzlech. Nap°. zßkaznφk banky m∙₧e mφt veden ·Φet v poboΦce P2 (databßze je na uzlu U2) a chce si vybrat Φßstku v poboΦce P1 (databßze je na uzlu U1). ┌Φetnφ transakce v P1 bude z°ejm∞ zahrnovat podtransakci T2, kterß na uzlu U2 zaznamenß pohyb na zßkaznφkov∞ ·Φtu, podtransakce T1 na uzlu P1 zahrne pokladnφ operaci a zßznam do historie operacφ proveden²ch v poboΦce P1. Softwarovß komponenta databßze na uzlu U1 - transakΦnφ mana₧er TM1, bude koordinovat p∙vodnφ (distribuovanou) transakci. Co vÜak tato koordinace znamenß? ╪ekneme, ₧e podtransakce transakce T jsou v jednotliv²ch uzlech koordinovßny, jestli₧e je garantovßno, ₧e vÜechny budou bu∩ potvrzenΘ nebo zruÜenΘ. Distribuovanß transakce vlastn∞ d∞dφ vlastnosti ACID z jednotliv²ch uzl∙. Nejt∞₧Üφ ovÜem je zajistit globßlnφ po₧adavek - bu∩ vÜe nebo nic, tj. globßlnφ atomicitu transakce vypl²vajφcφ z po₧adavku koordinace a dßle globßlnφ trvanlivost, tj. promφtnutφ vÜech zm∞n do databßzφ participujφcφch uzl∙.

Distribuovanß transakce (vyvolanß nap°. v U1) mß pouze t°i stavy: A (aktivnφ), C (potvrzenß) a AB (zruÜenß), p°iΦem₧ z A lze vstoupit bu∩ do C nebo AB a jak z A tak z AB nelze ji₧ jφt nikam. P°esto₧e v lokßlnφch uzlech, kde se provßd∞jφ podtransakce, je mo₧nΘ po chybovΘm stavu restartovat transakci, jde o akci °φzenou logikou aplikace. Jestli₧e je tedy nap°. provedena ·sp∞Ün∞ T2 v uzlu U2, tj. je tam potvrzena, a vypadne uzel U1, vede zpracovßnφ k zruÜenφ celΘ transakce. Bohu₧el, v uzlu U2 nenφ ji₧ mo₧n∞ ·sp∞Ünou podtransakci vrßtit do p∙vodnφho stavu (dokonce ji₧ mo₧nß poskytla zm∞n∞nß data pro ·Φely eventußlnφch lokßlnφch transakcφ v uzlu U2). Z toho ale vypl²vß, ₧e koordinace distribuovanΘ transakce pouze na zßklad∞ transakΦnφho zpracovßnφ v jednotliv²ch uzlech nenφ mo₧nß.

Zdß se, ₧e je pot°eba n∞jak² dalÜφ stav, ve kterΘm se m∙₧e distribuovanß transakce nachßzet. Takov² stav, navr₧en² pro podtransakce, nazveme p°ipraven² (P). Podtransakce T se stane p°ipravenß, vydal-li koordinßtor distribuovanΘ transakce po₧adavek na p°ipravenost, v mφst∞ danΘ T jsou vÜechny operace provedeny a do p°φsluÜnΘho ₧urnßlu transakcφ (log file) byl o tomto proveden odpovφdajφcφ zßznam. P°ipome≥me, ₧e jde vlastn∞ o obdobu stavu PC (ΦßsteΦnΘ potvrzenφ), kter² znßme z obyΦejnΘho (nedistribuovanΘho) zpracovßnφ transakcφ. Ze stavu p°ipravenosti m∙₧e transakce p°ejφt bu∩ do stavu AB nebo C. V p°φpad∞ havßrie vÜak lze p°ipravenou podtransakci op∞t uvΘst do stavu p°ipravenosti. SchΘma mo₧n²ch stav∙ a jejich vztah∙ je na obrßzku 1.

A

F AB

Obr. 1 Stavy podtransakcφ

Na zßklad∞ zavedenφ stavu p°ipravenosti, n∞kdy tΘ₧ naz²vanΘho RC (Ready to Commit), byl definovßn mechanismus znßm² z °ady komerΦnφch databßzov²ch produkt∙, kter² se naz²vß dvoufßzov² potvrzovacφ protokol.

Dvoufßzov² potvrzovacφ protokol (2PC) lze popsat nßsledovn∞:

Fßze 1: Koordinßtor zaÜle zprßvu vÜem uzl∙m, na kter²ch se provßd∞jφ podtransakce k danΘ distribuovanΘ transakci, ve kterΘ je po₧adavek na p°ipravenost. Jestli₧e n∞kterß z odpov∞dφ hlßsφ ne·sp∞Ünost, pak koordinßtor provede ROLLBACK na transakci ve svΘm uzlu a poÜle zprßvu vÜem z·Φastn∞n²m uzl∙m s po₧adavkem na zruÜenφ (ABORT) podtransakcφ.

Fßze 2: Vedou-li vÜechny po₧adavky na p°ipravenost k odpov∞di hlßsφcφ ·sp∞Ünost, pak koordinßtor potvrdφ distribuovanou transakci a jejφ lokßlnφ komponenty ve svΘm uzlu, a pak odeÜle zprßvy s po₧adavkem na potvrzenφ (COMMIT) vÜech participujφcφch transakcφ v p°φsluÜn²ch uzlech. Tyto zprßvy d°φve nebo pozd∞ji budou vÜechny doruΦeny.

ProblΘm, co d∞lat, kdy₧ jedna transakce je potvrzenß a druhß zhavaruje vedlo p∙vodn∞ ke stavu AB celΘ distribuovanΘ transakce. To vÜak te∩ ji₧ ·pln∞ neplatφ. Jsou-li vÜechny podtransakce ve stavu p°ipravenosti, doÜlo k potvrzenφ distribuovanΘ transakce, byl vydßn po₧adavek na potvrzenφ podtransakcφ, pak, i kdy₧ nastane chyba v n∞jakΘm uzlu, nic se ned∞je. P°ipravenß a nßsledn∞ zhroucenß podtransakce m∙₧e b²t stßle jeÜt∞ uvedena do stavu p°ipravenosti (rekonstrukce pomocφ operace REDO a ₧urnßlu transakcφ v danΘm uzlu). P°φsluÜn² po₧adavek na COMMIT se pouze provede pozd∞ji. Zhavaruje-li koordinaΦnφ uzel po vlastnφm provedenφ COMMIT, takΘ zde m∙₧e b²t provedeno zotavenφ z chyby a odeslßnφ po₧adavk∙ na COMMIT do participujφcφch uzl∙ je pouze odlo₧eno, proto₧e koordinaΦnφ uzel si udr₧uje seznam participujφcφch podtransakcφ. Bohu₧el toto odlo₧enφ m∙₧e b²t dlouhΘ, tak₧e po celou tuto dobu jsou participanti blokovßni. Nemohou nap°. uvolnit odpovφdajφcφ zßmky na p°φsluÜn²ch zdrojφch dat. ╪eÜenφm m∙₧e b²t decentralizace v ukonΦenφ transakce. Participanti komunikujφ mezi sebou a jakmile zjistφ, ₧e alespo≥ jeden z nich je ji₧ ve stavu C nebo AB, kter² se objevil po vydßnφ globßlnφho p°φkazu COMMIT nebo ABORT, majφ Üanci p°ejφt do tΘho₧ stavu takΘ. Z toho ovÜem plyne, ₧e ka₧d² participant musφ znßt ostatnφ. To vÜak m∙₧e b²t informace zahrnutß do zprßvy PREPARE .

Existujφ i jinß °eÜenφ, nap°. t°φfßzov² potvrzovacφ protokol. V n∞m po v²padku koordinßtore existuje mo₧nost, ₧e jeho roli p°evezme jin² uzel. Pro praxi vÜak vedou takovΘ protokoly k velkΘ re₧ii.

ProblΘm, m∙₧e ovÜem nastat tehdy, nevracφ-li se odpov∞di na pou₧itΘ zprßvy vΦas od participujφcφch uzl∙. Nap°. objevφ-li se chyba v sφtφ. lze zavΘst pravidlo zruÜit transakci po n∞jakΘ urΦitΘ dob∞ (time out). To se uplatnφ zejmΘna v koordinaΦnφm uzlu ve fßzi 1.

Z hlediska SQL se realizuje 2PC pro danou transakci vydßnφm p°φkazu COMMIT WORK, tj. zaΦne realizace prvnφ fßze. Koordinßtor vyÜle p°φkaz PREPARE vÜem participujφcφm uzl∙m. Odpov∞di z dφlΦφch uzl∙ mohou b²t bu∩ YES VOTE nebo NO VOTE, podle toho, p°eje-li si participovat ·sp∞Ün∞ (je-li to v∙bec mo₧nΘ) nebo ne. V prvnφm p°φpad∞ je samoz°ejm∞ nutn² zßpis o p°ipravenosti do ₧urnßlu transakcφ. Ve druhΘm p°φpad∞, proto₧e z 2PC vypl²vß prßvo veta libovolnΘho participanta, m∙₧e lokßlnφ uzel uvolnit zßmky, zruÜit podtransakci a zapomenout, ₧e kdy existovala, tj. nemusφ ji₧ Φekat nic od koordinßtora. Ti, co odpov∞d∞li positivn∞, musφ Φekat na globßlnφ COMMIT, nebo ABORT. Navφc, nemohou takΘ svΘ pozitivnφ rozhodnutφ zm∞nit. Ti, co se rozhodli pro NO VOTE, nepot°ebujφ takΘ Φekat na globßlnφ ABORT.

SouΦßstφ 2PC protokolu ji₧ neb²vß potvrzenφ o provedenφ odpovφdajφcφch akcφch v participujφcφch uzlech. V implementacφch vÜak b²vß realizovßno, proto₧e koordinßtor tak zφskß kontrolu v²sledku p°ed tφm, ne₧ zapomene distribuovanou transakci. Slo₧itost 2PC je dßna poΦtem zßpis∙ do ₧urnßl∙ transakcφ u koordinßtora a participant∙, dßle pak poΦtem p°enßÜen²ch zprßv.

Existujφ r∙znΘ varianty 2PC protokolu. Dv∞ z nich jsou d∙le₧itΘ: p°edpoklßdan² ABORT 2PC a p°edpoklßdan² COMMIT 2PC. Jejich d∙le₧itost spoΦφvß v tom, nebo¥ redukujφ poΦet zprßv vym∞≥ovan²ch mezi koordinßtorem a participanty. Prvnφ varianta je zahrnuta do X/Open XA standardu, druhß je Φßstφ ISO standardu pro Open Distributed Processing.

Potvrzovßnφ v distribuovanΘm systΘmu p°edstavuje znaΦnou zßt∞₧. Existujφ m∞°enφ dokazujφcφ nap°., ₧e transakce pro aktualizaci jednoho zßznamu pod univerzßlnφm S╪BD pot°ebuje pro COMMIT Φßst transakce zhruba 1/3 dΘlky trvßnφ celΘ transakce. V distribuovanΘm prost°edφ jsou Φasy jeÜt∞ vyÜÜφ. Pro praxi to tedy znamenß, ₧e distribuovanΘ transakce se zatφm aplikujφ spφÜe na dotazy (read-only transakce) a spφÜe mΘn∞ na aktualizace.