Tags:    database locking timestamping samtidighed transaktion

Samtidige Transaktioner

Som jeg har sagt tidligere, er der ingen direkte problemer når data fra databasen hentes, af en enkelt bruger. De store problemer kan opstå, når der er flere brugere, som på samme tid benytter databasen. Problemet vi skal diskuterer herunder er stadig ikke noget som er det store problem, da de kun kan opstå hvis to brugere prøver at få adgang til præcis det samme data, på præcis det samme tidspunkt. Altså de laver hver deres transaktion samtidig, målrettet imod det samme data. Det lyder som noget der ikke forekommer ofte, men tænk bare på googles søge databaser. Der er jo flere millioner af brugere, som bruger disse databaser, og det kan jo ske at der er flere brugere som gerne vil læse det samme data samtidig. Vi har derfor en masse transaktioner som kan ske på samme tid, målrettet mod det samme slags data. En af metoderne til at løse disse problemer på er ved at bruge nogle kontrollerings procedurer, hvoraf en af dem kaldes Locking, men først skal vi lige se på, hvilke problemer der kan opstå ved samtidige transaktioner.

Lost Update Syndromet

En af de største problemer med en flerbruger database, er at to transaktioner læser de samme data, hvorefter den første opdaterer rækken med noget nyt data, og herefter opdaterer den anden transaktion den samme række, men med de gamle data som start data. Dette gør at den første transaktion ikke fik sin opdatering registreret ordentligt, fordi den anden transaktion har opdateret rækken lige efter, på baggrund af data hentet fra den gamle række. Dette kaldes en Lost Update, og er et af de største problemer vedrørende en flerbruger database.

Lad os tage et eksempel hvor vi har to transaktioner. De to transaktioner dækker over 2 flybillet bestillinger, altså hver transaktion skal ind i vores database, hvor vi har gemt data om hvor mange fly billetter, som der er tilbage er gemt. Transaktion 1 laver nu en læsning fra databasen, og får af vide hvor mange ledige billetter der er tilbage på flyet. Lad os sige at der kun er 4 ledige pladser tilbage på flyet. Transaktion 2 laver nu samtidig med transaktion 1, også en læsning af rækken med antallet af ledige fly billetter til det samme fly. Han får nu også vist at der er 4 ledige pladser tilbage. Transaktion 1 laver nu en bestilling, hvor han bestiller 2 af fly billetterne. Transaktion 1 går altså ind i databasen og opdaterer vores data fra 4 ledige billetter til nu kun at indeholde 2 ledige fly billetter. Der er altså nu kun 2 ledige pladser tilbage, men vores transaktion 2 har jo læst at der var 4 ledige pladser tilbage. Han har nu lavet en bestilling på 3 billetter, og opdaterer nu rækken med ledige billetter i databasen. Da han har læst at der var 4 ledige billetter, og han har bestilt 3, vil han overskrive rækken til kun at have en ledig plads tilbage på flyet, men hovedsagen er jo at transaktion 1, har allerede lavet en bestilling på 2 billetter, så det faktiske antal af ledige billetter er jo nu kun 2. Men fordi at transaktion 2 har læst antallet som 4, vil den transaktion arbejde med det tal, og vi får derfor en Lost Update. Vi har jo nemlig solgt 5 billetter på et fly hvor vi kun havde 4 ledige, og vi har endda en billet mere til gode i vores database. Dette er jo ikke super heldigt, og det er derfor vigtigt at vores DBMS får nogle protokoller/regler for hvordan den skal håndterer dette problem (Mere om dette senere). Lad os først lige se eksemplet som en figur.

Uncommitted Dependency Problem

