{"id":30878,"date":"2019-10-31T21:37:56","date_gmt":"2019-10-31T18:37:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-i-mehanizmy-ih-kontrolya\/"},"modified":"2019-10-31T21:37:56","modified_gmt":"2019-10-31T18:37:56","slug":"tranzaktsii-i-mehanizmy-ih-kontrolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transakce a mechanismy jejich kontroly","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transakce<\/h2>\n

<\/p>\n

Transakc\u00ed se rozum\u00ed sekvence operac\u00ed nad daty, kter\u00e1 m\u00e1 za\u010d\u00e1tek a konec<\/h4>\n

\nTransakce je sekven\u010dn\u00ed prov\u00e1d\u011bn\u00ed operac\u00ed \u010dten\u00ed a z\u00e1pisu. Konec transakce m\u016f\u017ee b\u00fdt bu\u010f ulo\u017een\u00ed zm\u011bn (potvrzen\u00ed, commit) nebo zru\u0161en\u00ed zm\u011bn (rollback). V kontextu datab\u00e1z\u00ed je transakce n\u011bkolik dotaz\u016f, kter\u00e9 jsou ch\u00e1p\u00e1ny jako jeden dotaz.<\/p>\n

Transakce mus\u00ed spl\u0148ovat vlastnosti ACID<\/h4>\n

\nAtomarita. Transakce bu\u010f prob\u011bhne cel\u00e1, nebo v\u016fbec neprob\u011bhne.<\/p>\n

Konzistence. P\u0159i ukon\u010den\u00ed transakce nesm\u00ed b\u00fdt poru\u0161ena omezen\u00ed ulo\u017een\u00e1 na data (nap\u0159\u00edklad constraints v datab\u00e1zi). Konzistence znamen\u00e1, \u017ee syst\u00e9m bude p\u0159eveden z jednoho spr\u00e1vn\u00e9ho stavu do druh\u00e9ho spr\u00e1vn\u00e9ho.<\/p>\n

Izolovanost. Paraleln\u011b prov\u00e1d\u011bn\u00e9 transakce by nem\u011bly m\u00edt vliv jedna na druhou, nap\u0159\u00edklad m\u011bnit data, kter\u00e1 pou\u017e\u00edv\u00e1 jin\u00e1 transakce. V\u00fdsledek prov\u00e1d\u011bn\u00ed paraleln\u00edch transakc\u00ed by m\u011bl b\u00fdt takov\u00fd, jako by transakce prob\u00edhaly sekven\u010dn\u011b.<\/p>\n

Trvanlivost. Po potvrzen\u00ed nesm\u00ed b\u00fdt zm\u011bny ztraceny.
\n<\/a><\/noindex><\/p>\n

\u017durn\u00e1l transakc\u00ed<\/h2>\n

<\/p>\n

\u017durn\u00e1l uchov\u00e1v\u00e1 zm\u011bny proveden\u00e9 transakcemi a zaji\u0161\u0165uje atomaritu a trvanlivost dat v p\u0159\u00edpad\u011b selh\u00e1n\u00ed syst\u00e9mu.<\/h4>\n

