© 2005 MAH – Datavetenskap LdP Transaktioner Distribuerade system PV7110.

En presentation över ämnet: "© 2005 MAH – Datavetenskap LdP Transaktioner Distribuerade system PV7110."— Presentationens avskrift:

1 © 2005 MAH – Datavetenskap LdP Transaktioner Distribuerade system PV7110

2 Innehåll Transaktioner Seriell ekvivalens Nästlade transaktioner Seriell ekvivalens med lås Samtidighetskontroll (concurrency control)

3 Transaktioner I vissa situationer kräver klienter att: 1.De inte störs av andra samtidiga klienter 2.Alla eller ingen av operationerna lyckas ACID –Atomicity –Consistency –Isolation –Durability

4 Transaktioner Det är önskvärt att maximera samtidighet Seriellt ekvivalenta transaktioner tillåts exekvera samtidigt –de har samma effekt som om de exekverades seriellt Varje transaktion ges ett unikt ID (TID) Lyckade transaktioner kallas ”commited” Vad gör servern och klienten vid krascher?

5 Transaktioner Tre vanliga problem –”Lost update” –”Inconsistent retrievals” –”Conflicting operations”

6 Lost update Båda transaktionerna skall öka b med 10% T’s uppdatering blir förlorat TransactionT: balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) TransactionU: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10) balance = b.getBalance(); $200 balance = b.getBalance(); $200 b.setBalance(balance*1.1); $220 b.setBalance(balance*1.1); $220 a.withdraw(balance/10) $80 c.withdraw(balance/10) $280

7 Inconsistent retrievals V överför $100 från A till B medan W beräknar ”totalt” Transaction V: a.withdraw(100) b.deposit(100) Transaction W: aBranch.branchTotal() a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() b.deposit(100) $300

8 Seriell ekvivalens Vi inför nu begreppet seriell ekvivalens En seriellt ekvivalent parallell exekvering: –En exekvering som ger samma resultat som om exekveringen hade skett seriellt Med samma resultat menas: –Läsoperationer ger samma värden –Instansvariabler har samma värden i slutet Transaktionerna schemaläggs för att undvika samtidig access till samma konton

9 Funkar det nu då? Om den ena kör före den andra funkar det Samma gäller för en seriellt ekvivalent ordning Transaction T: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) Transaction U: balance = b.getBalance() b.setBalance(balance*1.1) c.withdraw(balance/10) balance = b.getBalance()$200 b.setBalance(balance*1.1)$220 balance = b.getBalance()$220 b.setBalance(balance*1.1)$242 a.withdraw(balance/10) $80 c.withdraw(balance/10)$278

10 Den andra då? Det kan aldrig bli fel om alla läsningar görs före eller efter en uppdatering Läsningar och skrivningar till olika resurser påverkar inte varandra Vilka två operationer skulle kunna byta plats? Transaction V: a.withdraw(100); b.deposit(100) Transaction W: aBranch.branchTotal() a.withdraw(100); $100 b.deposit(100) $300 total = a.getBalance() $100 total = total+b.getBalance() $400 total = total+c.getBalance()... Svar: den översta I W med den andra i V

11 Conflicting operations Två operationer sägs var i konflikt om deras effekt beror på i vilken ordning de körs Enklaste exemplet: read och write Operations of different transactions Conflict Reason read No Because the effect of a pair ofread operations does not depend on the order in which they are executed readwriteYes Because the effect of aread and a write operation depends on the order of their execution write Yes Because the effect of a pair ofwrite operations depends on the order of their execution

12 Definition –”För att två transaktioner skall vara seriellt ekvivalenta är det nödvändigt och tillräckligt att alla operationer i konflikt utförs i samma ordning på alla objekt som båda använder” Om vi har följande: –T:x = read(i); write(i, 10); write(j, 20); –U:y = read(j); write(j, 30); z = read (i); Seriell ekvivalens kräver då att: –T accessar i före U och T accessar j före U, eller –U accessar i före T och U accessar j före T Var är konflikten? Seriell ekvivalens… T’s write(i) med U’s read (i) U’s read (j) och write(j) med T’s write(j)

