Adatbázis Rendszerek II. 10. Tranzakció kezelés 72/1B IT MAN

Átírás

1 Adatbázis Rendszerek II. 10. Tranzakció kezelés 72/1B IT MAN B IT v: MAN

2 Párhuzamosság Hasznos és kényelmes a felhasználó oldaláról Kihívás problémák a konkurens végrehajtásnál konfliktus helyzetek (azonos erőforrás igény) Megoldások: várakoztatás várakozó sorok (nyomtató) adatbázis-kezelésben egyedi vonások DB 72/2 B IT MAN

3 Tranzakció fogalma Logikailag összetartozó, egységként kezelt műveletsor. Az adatbázis-kezelés központi fogalma Minden műveletsor tranzakcióba szervezetten hajtódik végre A DBMS nem engedi tranzakción kívüli művelet végrehajtását Pl.: Az A számláról átutalunk 50 egységet a B számlára BEGIN READ(A) A:=A - 50 WRITE(A) READ(B) B:=B + 50 WRITE(B) END 72/3 B IT MAN

4 Tranzakció fogalma A tranzakció az adatbázisműveletek egy olyan csoportja, amelyek vagy mindegyike érvényre jut (commit) vagy közülük egyik sem (abort). A műveletek a mindent vagy semmit elv szerint hajtódnak végre. A tranzakcióknak úgy kell végrehajtódniuk, hogy megfeleljenek az adatbáziskezelés sajátosságainak, ezek az ACID elvek. login DML abort commit logout begin transaction insert delete update end transaction 72/4 B IT MAN

5 ACID elvek Atomicity Atomi Consistency Konzisztens Isolation Izolált Durability Tartós 72/5 B IT MAN

6 ACID elvek Atomicity Consistency Isolation Durability Atomiság Konzisztencia Izoláció Tartósság Atomi, vagyis a tranzakció minden művelete végrehajtódik, vagy egy sem. Konzisztens*, vagyis konzisztens állapotból konzisztens állapotba visz. Izolált, vagyis az eredmény ne függjön más párhuzamosan futó tranzakciók hatásától. Tartós, vagyis a véglegesített tranzakció hatása már nem szüntethető meg. *Konzisztens: belső ellentmondásoktól mentes, egységes, következetes. 72/6 B IT MAN

7 Atomiság Atomiság Az adatbázisban a műveletek nem izoláltak, nem egyediek, hanem kapcsolat van közöttük A felhasználó rendszerint műveletsort akar végrehajtani, nem egyedi műveletet Külön-külön nincs értelmük a műveleteknek, illetve hibához, ellentmondáshoz vezethetnek Pl. készpénzfelvétel automatából pinkód beírás -> ellenőrzés művelet megadás -> készpénz beállítás hitelkeret ellenőrzés -> készpénz levétele a számláról készpénz ellenőrzése az automatában -> pénz kiadása A DBMS-nek képesnek kell lennie a műveletek visszagörgetésre. Félig elvégzett műveletsor nem maradhat a rendszerben. 72/7 B IT MAN

8 Konzisztencia Konzisztencia Minden felhasználó számára konzisztens kell legyen (egységes, ellentmondás mentes) Konzisztens állapotból konzisztens állapotba vigyen Integritás őrzés pl. OKéztuk az összeget, de nem adja ki az automata Integritás sértő műveletek megakadályozása pl. életkor mezbe 3012 kerül 72/8 B IT MAN

9 Izoláció Izoláció A felhasználó a párhuzamosság káros mellékhatásaiból minél kevesebbet érezzen Legjobb, ha a felhasználó úgy érzi, hogy egyedül dolgozik a rendszerben Munkájának eredménye csak a kiinduló állapottól függjön, ne az egyéb tevékenységektől 72/9 B IT MAN

10 Tartósság Tartósság Műveletsor sikeres végrehajtása esetén a felhasználó visszajelzést kap Biztos lehet abban, hogy a műveletsor hatása véglegesen beíródott az adatbázisba Későbbi művelet nem törölheti vissza A lezárt tranzakciók eredményeit az adatbázis-kezelő mindenáron őrizze meg Gondoskodjon a véglegesített adatok elvesztése elleni védelemről 72/10 B IT MAN