\n\u017durn\u00e1l obsahuje hodnoty, kter\u00e9 data m\u011bly p\u0159ed a po jejich zm\u011bn\u011b transakc\u00ed. Strategie Write-ahead log vy\u017eaduje, aby se do \u017eurn\u00e1lu p\u0159id\u00e1valy z\u00e1znamy o p\u0159edchoz\u00edch hodnot\u00e1ch p\u0159ed za\u010d\u00e1tkem, a o koncov\u00fdch po dokon\u010den\u00ed transakce. V p\u0159\u00edpad\u011b n\u00e1hl\u00e9ho zastaven\u00ed syst\u00e9mu \u010dte datab\u00e1ze log v obr\u00e1cen\u00e9m po\u0159ad\u00ed a ru\u0161\u00ed zm\u011bny proveden\u00e9 transakcemi. Pokud datab\u00e1ze naraz\u00ed na p\u0159eru\u0161enou transakci, provede ji a zaznamen\u00e1 jej\u00ed zm\u011bny do \u017eurn\u00e1lu. Kdy\u017e se nach\u00e1z\u00ed ve stavu v dob\u011b selh\u00e1n\u00ed, datab\u00e1ze \u010dte log v p\u0159\u00edm\u00e9m po\u0159ad\u00ed a vrac\u00ed zm\u011bny proveden\u00e9 transakcemi. T\u00edmto zp\u016fsobem se zachov\u00e1v\u00e1 trvanlivost transakc\u00ed, kter\u00e9 ji\u017e byly potvrzeny, a atomarita p\u0159eru\u0161en\u00e9 transakce.<\/p>\n

Jednoduch\u00e9 opakov\u00e1n\u00ed chybov\u00fdch transakc\u00ed nesta\u010d\u00ed k obnoven\u00ed. <\/p>\n

P\u0159\u00edklad. Na \u00fa\u010dtu u\u017eivatele je 500 $ a u\u017eivatel se rozhodne je vybrat p\u0159es bankomat. Doch\u00e1z\u00ed k dv\u011bma transakc\u00edm. Prvn\u00ed \u010dte hodnotu z\u016fstatku a pokud je na z\u016fstatku dostatek prost\u0159edk\u016f, vyd\u00e1 pen\u00edze u\u017eivateli. Druh\u00e1 \u010d\u00e1st ode\u010d\u00edt\u00e1 pot\u0159ebnou \u010d\u00e1stku ze z\u016fstatku. P\u0159edpokl\u00e1dejme, \u017ee do\u0161lo k selh\u00e1n\u00ed syst\u00e9mu a prvn\u00ed operace neprob\u011bhla, zat\u00edmco druh\u00e1 prob\u011bhla. V takov\u00e9m p\u0159\u00edpad\u011b nem\u016f\u017eeme u\u017eivateli znovu vydat pen\u00edze, ani\u017e bychom vr\u00e1tili syst\u00e9m do p\u016fvodn\u00edho stavu s kladn\u00fdm z\u016fstatkem.<\/i><\/p>\n

\u00darovn\u011b izolace<\/h2>\n

<\/p>\n

\u010cten\u00ed potvrzen\u00fdch dat (Read Committed)<\/h4>\n

\nProbl\u00e9m \u0161pinav\u00e9ho \u010dten\u00ed (Dirty Read) spo\u010d\u00edv\u00e1 v tom, \u017ee transakce m\u016f\u017ee p\u0159e\u010d\u00edst meziv\u00fdsledek pr\u00e1ce jin\u00e9 transakce.<\/p>\n

P\u0159\u00edklad. Po\u010d\u00e1te\u010dn\u00ed hodnota z\u016fstatku 0 $. T1 p\u0159id\u00e1v\u00e1 k z\u016fstatku 50 $. T2 \u010dte hodnotu z\u016fstatku (50 $). T1 ru\u0161\u00ed zm\u011bny a kon\u010d\u00ed. T2 pokra\u010duje v prov\u00e1d\u011bn\u00ed s neplatn\u00fdmi daty o z\u016fstatku.<\/i><\/p>\n

\u0158e\u0161en\u00edm je \u010dten\u00ed potvrzen\u00fdch dat (Read Committed), kter\u00e9 zakazuje \u010d\u00edst data, zm\u011bn\u011bn\u00e1 transakc\u00ed. Pokud transakce A zm\u011bnila n\u011bjakou sadu dat, mus\u00ed transakce B p\u0159i p\u0159\u00edstupu k t\u011bmto dat\u016fm \u010dekat na dokon\u010den\u00ed transakce A.<\/p>\n

Opakovan\u00e9 \u010dten\u00ed (Repeatable Read)<\/h4>\n

