Problemen van gelijktijdige transacties

1.1 Inleiding

En nu begint het plezier - de theorie van hoe transacties werken. Hoe houd je het systeem werkend als je dezelfde gegevens in verschillende threads wijzigt? Of wilt u de ene transactie in de andere uitvoeren? We zullen beginnen met het zoeken naar antwoorden op deze vragen door de isolatie van transacties te bestuderen ...

Het transactie-isolatieniveau is een voorwaardelijke waarde die bepaalt in hoeverre, als gevolg van het uitvoeren van logisch parallelle transacties in het DBMS, inconsistente gegevens zijn toegestaan. De schaal van transactie-isolatieniveaus bevat een aantal waarden, gerangschikt van laag naar hoog; een hoger isolatieniveau komt overeen met een betere gegevensconsistentie, maar het gebruik ervan kan het aantal fysiek parallelle transacties verminderen.

Omgekeerd zorgt een lager isolatieniveau voor meer parallelle transacties, maar vermindert het de nauwkeurigheid van de gegevens. Dus door het niveau van gebruikte transactie-isolatie te kiezen, biedt de ontwikkelaar van het informatiesysteem tot op zekere hoogte een keuze tussen de snelheid van het werk en het waarborgen van de gegarandeerde consistentie van de gegevens die van het systeem worden ontvangen.

Problemen van gelijktijdige toegang met behulp van transacties

Wanneer transacties parallel worden uitgevoerd, zijn de volgende problemen mogelijk:

• verloren update - als één gegevensblok gelijktijdig wordt gewijzigd door verschillende transacties, gaan alle wijzigingen verloren, behalve de laatste;
• "dirty" reading (eng. Dirty read) - het lezen van gegevens die zijn toegevoegd of gewijzigd door een transactie, die vervolgens niet worden bevestigd (teruggedraaid);
• niet-herhaalbaar lezen (eng. niet-herhaalbaar lezen) - bij herlezen binnen dezelfde transactie worden eerder gelezen gegevens gewijzigd;
• fantoom leest - één transactie tijdens de uitvoering meerdere keren selecteert vele rijen volgens dezelfde criteria. Een andere transactie tussen deze ophaalacties voegt rijen toe of wijzigt kolommen van enkele van de rijen die zijn gebruikt in de ophaalcriteria van de eerste transactie en eindigt met succes. Als gevolg hiervan zal blijken dat dezelfde selecties in de eerste transactie verschillende reeksen rijen opleveren.

Overweeg situaties waarin deze problemen zich kunnen voordoen.

1.2 Verloren update

De situatie wanneer, wanneer één datablok gelijktijdig wordt gewijzigd door verschillende transacties, een van de wijzigingen verloren gaat.

Stel dat er twee transacties tegelijkertijd lopen:

In beide transacties verandert de waarde van het veld f2, na voltooiing moet de waarde van het veld worden verhoogd met 45. In feite kan de volgende reeks acties plaatsvinden:

1. Beide transacties lezen tegelijkertijd de huidige status van het veld. Exacte fysieke gelijktijdigheid is hier niet vereist, het volstaat dat de tweede leesbewerking in volgorde is voltooid voordat een andere transactie het resultaat schrijft.
2. Beide transacties berekenen de nieuwe veldwaarde door respectievelijk 20 en 25 op te tellen bij de eerder gelezen waarde.
3. Transacties proberen het resultaat van de berekening terug te schrijven naar veld f2. Aangezien het fysiek onmogelijk is om twee schrijfbewerkingen tegelijkertijd uit te voeren, zal in werkelijkheid een van de schrijfbewerkingen eerder worden uitgevoerd, de andere later. De tweede schrijfbewerking overschrijft het resultaat van de eerste.

Als gevolg hiervan kan de waarde van het f2-veld, na voltooiing van beide transacties, niet met 45 toenemen, maar met 20 of 25, dat wil zeggen dat een van de gegevensveranderende transacties zal "verdwijnen".

1.3 "Vuile" lezing

Gegevens lezen die zijn toegevoegd of gewijzigd door een transactie die later niet kan worden vastgelegd (terugdraaien).

Stel dat we twee transacties hebben geopend door verschillende toepassingen die de volgende SQL-statements uitvoeren:

In transactie 1 wordt de waarde van veld f2 gewijzigd en vervolgens in transactie 2 wordt de waarde van dit veld geselecteerd. Daarna wordt transactie 1 teruggedraaid, waardoor de ontvangen waarde van de tweede transactie afwijkt van de waarde die in de database is opgeslagen.

1.4 Niet-herhaalbare lezing

De situatie wanneer bij het herlezen binnen dezelfde transactie eerder gelezen gegevens gewijzigd blijken te zijn.

Stel dat we twee transacties hebben geopend door verschillende toepassingen die de volgende SQL-statements uitvoeren:

In transactie 2 wordt de waarde van veld f2 geselecteerd en in transactie 1 wordt de waarde van veld f2 gewijzigd. Als u opnieuw probeert een waarde uit veld f2 in transactie 2 te selecteren, krijgt u een ander resultaat. Deze situatie is vooral onaanvaardbaar wanneer de gegevens worden gelezen om deze gedeeltelijk te wijzigen en terug te schrijven naar de database.

1.5 Lezen "fantomen"

De situatie waarin bij herhaald lezen binnen dezelfde transactie dezelfde selectie verschillende reeksen rijen oplevert.

Stel dat er twee transacties zijn geopend door verschillende toepassingen die de volgende SQL-instructies uitvoeren:

Transactie 2 voert een SQL-instructie uit die alle waarden van veld f2 gebruikt. Vervolgens wordt in transactie 1 een nieuwe rij ingevoegd, waardoor het opnieuw uitvoeren van de SQL-instructie in transactie 2 een ander resultaat oplevert. Deze situatie wordt fantoomlezen (fantoomlezen) genoemd. Het verschilt van niet-herhaalbaar lezen doordat het resultaat van herhaalde gegevenstoegang niet is veranderd door het wijzigen/verwijderen van de gegevens zelf, maar door het verschijnen van nieuwe (fantoom)gegevens.