11 Tranzakciók leírása Műveletsort kell megadni. A műveletsorok elemei: Műveletek: olvasás: r, (select) írás: w, (insert, update) r(x) w(x) objektum, amelyre hatnak paraméterként: r(x), w(x) x: megadott táblában egy megadott mező tranzakció lezárása véglegesítés (commit): c visszagörgetés (abort): a c a Azonosítás: számokkal. Pl: r1(x) az 1-es tranzakció olvas Sorrendiség: nyilak. megelőzési reláció: m1 -> m2 r1(x) w2(x) 72/11 B IT MAN

12 Tranzakciók ábrázolása Ábrázolás gráffal: Csomópontok a műveletek, irányított élei a megelőzési relációk Kötöttségek érvényes tranzakció esetén: Tartalmaznia kell egy lezárási műveletet (c,a) Pontosan csak az egyiküket tartalmazhatja A lezárási művelet az utolsó, az összes többi megelőzi Egyértelmű végrehajthatósági feltétel: A műveletsor eredménye azonos kezdőfeltételek mellet mindig egyezzen meg a leírt tranzakció eredményével 72/12 B IT MAN

13 Tranzakció ábrázolása Az SQL parancsok: SELECT FIZ FROM DOLGOZO; SELECT * FROM UZEM; UPDATE DOLGOZO SET FIZ=0; COMMIT; A tranzakció: r(d(fiz)) r(u(*)) w(d(fiz)) c Általánosságban: r(x) r(y) w(x) c 72/13 B IT MAN

14 Tranzakciók ábrázolása 2. w1(x) w2(x) c r(x) w1(x) = 3 w2(x) = 5 A sorrend nagyon fontos! w1(x) -> w2(x) =/= w2(x) -> w1(x) 72/14 B IT MAN

15 Tranzakciók jellemzése Bármely két művelet között létezzen megelőzési reláció: Egyértelmű, de nem szükséges minden esetben Általában csak a tranzakció eredménye a fontos A közbenső állapotok érdektelenek Több út is adhatja ugyanazt az eredményt Ekkor a rendszer bármelyiket választhatja 72/15 B IT MAN

16 Tranzakciók ábrázolása 3. r(x) w(x) c r(y) w(y) c r(x) -> w(x) -> r(y) -> w(y) == r(y) -> r(x) -> w(x) -> w(y) Kérdés: mely elemek közötti relációk (nem) hagyhatók el? Válasz: amelyek sorrendje fontos a végeredmény szempontjából Konfliktusban álló műveletpárok 72/16 B IT MAN

17 Konfliktusban álló műveletek A sorrendiség kihat az eredményre! Konfliktus esetén: azonos objektumnak kell szerepelnie mindkét műveletben különböző objektumokhoz való hozzáférés nincs hatással egymásra legalább az egyik írási művelet az olvasások nem módosítják az adatbázist, bármikor felcserélhető a sorrendjük írási műveletek időbeli pozíciója lényeges r(x) w(x) c r(x) w(x) c 72/17 B IT MAN

18 Konfliktusban álló műveletek 2. Gráf esetén egyértelmű a végrehajtás eredménye: A gráfban bármely két konfliktusban álló műveletpár között létezik megelőzési reláció Ezt a tranzakció megadásánál meg is követeljük 72/18 B IT MAN

19 Konfliktusban álló műveletek 3. r1(x) w1(x+3) c1 X=X+5 r2(x) w2(x+5) c2 r1(x) w1(x+3) c1 r2(x) w2(x+5) c2 X=X+3 r1(x) w1(x+3) c1 X=X+8 r2(x) w2(x+5) 72/19 B IT MAN c2

20 Tranzakciók ekvivalenciája A tranzakciók ugyanazokat az elemeket tartalmazzák A konfliktusban álló műveletek között ugyanolyan a megelőzési sorrend Ugyanazon kiinduló állapotból, ugyanazon műveletek az eredmény szempontjából ekvivalens (egyforma értéket adó, azonos, megfelelő) sorrendben hajtódnak végre. 72/20 B IT MAN

21 History (esetleírás, történet) A rendszerben egyszerre futó tranzakciók összessége Megadása hasonló a tranzakció megadásához műveletekből áll lényeges a végrehajtási sorrend Ábrázolása: gráffal a tranzakció azonosítóját is feltüntetjük, mint művelet indexet T1 r1(x) w1(x) c1 T2 r2(x) w2(x) a2 72/21 B IT MAN

