Problemer med samtidige transaksjoner

1.1 Introduksjon

Og nå begynner moroa – teorien om hvordan transaksjoner fungerer. Hvordan holde systemet i gang når du endrer de samme dataene i forskjellige tråder? Eller vil du utføre en transaksjon i en annen? Vi vil begynne å se etter svar på disse spørsmålene ved å studere isolasjonen av transaksjoner ...

Transaksjonsisolasjonsnivået er en betinget verdi som bestemmer i hvilken grad, som et resultat av utførelse av logisk parallelle transaksjoner i DBMS, inkonsistente data tillates. Skalaen for transaksjonsisolasjonsnivåer inneholder en rekke verdier, rangert fra lavest til høyest; et høyere isolasjonsnivå tilsvarer bedre datakonsistens, men bruken kan redusere antallet fysisk parallelle transaksjoner.

Omvendt tillater et lavere isolasjonsnivå flere parallelle transaksjoner, men reduserer datanøyaktigheten. Ved å velge nivået på transaksjonsisolering som brukes, gir utvikleren av informasjonssystemet, til en viss grad, et valg mellom hastigheten på arbeidet og å sikre den garanterte konsistensen av dataene som mottas fra systemet.

Problemer med samtidig tilgang ved bruk av transaksjoner

Når transaksjoner utføres parallelt, er følgende problemer mulig:

• tapt oppdatering - hvis en datablokk endres samtidig av forskjellige transaksjoner, går alle endringer tapt, bortsett fra den siste;
• "skitten" lesing (eng. Dirty read) - lesing av data lagt til eller endret av en transaksjon, som senere ikke vil bli bekreftet (rullet tilbake);
• ikke-repeterbar lesing (eng. ikke-repeterbar lesing) - ved re-lesing innenfor samme transaksjon, endres tidligere leste data;
• phantom reads - én transaksjon under utførelse flere ganger velger mange rader i henhold til de samme kriteriene. En annen transaksjon mellom disse hentingene legger til rader eller endrer kolonner i noen av radene som ble brukt i den første transaksjonens hentingskriterier og avsluttes vellykket. Som et resultat vil det vise seg at de samme valgene i den første transaksjonen gir forskjellige sett med rader.

Vurder situasjoner der disse problemene kan oppstå.

1.2 Mistet oppdatering

Situasjonen når, når en datablokk endres samtidig av forskjellige transaksjoner, går en av endringene tapt.

Anta at det er to transaksjoner som kjører samtidig:

I begge transaksjonene endres verdien av f2-feltet, ved fullføring må verdien av feltet økes med 45. Faktisk kan følgende handlingssekvens forekomme:

1. Begge transaksjonene leser samtidig den nåværende tilstanden til feltet. Nøyaktig fysisk samtidighet er ikke nødvendig her, det er nok at den andre leseoperasjonen i rekkefølge er fullført før en annen transaksjon skriver resultatet.
2. Begge transaksjonene beregner den nye feltverdien ved å legge til henholdsvis 20 og 25 til den tidligere leste verdien.
3. Transaksjoner prøver å skrive resultatet av beregningen tilbake til felt f2. Siden det er fysisk umulig å utføre to skrivinger samtidig, vil i realiteten en av skriveoperasjonene bli utført tidligere, den andre senere. Den andre skriveoperasjonen vil overskrive resultatet av den første.

Som et resultat kan verdien av f2-feltet, når begge transaksjonene er fullført, øke ikke med 45, men med 20 eller 25, det vil si at en av de dataendrende transaksjonene vil "forsvinne".

1.3 "Skitten" lesing

Lese data som er lagt til eller endret av en transaksjon som senere vil mislykkes (rullback).

Anta at vi har to transaksjoner åpnet av forskjellige applikasjoner som utfører følgende SQL-setninger:

I transaksjon 1 endres verdien av felt f2, og deretter i transaksjon 2 velges verdien av dette feltet. Deretter rulles transaksjon 1 tilbake. Som et resultat vil verdien mottatt av den andre transaksjonen avvike fra verdien som er lagret i databasen.

1.4 Ikke-repeterbar avlesning

Situasjonen når tidligere leste data ved omlesing innenfor samme transaksjon viser seg å være endret.

Anta at vi har to transaksjoner åpnet av forskjellige applikasjoner som utfører følgende SQL-setninger:

I transaksjon 2 er verdien av felt f2 valgt, deretter i transaksjon 1 endres verdien av felt f2. Hvis du prøver på nytt å velge en verdi fra felt f2 i transaksjon 2, vil et annet resultat bli oppnådd. Denne situasjonen er spesielt uakseptabel når dataene leses for å delvis endre dem og skrive dem tilbake til databasen.

1.5 Lese "fantomer"

Situasjonen når, under gjentatt lesing innenfor samme transaksjon, det samme utvalget gir forskjellige sett med rader.

Anta at det er to transaksjoner åpnet av forskjellige applikasjoner som utfører følgende SQL-setninger:

Transaksjon 2 utfører en SQL-setning som bruker alle verdiene til felt f2. Deretter settes en ny rad inn i transaksjon 1, noe som fører til at re-utførelsen av SQL-setningen i transaksjon 2 gir et annet resultat. Denne situasjonen kalles fantomlesing (fantomlesing). Den skiller seg fra ikke-repeterbar lesing ved at resultatet av gjentatt datatilgang har endret seg ikke på grunn av endringen/slettingen av selve dataene, men på grunn av oppkomsten av nye (fantom)data.