\nProbl\u00e9m ztracen\u00fdch zm\u011bn (Lost Updates). T1 ukl\u00e1d\u00e1 zm\u011bny na vrcholu zm\u011bn T2.<\/p>\n

P\u0159\u00edklad. Po\u010d\u00e1te\u010dn\u00ed hodnota z\u016fstatku 0 $ a dv\u011b transakce z\u00e1rove\u0148 dopl\u0148uj\u00ed z\u016fstatek. T1 a T2 \u010dtou z\u016fstatek rovn\u00fd 0 $. Pot\u00e9 T2 p\u0159id\u00e1v\u00e1 200 $ k 0 $ a ukl\u00e1d\u00e1 v\u00fdsledek. T1 p\u0159id\u00e1v\u00e1 100 $ k 0 $ a ukl\u00e1d\u00e1 v\u00fdsledek. Kone\u010dn\u00fd v\u00fdsledek je 100 $ m\u00edsto 300 $.<\/i><\/p>\n

Probl\u00e9m nep\u0159 repeateln\u00e9ho \u010dten\u00ed (Unrepeatable read). Opakovan\u00e9 \u010dten\u00ed stejn\u00fdch dat vrac\u00ed r\u016fzn\u00e9 hodnoty.<\/p>\n

P\u0159\u00edklad. T1 \u010dte hodnotu z\u016fstatku rovnou 0 $. Pot\u00e9 T2 p\u0159id\u00e1v\u00e1 k z\u016fstatku 50 $ a kon\u010d\u00ed. T1 znovu \u010dte data a zji\u0161\u0165uje nesoulad s p\u0159edchoz\u00edm v\u00fdsledkem.<\/i><\/p>\n

Opakovan\u00e9 \u010dten\u00ed (Repeatable Read) zaru\u010duje, \u017ee opakovan\u00e9 \u010dten\u00ed vr\u00e1t\u00ed stejn\u00fd v\u00fdsledek. Data p\u0159e\u010dten\u00e1 jednou transakc\u00ed nesm\u011bj\u00ed b\u00fdt m\u011bn\u011bna v jin\u00fdch a\u017e do dokon\u010den\u00ed transakce. Pokud transakce A p\u0159e\u010detla n\u011bjakou sadu dat, mus\u00ed transakce B p\u0159i p\u0159\u00edstupu k t\u011bmto dat\u016fm \u010dekat na dokon\u010den\u00ed transakce A.<\/p>\n

Uspo\u0159\u00e1dan\u00e9 \u010dten\u00ed (Serializable)<\/h4>\n

\nProbl\u00e9m phantomov\u00e9ho \u010dten\u00ed (Phantom Reads). Dva dotazy vyb\u00edraj\u00edc\u00ed data podle ur\u010dit\u00e9ho krit\u00e9ria vracej\u00ed r\u016fzn\u00e9 hodnoty.<\/p>\n

P\u0159\u00edklad. T1 dotazuje po\u010det v\u0161ech u\u017eivatel\u016f, jejich\u017e z\u016fstatek je v\u011bt\u0161\u00ed ne\u017e 0 $ ale men\u0161\u00ed ne\u017e 100 $. T2 ode\u010d\u00edt\u00e1 1 $ od u\u017eivatele se z\u016fstatkem 101 $. T1 vykon\u00e1v\u00e1 dotaz znovu.<\/i><\/p>\n

Uspo\u0159\u00e1dan\u00e9 \u010dten\u00ed (Serializable). Transakce prob\u00edhaj\u00ed jako zcela sekven\u010dn\u00ed. Je zak\u00e1z\u00e1no aktualizovat a p\u0159id\u00e1vat z\u00e1znamy, kter\u00e9 spadaj\u00ed pod podm\u00ednky dotazu. Pokud transakce A vy\u017e\u00e1dala data z cel\u00e9 tabulky, je tabulka pro ostatn\u00ed transakce zcela zmrazena, dokud transakce A nedokon\u010d\u00ed.<\/p>\n