22 History ábrázolása Az SQL parancsok kiadásuk sorrendjében: T1 SELECT * FROM DOLGOZO; DELETE FROM UZEM; ROLLBACK; T2 SELECT * FROM UZEM; UPDATE DOLGOZO SET FIZ=0; COMMIT; A history: Parancsok kiadási sorrendjében Megvalósulási sorrendben r1(x) w1(y) a1 r1(x) w1(y) a1 r2(y) w2(x) c2 r2(y) w2(x) c2 72/22 B IT MAN

23 Hibás history gráf T1 r1(x) w1(x) c1 T2 r2(x) w2(x) w2(y) c2 T3 r3(y) w3(x) w3(y) c3 Mi a gráf hibája? Nem tartalmaz megelőzési relációt r2(x) és w3(x) között! 72/23 B IT MAN

24 History-k ekvivalenciája Azonos feltételekből kiindulva azonos eredményt szolgáltatnak A konfliktusban álló műveletpárok sorrendje lényeges Csak az elfogadott tranzakciók hatása marad meg Ekvivalensek a history-k, ha: azonos tranzakciókat tartalmaznak, minden nem abortált tranzakcióhoz tartozó, konfliktusban álló művelet között ugyanolyan irányú megelőzési reláció áll fenn 72/24 B IT MAN

25 History - Példa T1 w1(x) r1(y) w1(y) a1 T2 r2(x) w2(x) c2 T1 kiír egy értéket x-be T2 olvassa ezt, majd ez alapján új értéket ír x-be T2 véglegesíti az eredményt T1 tovább fut, olvassa y-t, majd módosítja T1 abortálódik w1(x) utasítás-t hogyan görgetjük vissza? T2 nem véglegesített adatokat használt fel, ezért T2 tranzakciót is vissza kell görgetni 72/25 B IT MAN

26 History típusok Legfontosabb az ACID elvek betartása Nem minden history teljesíti az elveket r1(x) w1(x) c1 r2(x) w2(x) a2 72/26 B IT MAN

27 Példa: r1(x) w1(x) a1 r2(x) w2(x) c2 A T2 tranzakció olvasta a T1 tranzakcióban írt x adatot, és véglegesítődik. A T1 tranzakció ezután visszagörgetésre kerül. Probléma: A T2 tranzakció olyan adatot olvasott, ami helytelen, ezért vissza kellene görgetni. Ez viszont sérti az ACID elvek D-jét (Durability, tartósság), ami kimondja, hogy a véglegesített tranzakció hatása nem törölhető. Megoldás: előbb le kell zárni egy tranzakciót, csak aztán szabad egy másik tranzakciónak abból adatot olvasnia. 72/27 B IT MAN

28 RecoverAble History Visszagörgethető műveletsor Visszagörgethető egy history, ha minden olyan tranzakció, ami olvasott egy másik tranzakcióban írt adatot, később zárul le, mint az a tranzakció, amelyből az adatot kiolvasta. r1(x) w1(x) a1 v1 r2(x) w2(x) c2 v2 r1(x) w1(x) a1 r2(x) w2(x) c2 A T2 tranzakció olvasta a T1 tranzakcióban írt x adatot, és később zárul le, mint a T1, ezért mindkét history RA. 72/28 B IT MAN

29 RA History A history RA, de mégis hibás. Miért? w1(x) r1(y) w1(y) a1 r2(x) w2(x) r3(x) w3(x) Probléma: abortálási lavina! r4(x)... T2 olyan adatot olvasott, melynek helyessége még nem dőlt el 72/29 B IT MAN

30 Avoiding Cascadeless Abort history Az abortálási lavinát elkerülő history-ban egy tranzakció csak akkor olvashat egy adatot, ha az adatot utoljára módosító tranzakció már lezáródott. w1(x) r1(y) w1(y) a1 r2(x) w2(x) r3(x)... Az x-et T1 módosította utoljára. A T2 a T1 lezárása után olvassa az adatot, így ez a history ACA. 72/30 B IT MAN

31 ACA history Az RA, és az ACA kritériumok is teljesülnek (egyik tranzakció sem olvas a másik által módosított adatot), mégis problémás a history: r1(x) w1(x) w1(y) a1 r2(y) w2(x) a2 Probléma: Előbb T1, majd T2 módosítja x-et, végül abortálódik mindkettő. Először vissza kell állítani a w1(x) előtti értéket (ez megoldható), ezután a w2(x) előttit, ami viszont nem ismert! Megoldás: az írási művelet is csak akkor legyen megengedett, ha az adatot előzőleg módosító tranzakció már lezárult. 72/31 B IT MAN