Figuren ovenover viser hvordan Lost Update syndromet finder sted, og husk på at dette er kun et problem når to brugere samtidigt prøver at læse og ændre i præcis de samme data. Faktisk er problemet med Lost Update syndromet langt 'værre' end man først lige skulle tro, fordi der kan opstå yderligere problemer hvis nu peter valgte at lave et rollback, i stedet for en commit til allersidst i vores eksempel, altså efter at han havde lavet en update til databasen. Sådan et problem kaldes også for en 'Uncommitted Dependency Problem', og betyder ganske enkelt at vi får et 'ikke gennemført afhængigheds problem', med vores data. Lad os lige først tage et eksempel på dette:

1. Vi har 5 ledige flybilletter tilbage, og Peter laver en transaktion i databasen, hvor han begynder bestillingen af 2 fly billetter. Databasen bliver nu opdateret til at indeholde 3 ledige billetter.


2. Josephine vil nu også bestille 3 fly biletter, og begynder derfor bestillingen af disse 3. Databasen bliver nu opdateret til at indeholde 0 ledige biletter.


3. Peter er næsten ved at færdiggøre sin transaktion, men da han skal betale sker der en fejl, fordi Peter ikke har penge nok til at betale for de 2 fly billetter. Peter annullerer nu transaktionen, og databasen begynder på en rollback procedure, som gør at antallet af ledige billetter igen er 5.


4. Josephine Afslutter nu sin bestilling og den bliver nu endeligt commited. Da Josphines transaktion har læst antallet af ledige billetter til tre, og hun nu har bestilt tre, vil vores DBMS opdatere databasen til at indeholde 0 ledige biletter.

Vi har nu fået et 'ikke genneført afhængigheds problem', da Josephines transaktion faktisk var afhængig af om Peters transaktion blev comitted eller ej. Det rigtige antal af ledige billetter skulle jo have været 2, men fordi at Josephines transaktion ikke blev behandlet som var den afhængig af Peters, så vil den opdateres til 0, da hendes transaktion læste antallet af ledige biletter som 3 og ikke 5.

Inconsistent Analysis Problem

Dette problem kan opstå, når vi f.eks. prøver at tilgå og ændre noget data i databasen, samtidig med at en anden er i gang med at læse og bruge de læste data (f.eks. til nogle beregninger eller andet). Lad os f.eks. tage et eksempel, hvor der er en der læser nogle balancer, og herefter summerer dem sammen for at få en total balance. Samtidig prøver en anden transaktion at ændre i nogle af de data, som personen lige har læst. Vores eksempel består af tre konti, der hver har følgende balance - Konto 1 ($1000), Konto 2 ($500), Konto 3 ($400).

1. Peter skal få beregnet det totale balance på tre forskellige kontoer, ved at læse dataende fra databasen og summerer dem. Peter læser først 'Konto 1', og får resultatet $1000. Den totale sum er nu $1000.


2. Peter læser nu 'Konto 2', og får resultatet $500. Den totale sum er nu $1500.


3. Josefine læser nu 'Konto 2', og vælger at flytte $300 fra 'Konto 2', til 'Konto 3'. 'Konto 2' indeholder nu kun $200.


4. Peter læser nu 'Konto 3', og får resultatet $700. Den totale sum er nu $2200.

Problemet er her at Josefine ændrede i balancerne, men ikke ved at fjerne data direkte, men ved at flytte data. Peter læste balancerne til $1000 + $500 + $700 = $2200, men den rigtige balance skulle være læst således, $1000 + $200 + $700 = $1900. $1900 er altså den korrekte total af de tre balancer, men fordi Josefine flyttede $300 fra Konto 2, til Konto 3, efter at Peter havde læst Konto 2, men inden han læste Konto 3, så får vi altså en Inconsistent Analysis Problem, fordi databasen er ikke inkonsistent, det er Peters analyse der er inkonsistent.



Hvad synes du om denne artikel? Giv din mening til kende ved at stemme via pilene til venstre og/eller lægge en kommentar herunder.

Del også gerne artiklen med dine Facebook venner:  

Karma barometer (30 dage)

IT jobs | Kontakt | Om Udvikleren.dk | Om karma | IT nyheds arkiv | Annoncering

X