Pl\u00e1nova\u010d (Scheduler)<\/h2>\n

<\/p>\n

Stanovuje po\u0159ad\u00ed, ve kter\u00e9m maj\u00ed b\u00fdt operace prov\u00e1d\u011bny p\u0159i paraleln\u00edch transakc\u00edch.<\/h4>\n

\nZaji\u0161\u0165uje danou \u00farove\u0148 izolace. Pokud v\u00fdsledek proveden\u00ed operac\u00ed nez\u00e1vis\u00ed na jejich po\u0159ad\u00ed, jsou takov\u00e9 operace komutativn\u00ed (Permutable). Komutativn\u00ed jsou operace \u010dten\u00ed a operace nad r\u016fzn\u00fdmi daty. Operace \u010dten\u00ed-z\u00e1pisu a z\u00e1pisu-z\u00e1pisu nejsou komutativn\u00ed. \u00dakolem pl\u00e1nova\u010de je st\u0159\u00eddat operace prov\u00e1d\u011bn\u00e9 paraleln\u00edmi transakcemi tak, aby v\u00fdsledek byl ekvivalentn\u00ed sekven\u010dn\u00edmu prov\u00e1d\u011bn\u00ed transakc\u00ed.<\/p>\n

Mechanismy \u0159\u00edzen\u00ed paraleln\u00edch \u00faloh (Concurrency Control)<\/h2>\n

<\/p>\n

Optimistick\u00fd se zakl\u00e1d\u00e1 na odhalov\u00e1n\u00ed a \u0159e\u0161en\u00ed konflikt\u016f, pesimistick\u00fd na prevenci vzniku konflikt\u016f.<\/h4>\n

\nP\u0159i optimistick\u00e9m p\u0159\u00edstupu z\u00edsk\u00e1v\u00e1 n\u011bkolik u\u017eivatel\u016f kopie dat. Prvn\u00ed, kdo dokon\u010d\u00ed \u00fapravy, ukl\u00e1d\u00e1 zm\u011bny, zat\u00edmco ostatn\u00ed mus\u00ed prov\u00e9st slou\u010den\u00ed zm\u011bn. Optimistick\u00fd algoritmus umo\u017e\u0148uje vznik konfliktu, ale syst\u00e9m se mus\u00ed po konfliktu zotavit.<\/p>\n

P\u0159i pesimistick\u00e9m p\u0159\u00edstupu prvn\u00ed u\u017eivatel, kter\u00fd si data zajist\u00ed, br\u00e1n\u00ed ostatn\u00edm v p\u0159\u00edstupu k dat\u016fm. Pokud jsou konflikty vz\u00e1cn\u00e9, je rozumn\u00e9 zvolit optimistickou strategii, proto\u017ee ta zaji\u0161\u0165uje vy\u0161\u0161\u00ed \u00farove\u0148 paralelismu.<\/p>\n

Zamyk\u00e1n\u00ed (Locking)<\/h2>\n

<\/p>\n

Pokud jedna transakce zablokovala data, zb\u00fdvaj\u00edc\u00ed transakce mus\u00ed p\u0159i p\u0159\u00edstupu k dat\u016fm \u010dekat na jejich odemknut\u00ed.<\/h4>\n

\nBlok m\u016f\u017ee b\u00fdt aplikov\u00e1n na datab\u00e1zi, tabulku, \u0159adu nebo atribut. Sd\u00edlen\u00e1 z\u00e1mek (Shared Lock) m\u016f\u017ee b\u00fdt aplikov\u00e1n na stejn\u00e1 data n\u011bkolika transakcemi, umo\u017e\u0148uje v\u0161em transakc\u00edm (v\u010detn\u011b t\u00e9, kter\u00e1 z\u00e1mek aplikovala) \u010dten\u00ed, ale zakazuje modifikaci a exkluzivn\u00ed z\u00e1mek. Exkluzivn\u00ed z\u00e1mek (Exclusive Lock) m\u016f\u017ee b\u00fdt aplikov\u00e1n pouze jednou transakc\u00ed, umo\u017e\u0148uje jakoukoli \u010dinnost aplikovan\u00e9 transakce, zakazuje jak\u00e9koli \u010dinnosti ostatn\u00edm.<\/p>\n