32 STrict history A szigorú history-ban egy tranzakció csak akkor írhat vagy olvashat egy adatot, ha az adatot előtte módosító másik tranzakció már lezáródott. r1(x) w1(x) w1(y) r2(y) w2(x) A T2 tranzakció csak a T1 lezárása után írhatja vagy olvashatja a T1 tranzakcióban érintett adatokat. 72/32 B IT MAN

33 Újabb probléma r1(x) w1(x+3) c1 r2(x) w2(x+5) c2 A T1-beli olvasás megelőzi a T2-beli írást, a T1-beli írás követi a T2-beli olvasást Ez a "Lost update" jelenség 72/33 B IT MAN

34 SeRializable history A sorossal ekvivalens history-ban a tranzakciók a konfliktusban álló elemekre vonatkoztatva nem fedik át egymást. A konfliktusban álló elemekre nézve a tranzakciókban azonos a megelőzési reláció. r1(x) w1(x) a1 r2(x) w2(x) c2 72/34 B IT MAN

35 Serial history A soros historyban egy tranzakció bármely két művelete közé nem ékelődik be egy másik tranzakció valamely művelete. r1(x) w1(x) c1 r2(y) w2(y) c2 72/35 B IT MAN

36 RA ACA ST History-k kapcsolata SR S Cél: ST SR history, ez biztosítja a teljes izolációt 72/36 B IT MAN

37 Következmények Kevés a megfelelő history Lecsökkentik a párhuzamosságot, a konkurencia megvalósulási lehetőségeit Teljesítmény korlátozás ACID elvek Nagyobb konkurencia, hatékonyabb rendszer 72/37 B IT MAN

38 Izolációs problémák A tranzakciók nem önállóan futnak, hanem tás tranzakciókkal együtt Az egyidőben, párhuzamosan futó tranzakciók konfliktusban állhatnak egymással, ha ugyanazokat az objektumokat kezelik, ekkor izolációs problémák léphetnek fel Izoláció: elszigeteltség, elkülönülés 72/38 B IT MAN

39 Izolációs problémák Konfliktusban álló műveletek keveredése: Két írás egymás után Lost update w1(x) w2(x) Olvasás két írás között Dirty read w1(x) r2(x) w1(x) Írás két olvasás között Non repeatable read r1(x) w2(x) r1(x) Írás két olvasás között Phantom read r1(x) w2(x) r1(x) 72/39 B IT MAN

40 Lost update elveszett frissítés r1(x) w1(x+3) c1 r2(x) w2(x+5) c2 A két tranzakció egyszerre olvassa ki egy adat értékét, majd egymás után módosítják azt, így az egyik módosítás felülírja a másik módosítás értékét. A T1 tranzakció által végrehajtott módosítás elveszik 72/40 B IT MAN

41 Dirty read piszkos olvasás r1(x) w1(x+3) w1(x+5) r2(x)... A T2 tranzakció olyan adatot olvas, amit a még le nem zárt T1 tranzakció írt A T2 tranzakcióban hibás a kiolvasott adat 72/41 B IT MAN

42 Non repeatable read nem megismételhető olvasás r1(x) r1(x) w2(x+3) c2 A T1 tranzakció újra olvas egy korábban már olvasott adatot, és azt látja, hogy az adatot egy másik - már befejezett tranzakció (T2) módosította vagy törölte A T1 tranzakció által először olvasott értéket nem lehet újra beolvasni 72/42 B IT MAN

43 Phantom read Fantom olvasás r1(x) r1(x) w2(x) c2 Pl: r1(x): Select sum(ár) from számla w2(x): insert into számla (tnév, ár) values('tej', 200) A T1 tranzakció újra olvas korábban már olvasott, több rekordot is érintő adatot, és azt látja, hogy az adatok közé egy másik - már befejezett tranzakció (T2) új sorokat szúrt be, vagy azok közül sorokat törölt A T1 tranzakció által először olvasott aggregált értéket nem lehet újra beolvasni 72/43 B IT MAN

