Isolatieniveaus beschrijven

Voltooid

PostgreSQL heeft drie niveaus van transactieisolatie die drie soorten gelijktijdigheidsconflicten voorkomen, vuile leesbewerkingen, niet-herhaalbare leesbewerkingen en fantoomleesbewerkingen voorkomen.

Typen gelijktijdigheidsconflicten

Vuile leesbewerkingen

Een vuile leesbewerking treedt op wanneer een transactie de bijgewerkte versie van gegevens leest die door een andere transactie wordt bewerkt. Deze update wordt echter nooit doorgevoerd.

Een transactie vindt bijvoorbeeld plaats op een spaarrekening waarmee het saldo van de rekening wordt meegenomen naar minder dan nul. Voordat de transactie wordt doorgevoerd, wordt het rekeningsaldo gecontroleerd en wordt de transactie teruggedraaid omdat spaarrekeningen geen saldo van minder dan nul mogen hebben. Tegelijkertijd wordt een rapport uitgevoerd om het huidige saldo van alle spaarrekeningen weer te geven. Als vuile leesbewerkingen zijn toegestaan, wordt het negatieve saldo geretourneerd, ook al worden deze nooit doorgevoerd.

Niet-herhaalbare leesbewerkingen

Een niet-herhaalbare leesbewerking treedt op als een transactie: gegevens leest, een andere transactie werkt de gegevens bij en de initiële transactie leest de gegevens opnieuw en ziet de nieuwe updates.

Verbinding A start bijvoorbeeld een transactie en leest de kosten per eenheid en het aantal eenheden voor een order, wat een kosten van 10 en het aantal eenheden van 3 is. Verbinding B start vervolgens een andere transactie en werkt dezelfde bestelling bij om de kosten per eenheid in te stellen op 12. In dezelfde transactie als de oorspronkelijke query berekent Connection A de totale kosten voor de order. Als niet-herhaalbare leesbewerkingen zijn toegestaan, retourneert Connection A kosten per eenheid van 10, het aantal eenheden van 3 en de totale kosten van 36, wat uiteraard niet zinvol is.

Phantom leest

Een fantoomleesbewerking treedt op als een transactie: gegevens leest, een andere transactie voegt een nieuwe rij (of rijen) toe aan de gegevens en de initiële transactie leest de gegevens opnieuw en ziet de nieuwe updates.

Verbinding A start bijvoorbeeld een transactie en telt het totale aantal facturen voor de dag in Parijs. Het aantal bedroeg 1100 facturen voor alle 10 winkels in Parijs. Verbinding B start vervolgens een andere transactie en voegt een nieuwe winkel toe in Parijs met 200 facturen voor de openingsdag van de nieuwe winkel. In de transactie Verbinding A telt het systeem nu het aantal winkels om het aantal facturen per winkel te berekenen. Verbinding A verdeelt nu de 1100 transacties door 11 winkels in plaats van de oorspronkelijke 10 die bestond toen de query voor het aantal facturen werd uitgevoerd. Deze berekening retourneert nu een onjuist gemiddelde van 100, ook al had de nieuwe winkel 200 facturen waarvoor Connection A transaction geen rekening heeft gehouden in de gemiddelde berekening.

Isolatieniveaus

Azure Database for PostgreSQL heeft drie isolatieniveaus voor transacties, vastgelegde leesbewerkingen, herhaalbare leesbewerkingen en serialiseerbaar. De niet-verzonden leesbewerking is niet beschikbaar in Azure Database for PostgreSQL.

Hoe isolatieniveaus van invloed zijn op gelijktijdigheidsconflicten:

Isolatieniveau Vuile leesbewerking Niet-herhaalbare leesbewerking Phantom gelezen
Niet-verzonden lezen* Mogelijk Mogelijk Mogelijk
Toegewezen lezen Niet mogelijk Mogelijk Mogelijk
Herhaalbare leesbewerking Niet mogelijk Niet mogelijk Mogelijk
Serialiseerbaar Niet mogelijk Niet mogelijk Niet mogelijk

* Niet beschikbaar in PostgreSQL

Lezen vastgelegd is het standaardisolatieniveau in Azure Database for PostgreSQL. Leesbewerkingen zijn het meest geschikt voor de meeste scenario's, omdat hiermee vuile leesbewerkingen worden voorkomen en goede prestaties worden geboden. Het is mogelijk om niet-herhaalbare leesbewerkingen en fantoomleesbewerkingen te hebben, maar deze voorwaarden kunnen alleen optreden als er meerdere SELECT-instructies tegelijk query's uitvoeren op dezelfde gegevens.

Herhaalbare leesbewerking verschilt van doorgevoerde leesbewerking, omdat meerdere SELECT-instructies binnen een transactie dezelfde resultaten zouden zien, zelfs als een andere transactie de rijen tussen de uitvoering van de twee SELECT-instructies van de transactie heeft bijgewerkt. Als een andere transactie nieuwe rijen invoegt, worden deze rijen niet weergegeven in de resultaten van de tweede SELECT-instructie.

Het serialiseerbare isolatieniveau biedt het hoogste niveau van transactieisolatie en voert uit alsof verschillende transacties in serieel werden uitgevoerd, dat wil gezegd, één na de andere. Het nadeel van serializeerbaar isolatieniveau is dat als een transactie een update uitvoert, andere transacties dit kunnen blokkeren. De serialiseerbare transactie moet wachten totdat de blokkeringstransactie is voltooid, wat van invloed is op de prestaties.

Serialiseerbare transacties kunnen ook geen wijzigingen aanbrengen in rijen die andere transacties wijzigen tijdens de serialiseerbare transactie. Als deze vorm van conflict optreedt, wordt er een foutbericht geretourneerd en daarom is het belangrijk dat er logica voor opnieuw proberen is ingebouwd in toepassingen wanneer serialiseerbare transacties worden gebruikt.

Als u transactieisolatieniveaus wilt bijwerken, gebruikt u de opdracht TRANSACTION ISOLATION LEVEL binnen een transactie.

Voorbeeld:

BEGIN TRANSACTION
TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM humanresources.department
COMMIT;