13 Detta funkar således ej Observera att detta inte är seriellt ekvivalent Operationerna görs inte i samma ordning TransactionT: U: x = read(i) write(i, 10) y = read(j) write(j, 30) write(j, 20) z = read (i)

14 Återhämtning från avbrott Om en transaktion avbryts måste servern se till att andra samtidiga transaktioner inte ”ser” dess effekter Vi tittar på två problem –”Dirty reads” –”Premature writes” Enligt tidigare: –getBalance() är en read-operation –setBalance() är en write-operation

15 TransactionT: a.getBalance() a.setBalance(balance + 10) TransactionU: a.getBalance() a.setBalance(balance + 20) balance = a.getBalance()$100 a.setBalance(balance + 10)$110 balance = a.getBalance()$110 a.setBalance(balance + 20) $130 commit transaction abort transaction Dirty read Exekveringarna är seriellt ekvivalenta Vad är problemet? U har gjort en “dirty read” U kan inte avbryta eftersom den har gjort “commit”

16 Återhämtning Om en transaktion (jämför med U) blir ”commited” efter att den ”sett” effekterna av en transaktion som senare blir avbruten, kan den inte återhämtas Vad kan vi göra? –En ”commit” fördröjs tills alla observerade transaktioner gör ”commit” Fortfarande problem –Detta leder till kedjeavbrott på väntande transaktioner

17 Återhämtning Kedjeavbrott (Cascading aborts) Tänk att U väntar tills T avbryter –Då måste även U avbryta –Då måste även alla andra som ”sett” U avbryta –O.s.v. Vi undviker genom: –Transaktioner tillåts endast läsa objekt skrivna av ”commited” transaktioner –Varje read operation måste alltså fördröjas U väntar t.ex. med getBalance() tills T gör ”commit”

18 Premature write Vissa databassystem håller ”before-images” och återställer dessa efter avbott $105 är ”before-image” för U, om U avbryter får vi rätt värde Blir det rätt i alla fall med ”before-images”? TransactionT: a.setBalance(105) TransactionU: a.setBalance(110) $100 a.setBalance(105)$105 a.setBalance(110) $110 Interaktion mellan write-operationer när en transaktion avbryter

19 Åtgärder Premature writes –Om vi har ”before-images” Köa write-operationer tills tidigare transaktioner som har uppdaterat samma objekt antingen avbryter eller gör ”commit” Strikt exekvering av transaktioner –Undvika både dirty read och premature write Köa både read- och write-operationer En exekvering kallar strikt om både read och write på ett objekt köas tills alla transaktioner som tidigare uppdaterat objektet antingen avbrutits eller gjort ”commit” Strikt exevering ger den önskvärda egenskapen isolation Tentative versions –Objektuppdateringar sparas tillfälligt i temporärt minne

20 Nästlade transaktioner En transaktion kan starta en annan transaktion som kan starta en annan transaktion som kan starta… Top level Sub transaction A1Sub transaction B1 Sub transaction A2Sub transaction B2

21 Nästlade transaktioner Transaktioner på samma nivå kan exekvera samtidigt om de uppfyller seriell ekvivalens En undertransaktion kan fallera oberoende av andra

22 Fördelar Samtidighet mellan undertransaktioner –Jämför med summering av konton (branchTotal) –Kan implementeras i olika servrar Robusthet –Undertransaktioner kan fallera oberoende –Föräldern väljer vad som skall göras vid eventuellt avbrott

23 Några viktiga krav En transaktion måste se till att alla dess undertransaktioner är färdiga innan den avbryter eller gör ”commit” En undertransaktion väljer själv om den vill avbryta eller göra ”provisional commit”, beslutet är fast Om en förälder avbryts, avbryts även alla undertransaktioner Om huvudtransaktionen gör ”commit” kan även alla undertransaktioner göra ”commit”

