Problemer med samtidige transaktioner

1.1 Indledning

Og nu begynder det sjove - teorien om, hvordan transaktioner fungerer. Hvordan holder man systemet i gang, når man ændrer de samme data i forskellige tråde? Eller vil du udføre en transaktion i en anden? Vi vil begynde at lede efter svar på disse spørgsmål ved at studere isoleringen af ​​transaktioner ...

Transaktionsisolationsniveauet er en betinget værdi, der bestemmer, i hvilket omfang inkonsistente data er tilladt som følge af udførelsen af ​​logisk parallelle transaktioner i DBMS. Skalaen af ​​transaktionsisolationsniveauer indeholder et antal værdier, rangeret fra lavest til højeste; et højere isolationsniveau svarer til bedre datakonsistens, men dets brug kan reducere antallet af fysisk parallelle transaktioner.

Omvendt giver et lavere isolationsniveau mulighed for flere parallelle transaktioner, men reducerer datanøjagtigheden. Ved at vælge det anvendte niveau af transaktionsisolering giver udvikleren af ​​informationssystemet til en vis grad et valg mellem arbejdshastigheden og sikring af den garanterede konsistens af de data, der modtages fra systemet.

Problemer med samtidig adgang ved hjælp af transaktioner

Når transaktioner udføres parallelt, er følgende problemer mulige:

• mistet opdatering - hvis en datablok ændres samtidigt af forskellige transaktioner, går alle ændringer tabt, undtagen den sidste;
• "dirty" læsning (eng. Dirty read) - læsning af data tilføjet eller ændret af en transaktion, som efterfølgende ikke vil blive bekræftet (rullet tilbage);
• non-repeatable read (eng. non-repeatable read) - når der genlæses inden for samme transaktion, ændres tidligere læste data;
• phantom reads - en transaktion under dens udførelse flere gange vælger mange rækker efter de samme kriterier. En anden transaktion mellem disse hentninger tilføjer rækker eller ændrer kolonner i nogle af rækkerne, der blev brugt i den første transaktions hentningskriterier og afsluttes med succes. Som et resultat vil det vise sig, at de samme valg i den første transaktion giver forskellige sæt rækker.

Overvej situationer, hvor disse problemer kan opstå.

1.2 Mistet opdatering

Den situation, hvor en af ​​ændringerne går tabt, når en datablok ændres samtidigt af forskellige transaktioner.

Antag, at der er to transaktioner, der kører på samme tid:

I begge transaktioner ændres værdien af ​​f2-feltet, efter færdiggørelsen skal værdien af ​​feltet øges med 45. Faktisk kan følgende handlingssekvens forekomme:

1. Begge transaktioner aflæser feltets aktuelle tilstand samtidigt. Præcis fysisk samtidighed er ikke påkrævet her, det er nok, at den anden læseoperation i rækkefølge er afsluttet, før en anden transaktion skriver sit resultat.
2. Begge transaktioner beregner den nye feltværdi ved at lægge henholdsvis 20 og 25 til den tidligere aflæste værdi.
3. Transaktioner forsøger at skrive resultatet af beregningen tilbage til felt f2. Da det er fysisk umuligt at udføre to skrivninger på samme tid, vil en af ​​skriveoperationerne i virkeligheden blive udført tidligere, den anden senere. Den anden skriveoperation vil overskrive resultatet af den første.

Som følge heraf kan værdien af ​​f2-feltet, efter afslutning af begge transaktioner, ikke stige med 45, men med 20 eller 25, det vil sige, at en af ​​de dataændrende transaktioner vil "forsvinde".

1.3 "Beskidt" læsning

Læsning af data tilføjet eller ændret af en transaktion, som senere ikke vil kunne forpligtes (rollback).

Antag, at vi har to transaktioner åbnet af forskellige applikationer, der udfører følgende SQL-sætninger:

I transaktion 1 ændres værdien af ​​felt f2, og derefter i transaktion 2 vælges værdien af ​​dette felt. Derefter rulles transaktion 1 tilbage. Som følge heraf vil værdien modtaget af den anden transaktion afvige fra den værdi, der er gemt i databasen.

1.4 Ikke-gentagelig læsning

Situationen, når tidligere læste data ved genlæsning inden for samme transaktion viser sig at være ændret.

Antag, at vi har to transaktioner åbnet af forskellige applikationer, der udfører følgende SQL-sætninger:

I transaktion 2 vælges værdien af ​​felt f2, derefter i transaktion 1 ændres værdien af ​​felt f2. Hvis du igen prøver at vælge en værdi fra felt f2 i transaktion 2, vil et andet resultat blive opnået. Denne situation er især uacceptabel, når dataene læses for delvist at ændre dem og skrive dem tilbage til databasen.

1.5 Læsning af "fantomer"

Den situation, hvor det samme valg under gentagen læsning inden for samme transaktion giver forskellige sæt rækker.

Antag, at der er to transaktioner åbnet af forskellige applikationer, der udfører følgende SQL-sætninger:

Transaktion 2 udfører en SQL-sætning, der bruger alle værdierne i felt f2. Derefter indsættes en ny række i transaktion 1, hvilket får genudførelsen af ​​SQL-sætningen i transaktion 2 til at give et andet resultat. Denne situation kaldes fantomlæsning (fantomlæsning). Den adskiller sig fra ikke-gentagelig læsning ved, at resultatet af gentagen dataadgang er ændret ikke på grund af ændringen/sletningen af ​​selve dataene, men på grund af fremkomsten af ​​nye (fantom)data.