Vz\u00e1jemn\u00e9 blokov\u00e1n\u00ed se pova\u017euje za situaci, kdy transakce jsou v re\u017eimu \u010dek\u00e1n\u00ed, kter\u00fd trv\u00e1 nekone\u010dn\u011b dlouho.<\/h4>\n

\nP\u0159\u00edklad. Prvn\u00ed transakce \u010dek\u00e1 na uvoln\u011bn\u00ed dat, kter\u00e1 byla zachycena druhou, zat\u00edmco druh\u00e1 \u010dek\u00e1 na uvoln\u011bn\u00ed dat, kter\u00e1 byla zachycena prvn\u00ed.<\/i><\/p>\n

Optimistick\u00e9 \u0159e\u0161en\u00ed probl\u00e9mu vz\u00e1jemn\u00e9ho blokov\u00e1n\u00ed umo\u017e\u0148uje vz\u00e1jemn\u00e9 blokov\u00e1n\u00ed nastat, ale pot\u00e9 obnovuje syst\u00e9m vr\u00e1cen\u00edm jedn\u00e9 z transakc\u00ed, kter\u00e9 se pod\u00edlej\u00ed na vz\u00e1jemn\u00e9m blokov\u00e1n\u00ed.<\/h4>\n

\nS ur\u010ditou pravidelnost\u00ed se prov\u00e1d\u00ed hled\u00e1n\u00ed vz\u00e1jemn\u00e9ho blokov\u00e1n\u00ed. Jeden ze zp\u016fsob\u016f detekce \u2014 podle \u010dasu, co\u017e znamen\u00e1 pova\u017eovat za vz\u00e1jemn\u00e9 blokov\u00e1n\u00ed, pokud transakce trv\u00e1 p\u0159\u00edli\u0161 dlouho. Kdy\u017e je vz\u00e1jemn\u00e9 blokov\u00e1n\u00ed nalezeno, jedna z transakc\u00ed se vr\u00e1t\u00ed, co\u017e umo\u017en\u00ed ostatn\u00edm transakc\u00edm, kter\u00e9 se pod\u00edlej\u00ed na vz\u00e1jemn\u00e9m blokov\u00e1n\u00ed, dokon\u010dit. V\u00fdb\u011br ob\u011bti m\u016f\u017ee b\u00fdt zalo\u017een na n\u00e1kladech transakc\u00ed nebo jejich st\u00e1\u0159\u00ed (schemata Wait-Die a Wound-wait). <\/p>\n

Ka\u017ed\u00e9 transakci T<\/b> se p\u0159i\u0159azuje \u010dasov\u00e1 zna\u010dka TS<\/b> obsahuj\u00edc\u00ed \u010das za\u010d\u00e1tku prov\u00e1d\u011bn\u00ed transakce.<\/p>\n

Wait-Die. <\/p>\n

Pokud TS(Ti)<\/b> < TS(Tj)<\/b>, pak Ti<\/b> \u010dek\u00e1, jinak Ti<\/b> se vrac\u00ed a za\u010d\u00edn\u00e1 znovu se stejnou \u010dasovou zna\u010dkou.<\/u><\/p>\n

Pokud mlad\u0161\u00ed transakce zachytila zdroj, a star\u0161\u00ed transakce \u017e\u00e1d\u00e1 o stejn\u00fd zdroj, pak star\u0161\u00ed transakce m\u016f\u017ee \u010dekat. Pokud star\u0161\u00ed transakce zachytila zdroj, pak mlad\u0161\u00ed transakce \u017e\u00e1daj\u00edc\u00ed o tento zdroj bude zru\u0161ena.<\/p>\n

