Please enable JavaScript.
Coggle requires JavaScript to display documents.
Tranzakciók adatbázis-kezelő rendszerekben, * - Coggle Diagram
Tranzakciók adatbázis-kezelő rendszerekben
mese
egy adatbázis kezelő rendszer egyetlen felhasználó egyetlen programját szolgálja ki egy időben
egy felhasználó/1CPU/1 háttértár
milyen nehézségek merülnek fel, ha több felhasználó v program egyidejúleg kerül kiszolgálásra a DBMS által
mi van ha nem elég
gyors? - mo: ph
robosztus: nem elég ellenálló(nem lehet elbusztítani) -mo : elosztott
védett? - def: security módszerek
hatékony? : adott mennyiségű erőforrással nem elég gyorsan - mo: kifinomultabb alg
Bevezetés
tranzakció
ahhoz, hogy egy tranzakció egy DBMS konkurens környezetben is értelmezhető legyen, hagyományosan további tul, ill ezek közül minél több teljesülését elvárjuk
ACID tulajdonságok:
atomicitás
konzisztencia
: csak sikeresen(teljes egészben) lefutott tranzakcióknak van hatása az adatbázis tartalmára, ekkor a tranzakciók az adatbázist egyik konzisztens állapotból egy másikba viszik át
izoláció
, másnéven elszigetelés: minden tranzakció úgy fut le, mintha közben más tranzakció nem futna
tartósság
: ha egy tranzakció már sikeresen lefutott, akkor annak hatása ,,nem veszhet el"
db-kezelő tranzakciókezelés megvalósítása arról szól, hogy milyen feltételek mellett, milyen módszerekkel, milyen hatákonyan lehet az ACID tul. biztosítani
a tranzakciók elemi lépésekból állnak: írás/ olvasás + kiegészítő lépések: ezek szintén nem oszhatók
ütemezés
Problémák a tranzakciókkal
idő előtti befejeződés
nullával osztás/illegal művelet
nem fér hozzá adathoz
kívülről lövik ki
konkurens rendszerekben a tranzakciók műveletei összefésülődhetnek, mert a tranzakció általában nem tud befejeződni, mielőtt az db-kezelőnek el kell kezdenie egy másik tranzakciót kiszolgálni, vagy folytatnia egy másik tranzakció kiszolgálát
a tranzakciók egymásba fésülése csak akkor probléma, ha közös erőforráshoz akarnak hozzáférni
itt ezek csak az adatok lesznek
Ütemezések
ha a tranzakciók egy rendszerben szigorúan egymás után futnak le, úgy hogy egyidejűleg csak egyetlen tranzakció fut, tehát nem lapolódnak át, akkor ez egy:
soros ütemezés
mindig megvalósítható probléma mentesen
amennyiben a tranzakciók külön-külön megvalósthatók
izolációjuk természetes módon telj.
egyebek neve: nem soros ütemezés
megvalósulhat egyetlen CPUN v többön
sorosíthatók
/
nem sorosíthatók
nem soros ütemezésnél a tranzakciók egymásba fésülése: problémák
Piszkos olvasás
egy T2 tranzakció egy ún
piszkos
adatot olvas, melyet egy másik, T1 TA, azelőtt írt az adatbázisba, hogy befejöződött volna.
ha a T1 tranzakció végül sikertelennek bizonyul, akkor a piszkos adat minél hamarabb eltávolítandó
Elveszett módosítás
több tranzakció ugyanazon az adategységen végez módosításokat úgy, hogy egy T1 tranzakció felülírja a másik T2 által végezz műveletek eredményét
Nem megismételhető olvasás
egy T1 tranzakció különböző eredményeket kap egy adategység többszöri olvasásáakor, mert egy másik T2 TA időközben módosította azt
Fantom olvasás
egy T1 tranzakció többször is végrehajtja ua a lekérdezést, miközben egy másik T2 tranzakció olyan rekordokat szúr be vagy töröl, melyek kielégítik T1 lekérdezésének szelekciós feltételét
más rekordhalmazt adhat vissza
a fentiek elkerülése, ill a kapcsolódó prob megoldása a tranzakciókezelés egyik központi kérdése
mo egyesével?
de a soros ütemezéseknél ezek fel sem merülnek
izolációs elv
ha tehát nem lehet egy soros ütemezésnél biztosítani, hogy ua az eredményt produkálja, mintha a TA valamely sorrendben egymás után futtatnánk le, akkor az ütemezést nem tekintjük korrektnek
korrekt
a sorosíthatóság számos módszerrel és feltétel mellett biztosítható
ált az adathozzáférés alkalmaz módjának korlátozása jelenti a problémát
az adathozzáférés:
módjának szabályozása pl zárakkal és/v időbélyegekkel történhet
egységeinek megválasztása kritkus rendszertechnikai kérdés
Megjegyzések
1
a definíció alapján nehéz eldönteni, hogy egy ütemezés sorosítható-e, hiszen elvileg minden TA minden adategységét meg kell vizzsgálni: k TA esetén k! opció
2
kissebb hibát vétünk, ha egy sorosítható ütemezést nem sorosíthatónak minősítünk, mint fordítva
3
a sorosíthatóság kérdését a gyakorlatban folyamatosan kell tudni megítélni, minden egyes adathozzáférési igény kapcsán
4
tipikus gyakorlati mo: olyan szabályok megalkotása, amelyeknek a betartása garantálja a sorosíthatóságot
az ütemező bonyolultsága jelentősen függ az alkalmazott protokolltól
zárkeseléssen alapuló tranzakció menedzsment esetén szorosan együttműködik a zármenedszerrel
a zármenedzser kezeli a zártábázatot, mely az alábbi szerkezetű bejegyzéseket tart:
⟨adategység⟩⟨zártípus⟩⟨tranzakció⟩
Tranzakciókezelés zárakkal
zár
helyezzünk el el zárakat adatmódosító műveletek előtt
{LOCK A ... UNLOCK A} műveletek között más tranzakció csak korlátozottan v sehogy sem fér hozzá A adategységéghez
a zárak szinkronizációs primitívként is szolgálnak
ha egy tranzakció lockolni akar egy adategységet, amin egy másik tranzakció tart fenn zárat, akkor addig nem mehet tovább, amíg a zár fel nem szabadul
legális ütemezés
Problémák a zárakkal
Ha egy Tm tranzakció azért nem tud továbblépni, mert egy olyan adategység felszabadítására vár, amin egy olyan Tn/=Tm tranzakció tart fenn zárat, ami viszont azért nem tud továbbépni és felszabadítani, mert ehhez olyan adategységhez kellene hozzáférnie, amint már Tm tart fenn zárat akkor
pattról/ holtpontról
beszélünk
patt elképzelhető kettőnél több TA részvételével is
Megoldási lehetőségek
a tranzakciók lockoljanak mindent egyszerre, amire a futásukhoz szükségük lehet, ha valamely zárat nem kaphatják meg, akkor ne is próbálkozzanak egyetlen művelet elvégzésével sem
ha a TA túl sokáig várakozik, akkor valószínűsíthető, hogy pazz helyzetbe került, ezért abortálandó
vmilyen egyértelmű sorrendet rendeljünk az adategységekhez és zárat csak ennek a sorrendjében lehessen kérni
folyamatosan monitorozzuk a zárak elhelyezését, és ha pattot érzékelünk, akkor valamilyen tranzakciót, amely a pattot okozza, kilőjük
Ez utóbbihoz szükségünk van egy eljárásra, amivel érzkeljük a patthelyzetet:
várakozási gráf
rajzolása
nem a patt az egyetlen lehetőség, hogy egy akár legális ütemezésben szereplő tranzakció ne tudjon lefutni
ha egy tranzakció egy adategység lockolására vár, de közben más tranzakciók mindig lockolják előtte a kérdéses adategységet, akkor éhezésről beszélünk
egy lehetőség az éhezés elkerülésére, ha feljegyezzük a sikertelen zárkéréseket, és ha egy adategység felszabadul, akkor a zárat csak a zárkérések sorrendjében ítéljük oda
Tranzakció modellek
a szabáylos tranzakciókat jellemző tulajdonságok gyűjteménye
egyszerű TA modell
adott adatelemen zár elhelyezésének követelménye, hogy a LOCK...UNLOCK műveletek között más tranzakció az adott adathoz semmilyen módon nem férhez hozzá
ugyanakkor feltételezzük, hogy a zárat elhelyezeő TA az adatelemet írja és olvasta is
egy adott ütemezés sorosíthatósága eldönthető a
sorosítási gráf
segítségével
a def háttere, hogy amikor élt rajzolunk a Ti csomópontból Tj csomópon felé, akkor a Tj TA az aA adategységnek olyan értékét olvassa, amit Ti hozott létre
tehát Ti meg kell, hogy előzze Tj-t az ütemezés minden soros ekvivalensében, ezt fejez ki a nyíl
a sorosítási gráf segítségével tehát a sorosíthatóság eldöntése visszavezethető a kör keresésére egy irányított gráfban
minden zárkérés előtt elvégezendő
így az egyidejűleg futó TA és az általuk közösen használt adatelemek számának fg-ben lassulhat az ütemező működése
gyakorlatba elterjedtebb: az ütemezésben található minden TA egy adott protokollt követ, amely protokoll mellett a sorosíthatóság v automatikusan tel, v egyszerű módszerekkel biztosítható
Kétfázisú zárolás(2PL)
kétfázisú zárolás
a tranzakció az első fázisban zárat kér
másodikban felszabadít
Tétel
zárpont
Megjegyzések
1
ha vmely ütemezés tartalmaz egyetlen nem kétfázisú tranzakciót(T1) is, akkor létezik olyan T2, amellyek együtt az ütemezés már nem sorosítható
2
A 2PL protokollt követőtranzakciók esetén a kapcsolódó ütemezp olyan egyszerű lehet, hogy emiatt gyakorlatban igen gyakran alkalmazzák
folyt
RLOCK-WLOCK modell
azt várjuk, hogy kevesebb legyen a várakozás, több TA is képessé válik egy időben ua adategységet olvasni
hasonlóan az egyszerű TA modellhez itt is lehetőség van sorosítási gráf seg.vel eldönteni, egy ütemezés sorosíthatóságát
a hatékonyságnövekedést az okozza, hogy REAd...READ szekvenciák mellett nem kell élet hútni Ti Tj közé
Az At csak olvasó TA sorrendje sorosíthatóság szempontjából tehát mellékes, ha mindegyik a legutóbbi At író tranzakció után és első, őt követő, A-t író TA előtt következik a soros ekvivalensben
Tétel
RL-WL kétfázisú
Tétel
további zármódok is definiálhatók
ettől akkor várhatunk el hatákonyságnövekedést, ha az értelmezett zármódok között minél több olyan van, amely egy adategységen egyidejűleg tartható fenn, azaz összeférhetők, komptaibilisek
ezt zárkompatibilis mátrixban szokás ábrázolni
inkrementális zár
hi ismerjük az alk zárak kompatibilitási mátrixát, akkor fel tudjuk rajzolni a sorosítási gráfot
Zárak hierarchikus adategységeken
eddig a zárkezelési mechanizmusok tökéletesen függetlenek voltak attól, hogy az adategységek milyen struktúrába szervezett, ill szervezettek-e egyáltalán
ennek a járulákos inf felhasználásával a zárkezelés hatékonysága tovább növelhető
kitüntetett a szerepe ha ezek vmilyen hierarchiába vannak szervezve
hiearchikus adatbázis rekodjai
B*-fa elemei
egymásba ágyazott adatelemek: ezek közül a legfontosabb a relációs adatbázis-reláció-blokk-tuple hiearchia
kihasználva a hierarchikus szerkezetet, lehetőség van arra, hogy egy adategység zárolása esetén minden, a hierarchiában alacsonyabban levő adategységet is egyidejűleg zároljuk
pl: relációa db.nál, ha egy tábla minden sorát zárolni kell, soronként költséges, de mo: a táblára helyezett zárral
B*-fánál ez nem igen célravezetp
jó példa: fa protokoll
előbbi: figyelmeztető protokoll
A faprotokoll
egyszerű tranzakció modellt követjük és egy csp zárolása nem jelenti a gyerekek záolását is
Szabályai:
egy trazakció az első LOCK-ot akárhová teheti
további LOCK-ok csak akkor helyezhetőek el, ha az adategység szülőjére ugyanaz a tranzakció már rakott zárat
egyazon tranzakció kétszer ugyanazt az adategységet nem zárolhatja
vegyük észre, hogy az ULOCK-ra nincs előírás, aminek a következménye, hogy a fa prtokoll nem feltétlenül kétfázisú
ez a szekvencia a valóságban is gyakran előfordul, amikor egy TA beszúrás műveletet hajt végre egy B-fán
ha B egy olyan csp, amiben van hely egy újabb indexrekord számára, akkor a fa átstruktúrálodás a beszúrás következtében a B csp őseit már nem érinti
így a rajtuk levő zár felszabadítható, lehetővé téve, hogy más TA zárolja a C csp.hoz tartózó részfát
tétel
A figyelmeztető protokoll
egyszer TA modellt követjük
de csp zárolása minden leszármazott zárolását is jelenti
azt is eredményezi, hogy 2 TA egy idejűleg tart fenn zárat ua az adategységen
ennek a neve:
zárkonfliktus
szabályok betartásával kell elkerülni
zárműveletei:
LOCK A:zárolja At és az összes leszármazott csp, 2 különböző tranzakció nem tarthat fenn zárat egyidejűleg ua adategységen
WARN A. A ra figyelmeztetést rak. Ekkor At más TA nem zárolhatja
UNLOCK A: eltácolítja a zárat v az UNLOCK által elhelyezett ifgyelmeztetést A-ról
Szabályok: mint az egyszerű TA modellben +
egy TA első művelete kötelezően LOCK gyökér v WARN gyökér
LOCK A vWARNA akkor helyezhető el, ha A szülőjén ua a tranzakció már helyezett el WARN-t
UNLOCK A akkor lehetséges, ha A gyerekein már ua a tranzakció nem tart fen sem LOCK ot, sem WARN-t
kétfázisú: az első UNLOCK után következhet LOCK vagy WARN
Tranzakcióhibák kezelése
eddig nem foglalkoztunk azokkal a problémákkal, amik akkor lépnek fel, ha egy Ta nem fut le tlejesen
okok:
tranzakció fébeszakad: 0val o, nem fér hozzá
az ütemező patt miatt kilövi
az ütemező azért lövi ki, mert a sorosíthatóság így biztosítható
vmilyen rendszerhiba lép fel, emiatt hibásan kezd el működni
a háttértát tartalma megsérül
1-3 a mem és a háttértár érintetlen
rendszerhibáról beszélünk akkor is, ha az operatív tár tartalma sérül
egyre nehezebb: néha csak a biztonsági másolat segít
1-3
konzisztens állapot
automatikusan nem megvalósulható
olyan módszerek, amelyek az egyes TA ezt a tulajdonságát biztosítják
készpont
a tranzakció inden számítást elvégeztt és minden zárat megkapott
nem feltételnül azonos azzal, amikor minden eredmény már véglegeítve lett
ehhez további műv is szükségesek lehetnek
ha nem jutott el eddig-> abort, majd minden lehetséges hatását törlni kell
pszkos adat
minél hamarabb eltávolítandó
de egy másik már olvasta, ami lefutott
ez nem tekinthető helyesnek
iteráltan is előforudulhat: lavina
sok járulékos költéget eredményez
Kezelése:
nem commitált TAtól nem olvasunk
ha megengedjük, akkor minden piszkos értéket olvasott TA hatása törlendő az adatbázisból
lehetetlenné tesszük, hogy a TA piszkos adatot olvasson
Szigorú kétfázisú protokoll
egy TA ezt a protokollt követi, ha kétfázisú, továbbá:
nem ír az adatbázisba, amíg a készpontját el nem érte
a zárait csak az adatbázisba írás után engedi el
az az a COMMIT, adatbázisba írás, zárak elengedése pontosan ebben a sorrendben következik
az 1 szabály ahhoz kell, hogy ne kelljen az adatbázist helyreállítani, ha egy TA abortált
A 2 szabály biztosítja valójában azt, hogy piszkos adatot ne lehessen olvasni, tehát a lavinákat elkerüljük
ez csak akkor igaz, ha nem kell rendszerhibákkal is számolni, amig az írás folyamatot megzavarva piszkos adatok db-ba kerülését eredményezik
tétel
Agresszív és konzervatív prokoll
a szigorú kétfázisú prtokollok is valójában egy családo alkotnak, mivel számos alternatíva létezik még, amely az ütemezésekre hatással lehet
ezen alternatívák elsősorban annak alapján értékelhetők, hogy mennyire segítik a db-K rendszerk hatékony konkurens működését
Hatékonyság mércéje:
egy adott TA minél hamarabb fusson le
adott idő alatt minél több TA fusson le
ezen kritériumok ellentmondásosak, adott esetben mindkettő lehet fontosabb a másiknál
gyakran a Ta teljesítményét kívánjuk maximalizálni az ütemező alkalmas megválasztásával
Hogyan bef ezek a Takciós teljesítményt?
számos műveletet igényel a zártáblák kezelése, a zárakra várakozó sorok karbantartása, pattok érzékelése és feloldása, annak eldöntése, hogy a zár odaítélhető-e v sem
A később abortált TA által végzett műveletek mind kárbavesznek, csakúgy, mint az általuk igényelt és fel nem oldott zárak felkutatása és felszabídítása
nem szigorú 2PL esetén az DB helyreállítása, a lavinaeffektus felszámolása szintén csökkenti a Takciós teljesítményt
agresszív protkolll
konzervatív protokoll
Váalsztási szempont:
ha kevés a TA által közösen használt adat, akkor kicsi a nem sorosítható ütemezés, patt és éhezés veszélye: agresszív protokoll hatákonyabb
Nagyon konzervatív
szigorú 2PL
az összes zárat előre elkéri és csak akkor indul, ha már az összeset megkapta
csak akkor kap meg egy zárat, ha az előtte senkinek nem kell az adatelmhez tartozó várakozó sorban
1 miatt sorosítható és lavinamentes, 2 miatt patt mentes, 3 éheztetés mentes
Ára:
2 és 3 miatt nagy lehet a késleltetés, amíg egyáltalán elinduk
2 és 1 miatt más TA is szükségtelenül késletet
2 miatt előre ismerni kell minden zárat
Nagyon agresszív
zárakat közvetlenül írás v olvasás előtt kéri
amennyiben a zárakat csak azután engedi el, hogy mindet megkapta, akkor egyszerűen sorosítható
egyébként a sorosíthatóság biztosítása is is külön probléma
patt és éheztetés lehetséges
a TA gyorsan lefutnak és a többi TA kevéssé fogják vissza
Helyreállítás rendszerhibák és médiahibák után
operatv tár sérül, a háttértár nem
eddig csak arról volt szó, hogy mi a teendő, ha egyes TA aborttal fejezik be a futásukat
4-5 hibák
a rendszerhibák elleni védekezés általános módszere a naplózás
számos mód
napló
általában az alábbi szerk rekordokat tart:
(⟨tranzakció azonosító⟩, begin)
(⟨tranzakció azonosító⟩, commit)
(⟨tranzakció azonosító⟩, abort)
(⟨tranzakció azonosító⟩,⟨adategység⟩,⟨új érték⟩,⟨régi érték⟩)
ha tudható, hogy undo műveleteket nem kell an apló alapján végezni, akkor elég az adategység új értékének naplózása
néha ez is nagy: az kerül a naplóba, hogy hogyan kell az új értéket előállítani
alapszabáky
: a naplót azelőtt írjuk, hogy a műveletre sor kerülne(kivétel abort)
Hatékonysági kérdések
a helyreállítás képességének igénye miatt a napló a stabil tárban tárolnadó
ennek költsége a háttértárra írt naplóblokkok számával arányos
gyakorltban vmilyen lapozási stratégiávaé kezelik
számos naplóoldal lehet, egyidejűleg a memóriában és egy lapmenedzser gondoskodik a háttértárra kiírásról, meghatározott stratégia és feltételek szerint
ue igaz az adatbázis blokkokra is
ha változtatunk az adatbázisunkon, a változás elveszhet egy rendszerösszeomlás esetén, ha a naplót v a megváltozott DB oldalakat nem írjuk ki a stabil tárba
hatékonyabb, ha a naplót írjuk, mert a napló tömörebben tartalmazza a változtatásokat, mint maguk az adatbázis oldalak
ekkor kevesebb blokkműveletet kell végeznünk
szabály, hogy egy TA vége után a napló akkor is kiirandó a háttértárra, ha a lapozási stratégia ezt még nem követelné meg
ez által válik a TA tartósan végrehajtottá
a DB oldalakat lehet a naplótól függetlenül is, egy másik lapozási stratégia szerint cserélni
A redo protokoll
nevét onnan kapta, hogy olyan TA kezelést valósít meg, amely a rendszerhiba után szükségtelenné teszi az undo műveletet, csak redo kell
A prokotoll két része a redo naplózés és a redo helyreállítás
A redo naplózás
a redo naplózás szigorú 2PL finomátása
Lépései
(T, begin) naplóba,
(T, A, ⟨A új értéke⟩) naplóba, ha T megváltoztatja valamely A adategység
értékét,
(T, commit) naplóba, ha T elérte a commit pontját,
a napló mindazon oldalainak stabil tárba írása, amikkel ez még nem történt
meg,
az A értékeknek a tényleges írása az adatbázisba (operatív tárba),
a piszkos DB blokkok diszkre írása egyéb szempontok szerint
zárak elengedése.
Megjegyzések
1
az a TA lett véglegesítve, amelyik eljutott a 4. pont végéig, hiszen a napló alapján az DB-on végzett műveletei már bármikor megismételhetők
a 4. pont végégig el nem jutott TA hatása, pedig részben vagy egészben elveszhet
2
az 5. pontban az adatbázisoldalak írásához az érintett blokkokat be kell hozni a memóriába, az írást elvégezni, de a megváltozott oldalak azonnali visszaírása a mem-ba már opcionális
3
a 7 pont után férnek hozzá csak más TAk A T által megváltoztatott adatokhoz, így nincs lavinaeffektus sem
A redo helyreállítása
az adatbázist egy konzisztens állapotba viszi át a helyreállítás végére
lépései:
az összes zár felszabadítása,
napló vizsgálata visszafelé: feljegyezzük azon tranzakciókat, amelyekre találunk (T, commit) bejegyzést
addig megyünk visszafelé a naplóban, ameddig nem találunk egy konzisztens
állapotot (ld. később),
a 2. pontnak megfelelő tranzakciókra vonatkozó bejegyzések segítségével az
adatbázisban található értékeket felülírjuk az újakkal
a redo helyreáll ederményeként a 2. pontnak megfelelő tranzakciók hatása megmarad a többi elvész, és az DB egy új konzisztens állapotba kerül
ha a redo helyreállítás elszáll, akkor egyszerűen megismételendő, hiszen a 4. pontban végzett műveletek hatása az adatbázisra idempotens
Ellenőrzési pontok
a redo helyreállításnál könnyen előfordulhat, hogy igen régi időpontra kell a naplóban visszafelé menni ahhoz, hogy alkalmas időpontot találjunk a helyreáll megkezdsére
ezt segítik az ell pontok, amik kikényszerítik az DB-nak egy konzisztens állapotát
ideiglenesen megtiltjuk új TA indítását és megvárjuk, amíg minden TA befejeződik v abortál
megkeressük azokat a memóriablokkokat, amelyek módosultak, de még nem kerültek a háttértába kiírásra
ezeket a blokkokat visszaírjuk a háttértárra
ellenőrzési pont tényét naplózzuk
naplót kiírjuk a háttértárra
Előnyök:
redo helyreállításnál csak a legutóbbi ell pontig kell a naplóban visszamenni
emiatt a naplü korábbi részei eldobhatók
csökkenti a lavinák számát
Hátrányok
csökkenti a TA teljesítményt
Ütemezése:
adott idő eltelte után
adott számú TA lefutása után
kombinálva az előző kettőt
Mivel az ell pontokra elsősorban a helyreállításkor van szükség ez pedig ritka események számít, ezért ell pontokat is viszonylag ritkán iktatnak be
Köv: a helyre áll tovább tart
Médiahibák elleni védekezés
Megoldások:
rendszeres mentések, modern dbK rendszereket úgy hajtják végre, hogy egy pillanatnyi üzemszünetet sem okoz
az adatbázis fájlok duplikálása lehetőleg egy másik fizikai eszközön, néha más fölsrajzi helyen
érdemes a napló fájlokat is védeni: jó gyakorlat, ha az adatbázis és a napló más fizikai eszközön található, szóba jön itt is a duplikálás
Időbélyeges tranzakciókezelés
sorosíthatóság biztosításának másik módja
akkor praktikus, ha a TA között kevés a potenciális sorosítási konfliktus
az időbélyeges TA kezelés során az adategységekhez egy járulékos adatot rendelünk hozzá(időbélyeg)
segítségével eldönthető, hogy egy TA adott adategységre vonatkozó kérése sérti-e a sorosíthatóságot
ha igen a TA abortálni kell, így alapvetően ez egy agresszív protokoll
időbélyeg
figyelembe véve, hogy
az időbélyegek a TAnak egy egyértlemű sorrendjét határozzák meg
képzelhetjük úgy, mintha a TA a kezdőidejükben zérus idő alatt futnának le
a kezdőidők novekvő sorrendjébe állítva a TA-kat ez lehet egy soros ekvivalens ütemezés
ha az időbélyeges ütemező tehát gondosodik arról, hogy csak olyan műveleteket engedélyezzen, amelyek hatása a TA növekvő időbélyegei által meghatározott soros ütemezés hatásaival egyezik meg, akkor a TA indulási sorrendje valóban egy soros ekvivalens ütemezés
megjegyzés
: érdemes összehasonlítani: soros ekvivalens ütemezés kétfázisú zárkezeléssel: a zárpontok szerinti növekvő sorrend az soros ekvivalens. Soros ekvivalens ütemezés időbélyegesen:a t(Ti1 ) < t(Ti2 ) < . . . < t(Tin )-nek megfe lelő Ti1 , Ti2 , . . . , Tin a soros ekvivalens.
az időbélyeges kiosztása az egyértelműség kritikus
egyprocesszoros környezetben a TA indulásakor a rendszeróra által mutatott érték jó alap az időbélyeg meghatározásához
többprocesszoros környezetben ehhez még a processzor azonosítója is hozzáveendő
A sorosítás feltételek megsértése többféle modell alapján is detektálható
Itt is létezik
egyszerű modell
read/write modell
további műveletek is megkülönböztethetőek
Időbélyeges tranzakciókezelés R/W modellben
olvasási és írási idő
az alábbi alapján eldönthető, hogy egy TA műveleti igénye az A adategységre vonatkozóan engedélyezhető-e vagy sem, azaz az időebélyeges soros ekvivalensnek megfelel-e.
Az időbélyeges R/W modell és a 2PL összehasonlítása
elképzelhető, hogy egy ötemezés sorosítható
időbélyegesen, de kétfázisú zárakkal nem
időbélyegesen is és zárakkal is
kétfázisú zárakkal, de időbélyegesen nem
időbélyegesen és zárakkal sem
Időbélyegek kezelése
zár alapú TAkezelésnél praktikus megközelítés, ha
külön tároljuk a zárinformációt az adategységektől és
feltételezzük, hogy az adategységek alapértelmezett állapotba ,,nem zárolt"
tehát a zártáblában csak azokról az adategységekről tárolunk információt, amelyeken van zár
analóg módon: időbélyeges esetben az adategységek alapértelmezett időbélyege lehet -végtelen és csak az ettől eltérő értéket kell explicit módon tárolni
ezek az értékek megjelenhetnek közösen egy időbélyegtáblán, ami lehetőség szerint a mem tárolandó
a tábla nem nő a végtelenségig, mert a táblából kitörölhetők azok az időbélyegek, amelyek kisebbek, mint a futó TA legkisebb időbélyegének értéke
*