24 Sammanfattning OBS! Transaktioner i en server Atomiska vid samtidighet –Genom seriellt ekvivalenta exekveringar Atomiska vid serverkrascher –Sparar ”commited”-tillstånd –Använder strikt exekvering –Tentative versions för att kunna uppdatera och avbryta Nästlade transaktioner –Samtidig exekvering av undertransaktioner –Oberoende återhämtning av undertransaktioner

25 Lås/Uteslutning Med lås/uteslutning kan seriell ekvivalens garanteras

26 Strikt 2-fas låsning 1. Vad är “dirty reads”? 2. Hur kan de förhindras? 1.En transaktion läser ett värde som uppdaterats av en annan transaktion som senare avbryter 2.Fördröj read-operationer tills transaktioner som uppdaterat värden avbryter eller gör ”commit” Strikt exekvering förhindrade ”dirty reads” och ”premature writes” Allt som blivit låst under en transaktion måste hållas låst tills transaktionen avbryter eller ”commits” Detta kallas strikt 2-fas låsning För att dessutom säkerställa återhämtning efter krasch, hålls låsen tills uppdateringar har skrivits till permanent lagring

27 Read/Write konfliktregler Read-operationer i olika transaktioner blir inte i konflikt –Exklusiva lås på dessa påverkar samtidigheten negativt Readers/writer - flera läsare, en skrivare –Flera transaktioner kan läsa ett värde samtidigt –En transaktion i taget kan skriva –Båda ovanstående kan inte göras samtidigt –Använd read- och write-lås –Read-lås kallas ibland för ”shared locks” (delade) 3. Vad avgör om 2 operationer är i konflikt? 3.Deras gemensamma effekt är beroende på i vilken ordning de körs

28 Konfliktregler Operationer i konflikt: –1. En transaktion T har läst ett värde. Då kan inte en annan uppdatera värdet innan T avbryter eller gör ”commit” –2. En transaktion T har skrivit ett värde. Då kan inte en annan läsa eller skriva värdet innan T avbryter eller gör ”commit” For one objectLock requested readwrite Lock already set noneOK readOKwait writewait

29 Upp/Ner-gradering av lås En transaktion sätter ett read-lås när den skall läsa ett värde Låset ”uppgraderas” till ett write-lås vid behov till att skriva –OBS! Bara samma transaktion kan uppgradera det Andra transaktioner måste då vänta Eng: Lock promotion Varning! – Ökar risken för deadlock!

30 Sammanfattning Access till ett objekt i en transaktion –Om objektet inte är låst, lås det och fortsätt –Om objektet är ”write”-låst, vänta –Om objektet är ”read”-låst, dela låset och fortsätt –Om samma transaktion redan låst det, uppgradera vid behov och fortsätt När en transaktion avbryts eller gör ”commit” –Öppna alla lås som transaktionen låst Hur gör vi med risken för deadlock?

31 Kan vi förhindra deadlock? Ja, men är det realistiskt? Två sätt att göra det: –Låsa alla objekt som en transaktion kommer att behöva access till Stora prestandaförluster Kan vara omöjligt att avgöra vilka objekt som kommer att behövas –Lås begärs i en fördefinierad ordning Stora prestandaförluster Går det i stora system?

32 Implementation av lås Ett separat objekt sköter om låshanteringen - Lock manager Lock managern måste hantera deadlocks Vi introducerar väntegrafer (wait-for graphs) för att visualisera relationerna mellan samtidiga transaktioner B A Waits for Held by T U U T Waits for

33 Wait-for graphs T, U och V delar ett ”read”-lås på C W håller ett ”write”-lås på B (som V väntar på) T och W begär uppgradering av låset på C  deadlock (V väntar i 2 cykler) C T U V Held by T U V W W B Waits for

34 Upptäcka deadlock Leta efter cykler i väntegrafer Om ett deadlock upptäcks kan en transaktion avbrytas för att lösa upp en cykeln Kan byggas in i Lock managern Väntegrafen måste representeras Vilken transaktion skall avbrytas? –Den ”äldsta”, eller ”nyaste”, eller den i flest cykler?