Wound-wait. <\/p>\n

Pokud TS(Ti)<\/b> < TS(Tj)<\/b>, pak Tj<\/b> se vrac\u00ed a za\u010d\u00edn\u00e1 znovu se stejnou \u010dasovou zna\u010dkou, jinak Ti<\/b> \u010dek\u00e1.<\/u><\/p>\n

Pokud mlad\u0161\u00ed transakce zablokuje zdroj a star\u0161\u00ed transakce se pokus\u00ed o tento stejn\u00fd zdroj, mlad\u0161\u00ed transakce bude zru\u0161ena. Pokud star\u0161\u00ed transakce zablokuje zdroj, mlad\u0161\u00ed transakce, kter\u00e1 se pokou\u0161\u00ed o tento zdroj, m\u00e1 povoleno \u010dekat. V\u00fdb\u011br ob\u011bti na z\u00e1klad\u011b st\u00e1\u0159\u00ed zabra\u0148uje vzniku vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed, ale vrac\u00ed transakce, kter\u00e9 nejsou ve stavu vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed. Probl\u00e9m spo\u010d\u00edv\u00e1 v tom, \u017ee transakce mohou b\u00fdt opakovan\u011b ru\u0161eny, proto\u017ee star\u0161\u00ed transakce m\u016f\u017ee dlouho dr\u017eet zdroj.<\/p>\n

Pesimistick\u00e9 \u0159e\u0161en\u00ed probl\u00e9mu vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed neumo\u017e\u0148uje transakc\u00edm zah\u00e1jit prov\u00e1d\u011bn\u00ed, pokud existuje riziko vzniku vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed.<\/h4>\n

\nPro detekci vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed se vytv\u00e1\u0159\u00ed graf (graf \u010dek\u00e1n\u00ed, wait-for-graph), jeho\u017e vrcholy p\u0159edstavuj\u00ed transakce a hrany jsou sm\u011brov\u00e1ny od transakc\u00ed \u010dekaj\u00edc\u00edch na uvoln\u011bn\u00ed dat k transakc\u00edm, kter\u00e9 tato data zabraly. P\u0159edpokl\u00e1d\u00e1 se, \u017ee k vz\u00e1jemn\u00e9mu zablokov\u00e1n\u00ed do\u0161lo, pokud m\u00e1 graf cykly. Vytv\u00e1\u0159en\u00ed grafu \u010dek\u00e1n\u00ed, zejm\u00e9na v distribuovan\u00fdch datab\u00e1z\u00edch, je n\u00e1kladn\u00fd proces.<\/p>\n

Dvouf\u00e1zov\u00e9 zamyk\u00e1n\u00ed \u2013 prevence vz\u00e1jemn\u00e9ho zablokov\u00e1n\u00ed t\u00edm, \u017ee transakce zabere v\u0161echny zdroje vy\u017eadovan\u00e9 na za\u010d\u00e1tku transakce a uvoln\u00ed je na konci.<\/h4>\n

\nV\u0161echny blokuj\u00edc\u00ed operace mus\u00ed p\u0159edch\u00e1zet prvn\u00ed uvol\u0148uj\u00edc\u00ed operaci. M\u00e1 dv\u011b f\u00e1ze \u2013 f\u00e1zi R\u016fst (Growing Phase), b\u011bhem n\u00ed\u017e doch\u00e1z\u00ed k akumulaci z\u00e1mk\u016f, a f\u00e1zi Sn\u00ed\u017een\u00ed (Shrinking Phase), p\u0159i n\u00ed\u017e doch\u00e1z\u00ed k uvol\u0148ov\u00e1n\u00ed z\u00e1mk\u016f. Pokud nelze zabrat n\u011bkter\u00fd ze zdroj\u016f, transakce za\u010d\u00edn\u00e1 znovu. M\u016f\u017ee nastat situace, kdy transakce nebude moci z\u00edskat po\u017eadovan\u00e9 zdroje, nap\u0159\u00edklad pokud n\u011bkolik transakc\u00ed sout\u011b\u017e\u00ed o stejn\u00e9 zdroje.<\/p>\n