44 Tranzakció menedzser Ha gyorsítani akarjuk a tranzakciók végrehajtását, meg kell engedni, hogy a rendszerben egyszerre több tranzakció fusson párhuzamosan. Az egyes tranzakciók ilyenkor nem elszigetelten (izoláltan) futnak a rendszerben Ha a tranzakciók ugyanazokat az adatokat kezelik, konfliktusok keletkezhetnek közöttük. A konfliktusok elkerülése érdekében a Transaction Manager (TM) átrendezheti a tranzakciók végrehajtási sorrendjét Igényelt Megvalósult r1(x) w1(x) c1 r1(x) w1(x) c1 r2(x) w2(x) c2 r2(x) w2(x) c2 72/44 B IT MAN

45 Izolációs szintek A DBMS-ek által biztosított izolációs szintek (tranzakció függetlenségi fokok): 0.szint anarchia, minden hibajelenség felléphet 1.szint nincs átlapolt írás (nincs lost update) 2.szint első szint és nincs piszkos olvasás 3.szint második szint és ismételhető az olvasás 72/45 B IT MAN

46 Izolációs szintek beállítása SQL-ben SET TRANSACTION ISOLATION LEVEL szint A szint paraméter lehetséges értékei: NOLOCK READ UNCOMMITED READ COMMITED REPEATABLE READ SERIALIZABLE 72/46 B IT MAN

47 Izolációs szintek (1) NOLOCK Nem foglalja le a tranzakció által érintett objektumokat. A tranzakciók nem támogatottak, nincs tranzakció kezelés. 0. szint 72/47 B IT MAN

48 Izolációs szintek (2) READ UNCOMMITED Piszkos, véglegesítés előtti adatok is olvashatók, Átlapolt írás nem megengedett. 1. szint Olvasáskor mindig az aktuális (módosított) értéket kapjuk, még akkor is, ha az adott insert/update tranzakciót a kezdeményező nem commit-olta. A következő problémák léphetnek fel: Dirty read, Non repeatable read, Phantom read. 72/48 B IT MAN

49 Izolációs szintek (3) READ COMMITED Csak véglegesített, tiszta adatok olvashatók. 2. szint Olvasáskor mindig az adott rekord véglegesített értéket kapjuk. Ez az esetek 99%-ra használható, a tranzakcióink mindig csak olyan rekordokat olvasnak, amik véglegesítve vannak, azaz nincs nyitott tranzakció, ami dolgozna rajtuk. A baj ezzel az, hogy ha sokan írják és olvassák az adott rekordot vagy táblát akkor könnyen kialakulhat az a helyzet, hogy az olvasó tranzakciók arra várnak hogy az írás (pl egy nagy tábla update-je) befejeződjön. Ez a főleg a rekordokra vonatkozik így csak a piszkos olvasástól véd. Probléma lehet: Non repeatable read, Phantom read. 72/49 B IT MAN

50 Izolációs szintek (4) REPEATABLE READ Teljesül az ismételhető olvasás, két olvasás között bővülhet a tábla. 3. szint Ez annyival jobb a READ COMMITTED-nél, hogy már a nonrepeatable read hibát is képes kiszűrni a tranzakcióból. Egyszerűbben: csak a rekordok véglegesített értékeit használja, és a rekordok tranzakció közbeni törlése nem befolyásolja a select-eket. Ebben az esetben csak egy probléma marad: Phantom read 72/50 B IT MAN

51 Izolációs szintek (5) SERIALIZABLE A teljesen soros végrehajtást kérvényezi, nincs elméleti izolációs szint (3. szint), mindennemű módosítás tiltott. Annyival több a REPEATABLE READ-től, hogy más tranzakció nem írhatja felül a mi tranzakciónk által olvasott értékeket, azaz addig várakoztatja azokat míg be nem fejeződik a tranzakciónk. Így nem fognak tranzakció közben fantom sorok keletkezni a táblában. Itt elég problémás lehet, ha több résztvevő folyamatosan olvas egy táblát, amíg az updatelő szál várakozik, mert a tábla lock-olva van és nem tud bele írni 72/51 B IT MAN

52 Zárolás Az egyik legismertebb és leginkább elterjedt tranzakció kezelési módszer. A tranzakció rátelepszik, lefoglalja az objektumot arra az időre, amíg használni szeretné. A zárolás hatására a többi tranzakció korlátozva van az objektum elérésében, ezért rendszerint várakozásra kényszerülnek. A várakozás akkor vagy oldódik fel, ha újra elérhető már az objektum. l1(x) r1(x) w1(x) u1(x) lock unlock 72/52 B IT MAN