35 Timeout på lås Kan vi inte ha timeout på låsen istället? –Ett lås blir ”sårbart” efter en viss tid –Låset kan fortgå i sårbart tillstånd tills en annan transaktion begär inträde, då bryts låset –Transaktioner som har fått ett lås brutet avbryts Vilka problem har vi då? –Lås bryts trots att vi inte har deadlock –Vid tider med stor belastning straffas långa transaktioner eftersom många lås då bryts –Svårt att välja tidsintervall

36 Optimistisk kontroll Eng: Optimistic Concurrency Control Behöver vi tvunget låsa allt för att vara säkra? Nej! Inte i system med få konflikter –Transaktioner tillåts exekvera utan hinder –I slutet kollas om transaktionen har varit i konflikt –Om en konflikt har uppstått avbryts en transaktion Transaktioner delas in i 3 faser –Arbete(Working) –Validering(Validating) –Uppdatering(Updating)

37 3 olika faser En koordinator behövs Arbete –Transaktionen använder ”tentativa” versioner av objekt den accessar (”dirty reads” kan förekomma) –Read- och write-operationer ”spelas in” av koordinatorn Validering –Vid slutet av en transaktion kollas efter eventuella konflikter –Om inga påträffas görs ”commit” –Vid konflikt måste en av transaktionerna avbryta Uppdatering –Vid lyckad validering skrivs de ”tentativa” värdena permanent –”read-only”-transaktioner kan göra ”commit” direkt Här får vi alltså inte deadlock. Istället lyckas den transaktion som först går igenom valideringen. De andra avbryts om konflikter hittas

38 Validering av transaktioner Vi använder read/write-konfliktregler –Då har vi seriell ekvivalens mellan transaktioner Varje transaktion ges ett nummer vid start. Numret behålls vid ”commit” Reglerna nedan säkerställer serialiserbarhet för transaktion T v m.a.p T i TvTv TiTi Rule writeread1.TiTi must not read objects written byTvTv readwrite2.TvTv must not read objects written byTiTi write 3.TiTi must not write objects written byTvTv and TvTv mustnot write objects written byTiTi

39 Validering av transaktioner Backward validation –T v ’s ”reads” kollas mot föregående överlappande transaktioner –Transaktioner utan read-operationer behöver inte kollas Earlier committed transactions WorkingValidationUpdate T 1 T v Transaction being validated T 2 T 3 Later active transactions active 1 2

40 Backward validation boolean valid = true; for (int Ti = startTn+1; Ti <= finishTn; Ti++){ if (read set of Tv intersects write set of Ti) valid = false; } startTn - Det största transaktionsnumret hos en tidigare avslutad transaktion när T v startade finishTn – Det största transaktionsnumret hos en tidigare transaktion när T v påbörjar validering Vid eventuell konflikt måste T v avbrytas 4. Vad behövs för valideringen? 4.Vi behöver lagra ”write”-operationer från tidigare transaktioner

41 Validering av transaktioner Forward validation –T v ’s ”writes” kollas mot överlappande aktiva transaktioner –Transaktioner utan ”write”-operationer går alltid igenom Earlier committed transactions WorkingValidationUpdate T 1 T v Transaction being validated T 2 T 3 Later active transactions active 1 2

42 Forward validation boolean valid = true; for (int Tid = active1; Tid <= activeN; Tid++){ if (write set of Tv intersects read set of Tid) valid = false; } Algoritmen måste kunna hantera det faktum att aktiva transaktioners ”read”-operationer kan ändras under valideringen 5. Vilken transaktion avbryter vi vid fel? 5.Vi kan välja, men tänk på att: Om vi avbryter T v på grund av T i kan det vara förgäves om T i senare också avbryts

43 Jämförelse Vid konflikt –Forwdard tillåter olika val vid avbrytning av transaktion –Backward kan endast avbryta den validerande transaktionen Normalt är ”read”-operationer > ”write”-operationer –Backward Kan behöva kontrollera en stor mängd operationer Kan behöva lagra många gamla ”write”-operationer –Forward Kollar en ett mindre antal ”write”-operationer Behöver däremot hantera förändring i transaktioners ”read”- operationer och nystartade transaktioner