Dvouf\u00e1zov\u00fd z\u00e1vazek zaji\u0161\u0165uje proveden\u00ed z\u00e1vazku na v\u0161ech replik\u00e1ch datab\u00e1ze.<\/h4>\n

\nKa\u017ed\u00e1 datab\u00e1ze vlo\u017e\u00ed informace o datech, kter\u00e1 budou zm\u011bn\u011bna, do protokolu a odpov\u00ed koordin\u00e1torovi OK (Voting Phase). Po obdr\u017een\u00ed v\u0161ech odpov\u011bd\u00ed OK koordin\u00e1tor ode\u0161le sign\u00e1l, kter\u00fd zavazuje v\u0161echny prov\u00e9st z\u00e1vazek. Po z\u00e1vazku serveru<\/a> odpov\u00eddaj\u00ed OK, pokud alespo\u0148 jeden neodpov\u00ed OK, koordin\u00e1tor ode\u0161le sign\u00e1l zru\u0161en\u00ed zm\u011bn v\u0161em server\u016fm (Completion Phase).<\/p>\n

Metoda \u010dasov\u00fdch raz\u00edtek<\/h2>\n

<\/p>\n

Star\u0161\u00ed transakce se vrac\u00ed p\u0159i pokusu o p\u0159\u00edstup k dat\u016fm, na kter\u00fdch se pod\u00edl\u00ed mlad\u0161\u00ed transakce.<\/h4>\n

\nKa\u017ed\u00e9 transakci je p\u0159i\u0159azena \u010dasov\u00e1 zna\u010dka TS<\/b> odpov\u00eddaj\u00edc\u00ed \u010dasu zah\u00e1jen\u00ed prov\u00e1d\u011bn\u00ed. Pokud Ti<\/b> je star\u0161\u00ed Tj<\/b>, pak TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Kdy\u017e je transakce zru\u0161ena, je j\u00ed p\u0159i\u0159azena nov\u00e1 \u010dasov\u00e1 zna\u010dka. Ka\u017ed\u00fd datov\u00fd objekt Q<\/b> ozna\u010den\u00fd transakc\u00ed je ozna\u010den dv\u011bma zna\u010dkami. W-TS(Q)<\/b> \u2014 \u010dasov\u00e1 zna\u010dka nejmlad\u0161\u00ed transakce, kter\u00e1 \u00fasp\u011b\u0161n\u011b provedla z\u00e1pis nad Q<\/b>. R-TS(Q)<\/b> \u2014 \u010dasov\u00e1 zna\u010dka nejmlad\u0161\u00ed transakce, kter\u00e1 provedla \u010dten\u00ed z\u00e1pisu nad Q<\/b>.<\/p>\n

Kdy\u017e transakce T<\/b> \u017e\u00e1d\u00e1 o \u010dten\u00ed dat Q<\/b> mohou nastat dv\u011b varianty.<\/p>\n

Pokud TS(T)<\/b> < W-TS(Q)<\/b>, tedy pokud byla data aktualizov\u00e1na mlad\u0161\u00ed transakc\u00ed, pak transakce T<\/b> se zru\u0161\u00ed.<\/u><\/p>\n

Pokud TS(T)<\/b> >= W-TS(Q)<\/b>, pak se \u010dten\u00ed prov\u00e1d\u00ed a R-TS(Q)<\/b> st\u00e1v\u00e1 se MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Kdy\u017e transakce T<\/b> \u017e\u00e1d\u00e1 o zm\u011bnu dat Q<\/b> mohou nastat dv\u011b varianty. <\/p>\n