53 Zárolás (2) A zárolás nem akadályozza az adatok olvasását, csak a mások által való módosítást Nyilván kell tartani objektumonként kiegészítő információkat: Szabad-e, Ki foglalja (felszabadításnál tudni kell) Nő a holtpont esélye Helytöbblettel jár a zárolás 72/53 B IT MAN

54 Zárolási szintek Mező szintű zárolás Rekord szintű zárolás Tábla szintű zárolás 72/54 B IT MAN

55 A zárolások finomsága A különböző adatbázis-kezelők eltérnek abban, hogy milyen fajta adattételek zárolását teszik lehetővé. Van amelyik mezők, van amelyik rekordok, és van amelyik teljes relációk zárolását megengedi. Minél nagyobb a zárolt objektum, annál nagyobb az esélye annak, hogy egy tranzakciónak egy másikra kell várnia, még akkor is, ha a két tranzakció ténylegesen nem ugyanazt az adatelemet szeretné elérni. Viszont minél kisebb a zárolható adattétel, annál terjedelmesebb és bonyolultabb a zárolást kezelő mechanizmus. 72/55 B IT MAN

56 Előnyök és hátrányok Előny Hátrány Mező szintű zárolás Nagyobb fokú párhuzamosság Jelentősebb konkurencia Sokkal több kiegészítő információt kell tárolni és karbantartani Jelentős hely, idő és költségnövekedés Tábla szintű zárolás Sokkal egyszerűbb nyílvántartani Gyorsabban adminisztrálható Nagyon lecsökkenti a konkurenciát Nagyon sokáig kell várakozni a párhuzamosan futó tranzakcióknak egymásra 72/56 B IT MAN

57 Zárolási idő Alapelv: csak addig zároljunk egy objektumot, ameddig szükséges Lefoglalás: amikor szükség van rá Felengedés: adatok véglegesítése után, tranzakció végén Hiba: ha a művelet után azonnal felengednénk T2 olvashatna T1 által írt, nem véglegesített objektumot RA, ACA feltétel sérülne 72/57 B IT MAN

58 Kétfázisú zárolás (2PL Two-Phase Locking) 1. fázis: zárolások lefoglalása 2. fázis: zárolások felengedése a tranzakció végén Kétfázisú zárolás esetén a tranzakció végéig csak zárolások történhetnek, majd a tranzakció végén egyidejűleg történik a zárolások felengedése. Minden zárolási művelet megelőz minden feloldást. A legtöbb RDBMS-ben 2PL zárolás biztosítja az ACIDelveknek megfelelő history-k megvalósítását 72/58 B IT MAN

59 Mely műveleteknél zároljunk? ST és SR szabályok: A konkurens műveleteknek sorosan kell végrehajtódniuk, beleértve a tranzakciók lezárási utasításait is Írási műveletkor szükséges a zárolás Egyébként RA követelmény sérülne l1(x) w1(x) Olvasáskor is szükséges lehet az olvasás Lost update jelenség elkerülése l1(x) r1(x) A gyakorlatban kissé módosul a zárolás 72/59 B IT MAN

60 Zárolás típusok Normál zárolás: Zárolás alatt más tranzakció nem olvashatja és/vagy írhatja a foglalt elemet Írási és olvasási zárolás: Írási zárolás: Más tranzakció se nem olvashatja, se nem írhatja az objektum értékét Olvasási zárolás: Csak a másik tranzakció általi értékmódosítást akadályozza meg 72/60 B IT MAN

61 Példa normál zárolásra Zárolás nélkül: lost update r1(x) w1(x+3) c1 r2(x) w2(x+5) c2 Normál zárolással: l1(x) r1(x) w1(x+3) c1 u1(x) l2(x) r2(x) w2(x+5) c2 u2(x) T2 lefoglalja x-et, az r1(x) már nem tud végrehajtódni r1(x) megvárja T2 befejezését, x elengedését T1 lefoglalja x-et, megnöveli értékét. Lost update elkerülve! 72/61 B IT MAN

