Plan for dagen. Måter å tenke på

Transkript

1 Plan for dagen Måter å tenke på Måter å tenke på (perspektiv på UML) Dagens sidesprang: yacc Transaksjoner Hva er det? Atomiske beregninger Hvordan håndtere SW feil abortere transaksjonen Hvordan håndtere kræsj/restart Log? Oppdeling i funksjoner Transaksjoner Dataflyt/datalagring? Objekter Tilstandsmaskiner? Design patterns / generic objects Tråder & synkronisering Prosesser & kommunikasjon %{ % %% Lex & Yacc repetisjon lex \+ { return PLUS; - { return MINUS; [0-9]+ { yylval.number = atoi(yytext); return NUMBER; ; %% Lex & Yacc YACC %{ % %token PLUS MINUS LPAR RPAR %token <number> NUMBER %union{ int number; %type <number> Expr %% Expression: Expr { printf("result = %d\n",$1); Expr: NUMBER { Expr PLUS Expr{ $$ = $1 + $3; Expr MINUS Expr{ $$ = $1 - $3; LPAR Expr RPAR{ $$ = $2; %% #include "lexyy.c"

2 $./lexyacc.exe Result = Result = 16 Lex & Yacc Kjøring Lex & Yacc bygging av Abstract Syntax Tree (AST) Dette er vel og bra for f.eks. lesing av enkle config filer, men hva om vi ikke skal evaluere der og da? En standard måte å bygge datastrukturer som svarer til det innleste (9-2)+3 Expression Result = 4 9lkas+2 lkjd Result = 10 lkas lkjd Result = 11 Expression_Int int value int eval() int eval() Expression_Plus Expr * e1,e2 int eval() Expression_Minus Expr * e1,e2 int eval() Lex & Yacc AST eksempel Lex [0-9]+ { yylval.expr = new Expression_Int(atoi(yytext)); return NUMBER; ; Yacc %union{ Expression * expr; %type <expr> Expr Expr: NUMBER { Expr PLUS Expr{ $$ = new(expression_plus($1,$3); Expr MINUS Expr{ $$ = new(expression_minus($1,$3); LPAR Expr RPAR{ $$ = $2; Transaksjoner (Design) rammeverk for SW en filosofi :-) Database folk tenker transaksjoner, men det er ikke begrenset til databaser Knakende bra grunnlag for bl.a. feilhåndtering & tilgjengelighet. Begreper Transaksjon == Atomiske Beregninger Commit, Abort

3 En transaksjon har ACID egenskaper: Atomisk enten utføres hele transaksjonen eller ingen ting. Consistency en transaksjon er en transformasjon av tilstanden i systemet fra en konsistent tilstand til en annen (ingen halvparter). Isolation Andre transaksjoner enten ser eller ikke ser transaksjonen. Durability Når en transaksjon er utført mistes aldri resultatet. Kontekst Consistency er rent design av transaksjonene inkludert konsistenssjekker. Isolation kan fikses ved lese/skrivelåser Atomicy & Durability er ikke tull: Skal holde uansett feil! Vil anta bare en feil her, men vi kan lett generalisere. Alloker låser Gjør jobben Frigi låser En transaksjon? Isolation er ok, vi antar consistency, og atomicy er greit hvis ingen ting går galt, men hva med durability? Vi skal bygge på dette eksemplet i to timer til for å resten på plass :-) Hva hvis en beregning mislykkes? Vi må: Sette alle variable tilbake (og rette opp alle andre effekter) frigi låser rapportere abort tilbake til oppdragsgiver.

4 Feilhåndtering Alloker låser Lagre unna variable Gjør jobben, hopp til end: hvis problemer label end: if(error){ sett variable tilbake status = FAIL; else{ status = OK; Frigi låser return status; Men hva hvis II... vi skal gjøre flere ting i samme transaksjon / det er flere moduler (/servere/maskiner...) involvert? Enten må alt gjøres eller ingen ting! --> To-fase commit protokoll (Til alle deltagere:) Gjør dette! Fikk dere det til? Hvis alle svarer ja Commit, ellers Abort Forsøk på tofase commit: status = OK; if(doworkx(...) == FAIL) status = FAIL; if(doworky(...) == FAIL) status = FAIL; if(doworkz(...) == FAIL) status = FAIL; if(status == OK){ commitworkx(); commitworky(); commitworkz(); else{ abortworkx(); abortworky(); abortworkz(); Mye overhead både i klient og modul/server Tofase commit standard løsning Vi innfører en Transaction Manager TransactionId beginwork() Status endwork(tid) TransactionId tid = beginwork(); doworkx(tid,...); doworky(tid,...); doworkz(tid,...); result = endwork(tid); Temmelig rigid Håndterer det flere samtidige transaksjoner?

5 Transaction Manager Holder rede på hvem som er med i transaksjonen. Tar seg av avstemmingen Sett fra en Resource Manager resource manager == det jeg hittil har kalt en modul eller server Den må: Melde seg selv til Transaction Manager for å være med i en transaksjon. Holde rede på hvilke låser som er assosiert med en transaksjon Holde rede på hvile variable/effekter som må settes tilbake ved en evt. abort. Klient Transaction Manager Resource Manager beginwork Transaksjons Id doworkx(tid,...) doworky(tid,...) doworkz(tid,...) endwork(tid) OK/Fail jointransaction(tid) preparetocommit OK/Fail commit/abort Resource Manager i praksis Alle kall tar tid inn Alle kall sjekker om RM er påmeldt transaksjonen Alle låser lagres unna Alle variable/effekter lagres Staus (OK/fail) lagres unna Må implementere: en generell preparetocommit (dvs. returnere status for transaksjonen) generelle commit & abort. Alle disse tre virker bare på modulens datastrukturer!

6 Deadlocks, Starvation & timing problemer Et transaksjonsbasert system gjør ingen antagelser som gjør at slike ikke forekommer! (Mao. i sterk kontrast til sanntidssystemer.) Standardløsning: Gi transaksjoner en tidsfrist, og så abortere om tiden går ut (en jobb for transaction manager) Alternativ løsning: Å gjøre de nødvendige antagelsene: Dette er ikke mulig i det generelle databasesystemet, men er det sannsynligvis for våre applikasjoner. (Burns&Wellings tar opp noe av dette!) Interaksjon med utenverdenen En utskrift til skjermen, eller et utsatt pådrag kan ikke aborteres... Løsningen må være applikasjonsavhengig: Holde pådrag utenfor transaksjonsregimet. Vente med utsetting til commit. Intelligent HW som håndterer abort. Oppsummering Vi håndterer nå alle feil uten å komme i inkonsistent tilstand. Det har kostet en del infrastruktur (Transaction Manager + en del datastrukturer i Resource Manager), men gitt denne er det relativt rett frem å lage applikasjoner. Vi har ikke diskutert durability enda! Durability Dette er jo ikke noe problem så lenge prosesser ikke kræsjer/restartes... Å lagre tilstand til disk etter hver transaksjon er ingen løsning... Selv om en transaksjon er ferdig kan det være andre som er midt i, dessuten kan disk-skrivingen skjære seg. Så, hvordan?

7 Durability Bruk av Log Hver deltager (unntatt klienten) skriver til en logg hva den har tenkt å gjøre, og så venter til logg'en er trygt bevart før den gjør det. La oss, mens vi holder på, før-status til loggen også (vi kommer til hvorfor...) Når en prosess kommer opp igjen kan den rekonstruere tilstanden ved å utføre alle log recordene. Durability Bruk av Log - II Den må selvfølgelig sjekke, før den utfører noe, at transaksjonen faktisk ble committed. (Anta at vi skriver commit & abort logrecorder også) Noen transaksjoner vil kunne mangle commit eller abort-logrecorder (TransactionManager har enda ikke tatt avgjørelse, eller den ble tatt mens vi var nede.) Vi må kunne spørre TM om dette. Hvordan gikk det egentlig med denne transaksjonen? Durability Bruk av Log - III Foil fra boken p Men hva om TM går ned? Etter at avstemmingen er ferdig, men før commit/abort sendes ut, logges resultatet. Alle transaksjoner som er aktive når TM går ned aborteres. Så, hvorfor skrev vi før-tilstand til loggen? Genistrek: Vi slipper å holde rede på førtilstand til variable i modulen, men kan bare kjøre undo på logrecordene i motsatt rekkefølge.

8 Log IV: Blir ikke log'en uendelig stor? Innimellom skrives komplett tilstand, inkludert en liste over aktive transaksjoner skrevet til log'en. (et sjekkpunkt ) Log som er eldre enn det siste sjekkpunktet som ikke inneholder aktive transaksjoner kan kastes. NB: et sjekkpunkt representerer alene ingen konsistent tilstand! På tide med en Log Manager? Jepp, dermed kan denne samle opp logrecorder og gjøre diskskrivingen mer effektiv. Og går den på en annen maskin kan vi til og med være fornøyd med å få kvittering for mottatt logrecord istedet for å vente på den trege diskskrivingen! Lock Manager? Figur p. 534 OK, vi kan få funksjonalitet som frigi alle låser assosiert med tid. Også: I den grad vi har låsing av ting utenfor prosessen kan lock manager låse opp hvis vi dør.

9 Gray & Reuter: Transaction Processing ~1000 sider med detaljert stoff Mer avansert transaksjonsmodell Implementasjon på kodenivå Kunsten er å bruke bare det vi har bruk for og få det riktig. Dette er en filosofi - en måte å tenke på som kan ligge under designet ditt. Case I Høy tilgjengelighet: Vi har to maskiner hvor den ene skal kunne ta over for den andre på kort varsel. Skalerbarhet: Systemet skal være forberedt på å sette inn ekstra maskiner ved flaskehalser i beregningene. Case II Feilhåndtering: Backward error recovery (fra Burns&Wellings) er en ad-hoc måte å få til abort på. Distribuerte systemer: (Autronica:) Hvordan beholde en konsistent tilstand ved restart av et subsystem? Lastbalansering: Bruk databaser til data! De har denne funksjonaliteten inne og mer. God ytelse Store datamengder Administrasjonsprogrammer Kan spille Resource Manager rolle