Problem med samtidiga transaktioner

1.1 Inledning

Och nu börjar det roliga – teorin om hur transaktioner fungerar. Hur får man systemet att fungera när man ändrar samma data i olika trådar? Eller vill du utföra en transaktion i en annan? Vi kommer att börja leta efter svar på dessa frågor genom att studera isoleringen av transaktioner ...

Transaktionsisoleringsnivån är ett villkorligt värde som bestämmer i vilken utsträckning, som ett resultat av utförandet av logiskt parallella transaktioner i DBMS, inkonsekventa data tillåts. Skalan för transaktionsisoleringsnivåer innehåller ett antal värden, rangordnade från lägsta till högsta; en högre isoleringsnivå motsvarar bättre datakonsistens, men dess användning kan minska antalet fysiskt parallella transaktioner.

Omvänt tillåter en lägre isoleringsnivå fler parallella transaktioner, men minskar datanoggrannheten. Genom att välja vilken nivå av transaktionsisolering som används, ger utvecklaren av informationssystemet, i viss utsträckning, ett val mellan arbetshastigheten och säkerställande av den garanterade konsistensen av data som tas emot från systemet.

Problem med samtidig åtkomst med hjälp av transaktioner

När transaktioner utförs parallellt är följande problem möjliga:

• förlorad uppdatering - om ett datablock ändras samtidigt av olika transaktioner går alla ändringar förlorade, förutom den sista;
• "smutsig" läsning (eng. Dirty read) - läsning av data som lagts till eller ändrats av en transaktion, som sedan inte kommer att bekräftas (återställs);
• icke-repeterbar läsning (eng. icke-repeterbar läsning) - vid omläsning inom samma transaktion ändras tidigare lästa data;
• phantom reads - en transaktion under dess exekvering flera gånger väljer många rader enligt samma kriterier. En annan transaktion mellan dessa hämtningar lägger till rader eller modifierar kolumner i några av raderna som används i den första transaktionens hämtningskriterier och avslutas framgångsrikt. Som ett resultat kommer det att visa sig att samma val i den första transaktionen ger olika uppsättningar av rader.

Tänk på situationer där dessa problem kan uppstå.

1.2 Förlorad uppdatering

Situationen när, när ett datablock ändras samtidigt av olika transaktioner, en av ändringarna går förlorad.

Anta att det finns två transaktioner som körs samtidigt:

I båda transaktionerna ändras värdet på f2-fältet, när det är klart måste värdet på fältet ökas med 45. Faktum är att följande sekvens av åtgärder kan inträffa:

1. Båda transaktionerna läser av fältets aktuella status samtidigt. Exakt fysisk samtidighet krävs inte här, det räcker att den andra läsoperationen i ordning slutförs innan en annan transaktion skriver sitt resultat.
2. Båda transaktionerna beräknar det nya fältvärdet genom att lägga till 20 respektive 25 till det tidigare avlästa värdet.
3. Transaktioner försöker skriva resultatet av beräkningen tillbaka till fält f2. Eftersom det är fysiskt omöjligt att utföra två skrivningar samtidigt, kommer i själva verket en av skrivoperationerna att utföras tidigare, den andra senare. Den andra skrivoperationen kommer att skriva över resultatet av den första.

Som ett resultat kan värdet på f2-fältet, efter slutförandet av båda transaktionerna, inte öka med 45, utan med 20 eller 25, det vill säga en av de dataförändrande transaktionerna kommer att "försvinna".

1.3 "Smutsig" läsning

Läsa data som lagts till eller modifierats av en transaktion som senare inte kommer att genomföras (återställning).

Anta att vi har två transaktioner öppnade av olika applikationer som exekverar följande SQL-satser:

I transaktion 1 ändras värdet för fält f2, och sedan i transaktion 2 väljs värdet för detta fält. Därefter återställs transaktion 1. Som ett resultat kommer värdet som tas emot av den andra transaktionen att skilja sig från värdet som lagras i databasen.

1.4 Ej repeterbar läsning

Situationen då, vid omläsning inom samma transaktion, tidigare lästa data visar sig vara förändrad.

Anta att vi har två transaktioner öppnade av olika applikationer som exekverar följande SQL-satser:

I transaktion 2 väljs värdet för fält f2, sedan i transaktion 1 ändras värdet för fält f2. Om du försöker igen att välja ett värde från fält f2 i transaktion 2 kommer ett annat resultat att erhållas. Denna situation är särskilt oacceptabel när data läses för att delvis modifiera den och skriva tillbaka den till databasen.

1.5 Läsa "fantomer"

Situationen när, vid upprepad läsning inom samma transaktion, samma urval ger olika uppsättningar av rader.

Anta att det finns två transaktioner som öppnas av olika applikationer som kör följande SQL-satser:

Transaktion 2 kör en SQL-sats som använder alla värden i fält f2. Sedan infogas en ny rad i transaktion 1, vilket gör att återexekveringen av SQL-satsen i transaktion 2 ger ett annat resultat. Denna situation kallas fantomläsning (fantomläsning). Det skiljer sig från icke-repeterbar läsning genom att resultatet av upprepad dataåtkomst har förändrats inte på grund av ändringen/raderingen av själva datan, utan på grund av uppkomsten av nya (fantom)data.