Pokud TS(T)<\/b> < R-TS(Q)<\/b>, tedy data ji\u017e byla p\u0159e\u010dtena mlad\u0161\u00ed transakc\u00ed a pokud dojde ke zm\u011bn\u011b, vznikne konflikt. Transakce T<\/b> se zru\u0161\u00ed. <\/u><\/p>\n

Pokud TS(T)<\/b> < W-TS(Q)<\/b>, tedy transakce se sna\u017e\u00ed p\u0159epsat nov\u011bj\u0161\u00ed hodnotu, transakce T se ru\u0161\u00ed. V ostatn\u00edch p\u0159\u00edpadech se zm\u011bna provede a W-TS(Q)<\/b> st\u00e1v\u00e1 se rovno TS(T)<\/b>.<\/u><\/p>\n

Nen\u00ed nutn\u00e1 n\u00e1kladn\u00e1 konstrukce grafu \u010dek\u00e1n\u00ed. Star\u0161\u00ed transakce z\u00e1vis\u00ed na nov\u011bj\u0161\u00edch, tak\u017ee v grafu \u010dek\u00e1n\u00ed nejsou cykly. Nejsou vz\u00e1jemn\u00e9 blokace, proto\u017ee transakce ne\u010dekaj\u00ed, ale ihned se ru\u0161\u00ed. Mohou nastat kask\u00e1dov\u00e9 ru\u0161en\u00ed. Pokud Ti<\/b> se zru\u0161ila, a Tj<\/b> p\u0159e\u010detla data, kter\u00e1 zm\u011bnila Ti<\/b>, pak Tj<\/b> tak\u00e9 mus\u00ed b\u00fdt zru\u0161ena. Pokud byla v t\u00e9to dob\u011b Tj<\/b> ji\u017e zkomitov\u00e1na, dojde k poru\u0161en\u00ed principu udr\u017eitelnosti.<\/p>\n

Jedn\u00edm z \u0159e\u0161en\u00ed kask\u00e1dov\u00fdch ru\u0161en\u00ed. Transakce prov\u00e1d\u00ed v\u0161echny operace z\u00e1pisu na konci, p\u0159i\u010dem\u017e ostatn\u00ed transakce mus\u00ed po\u010dkat na dokon\u010den\u00ed t\u00e9to operace. Transakce \u010dekaj\u00ed na potvrzen\u00ed p\u0159ed \u010dten\u00edm.<\/p>\n

Thomasovo pravidlo z\u00e1pisu \u2014 variace metody \u010dasov\u00fdch zna\u010dek, p\u0159i kter\u00e9 je zak\u00e1z\u00e1no p\u0159episovat data aktualizovan\u00e1 mlad\u0161\u00ed transakc\u00ed star\u0161\u00edmi<\/h4>\n

\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30878","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Transakce a mechanismy jejich kontroly | ProHoster","description":"Transakce Transakc\u00ed se rozum\u00ed sekvence operac\u00ed nad daty, kter\u00e1 m\u00e1 za\u010d\u00e1tek a konec. Transakce je sekven\u010dn\u00ed prov\u00e1d\u011bn\u00ed operac\u00ed \u010dten\u00ed a z\u00e1pisu.","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0438 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0438\u0445 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f | ProHoster","og:description":"\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438.","og:url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:56+00:00","article:modified_time":"2019-10-31T18:37:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:38","updated":"2026-02-22 15:31:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransakce T<\/b> \u017e\u00e1d\u00e1 o zm\u011bnu dat Q<\/b>. Pokud TS(T)<\/b> < W-TS(Q)<\/b>, tedy transakce se sna\u017e\u00ed p\u0159epsat nov\u011bj\u0161\u00ed hodnotu, transakce T se neanuluje jako v metod\u011b \u010dasov\u00fdch zna\u010dek.
\n
Zdroj: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"