62 Példa írási-olvasási zárolásra Zárolás nélkül: lost update r1(x) w1(x+3) c1 r2(x) w2(x+5) c2 Írási-olvasási zárolással: l1r(x) r1(x) l1w(x) w1(x+3) c1 u1(x) l2r(x) r2(x) l2w(x) w2(x+5) c2 T2 zárolja x-et olvasásra, aztán beolvassa T1 olvashatja x-et, ezért zárolja olvasásra, és beolvassa T1 zárolja x-et írásra, kiírja, véglegesítődik a tranzakció T1 felengedi az x írási és az olvasási zárát T2 T1 zárolja x-et írásra, kiírja, véglegesítődik a tranzakció A lost update megmaradt, hiszen T2 w1(x+3) előtt olvasta ki x-et! Hibás a zárolás megoldása! 72/62 B IT MAN

63 Helyesen formált zárolás Minden művelet előtt van egy zárolás A művelet elvégzése után a zárolást fel kell engedni l1(x) w1(x) u1(x) 72/63 B IT MAN

64 Helyes zárolás Helyesen formált a zárolás Minden műveletet zárol Van írási és olvasási zárolás A 2PL teljesül, a tranzakció végén felengedve az objektumokat A helyes zárolás ST SR history-t ad! Megjegyzés: a helyes zárolás teljes izolációt eredményez, a gyakorlatban sokszor enyhítenek a szigoron a párhuzamosság megvalósítása miatt 72/64 B IT MAN

65 Zárolás felminősítése Ha minden műveletet egyenként zárolunk, és aztán feloldjuk a zárolást, nem lesz a zárolás kétfázisú (2PL) Ez esetben másik tranzakció megszerezheti az adott objektumot az elindított tranzakciótól Ezért egy tranzakció csak egyszer zárolhat, és ha írni is akar, akkor az adott objektumot írásra kell zárolni. l1w(x)... r1(x) w1(x) c1 u1(x) 72/65 B IT MAN

66 Zárolás felminősítése Probléma: Nem biztos, hogy a tranzakció tudja előre, hogy írni is fog Nagyon lecsökkenti a párhuzamosság lehetőségét, mivel túl hamar lefoglalja kizárólagos használatra az x objektumot Megoldás: A zárolást felengedés nélkül egy magasabb szintre kell vinni l1r(x)... l1w(x) r1(x) w1(x) c1 u1(x) 72/66 B IT MAN

67 Zárolások gyenge pontja A zárolások biztos megoldást nyújtanak a helyes history megvalósításra Gyenge pont: A tranzakciók várakozásra kényszerítése Többen várakoznak körbevárakozás alakulhat ki végtelen várakozás (deadlock, holtpont) l1(x) x rq(x) T1 DEADLOCK T2 rq(y) y l2(y) l: lock, zárolás rq: kérés, igénylés : várakozás 72/67 B IT MAN

68 Deadlock kezelése l1(x) x rq(x) T1 DEADLOCK T2 rq(y) y l2(y) Egyik tranzakció sem tud továbblépni, mindkettő a végtelenségig várakozna Megoldási módszerek: Detektálás, aztán az egyik tranzakció abortálása Feloldási módszerek: TimeOut módszer Wait-For Graph 72/68 B IT MAN

69 Timeout mechanizmus A rendszer figyeli, mennyi ideig várakozott a tranzakció a zárolás feloldására Ha a várakozási idő túllép egy megadott időhatárt, akkor a TM (tranzakció menedzser) deadlock jelenségként értékeli, melyet fel kell oldani Egyik megoldás: Valamelyik tranzakció abortálása Abortálandó tranzakció kiválasztására számos stratégia létezhet ~ OS memóriakezelés Kérdés: mit preferálunk? Eltöltött idő Elvégzett módosítások Még hátralévő idő 72/69 B IT MAN

70 Wait-For Graph A gráf elemei a futó tranzakciók A gráf élei irányítottak T1-ből mutat él T2-be, ha van olyan objektum, amit T2 lefoglalt és T1 is szeretne elérni, és T1 ezen objektum felszabadulására vár Deadlock jelentése a várakozások szintjén: Nincs vége a várakozási láncnak, azaz nincs esély, hogy a várakozási lánc valamikor is megszűnjön WFG gráfban: Akkor van deadlock, ha a létezik körút Amennyiben a gráf körútmentes, úgy a history végrehajtása során nem lépett fel deadlock 72/70 B IT MAN

71 Wait-For Graph T1 T2 T1 T2 T4 T5 T3 T5 T3 Körútmentes Deadlock 72/71 B IT MAN

72 VÉGE VÉGE 72/72 B IT MAN