Isolatieniveaus

Naast expliciete FOR UPDATE hebben transacties ook aangeboren wiskundige regels die diep in de motor zijn ingebakken en bepalen hoeveel energie er moet worden besteed aan het standaard isoleren van elke individuele interactie. Dit wordt het Isolatieniveau genoemd. In de SQL-wereld kennen we 4 standaardversies, in volgorde van kracht en veiligheid, maar uiteraard het omgekeerde in termen van prestaties.

• READ UNCOMMITTED: Anarchistische waanzin, uw transactie zal elke wijziging zien die door anderen is aangebracht, inclusief tijdelijke gegevens van mensen halverwege hun eigen scripts. Niemand gebruikt het op grote databases vanwege de constante Dirty Read-fouten.
• READ COMMITTED: (standaard voor Postgres). U ziet direct nieuwe gegevens zodra een derde partij een COMMIT uitvoert, maar u kunt het slachtoffer worden van fantoomlezingen (het zien van nieuwe records halverwege uw lange workflows) of een niet-lineair consistent beeld.
• REPEATABLE READ: Zwaarder. Gedurende de duur van je grote tijdvenstersessie "zie" ik dat de database bevroren is op het moment dat mijn zoekopdracht begon, waarbij ik zelfs de officiële commits die door andere mensen zijn gedaan totaal negeer en negeer! Het beschermt tegen het op magische wijze verschijnen van platen en garandeert stabiliteit.
• SERIALIZABLE: God-niveau (super langzaam). Behandelt elke overlappende transactie door ze te blokkeren en serieel in één rij uit te voeren, waarbij de transacties die botsen meedogenloos worden afgebroken, waardoor zelfs de wetenschappelijke mogelijkheid van de geringste botsing bij de wortel wordt geëlimineerd, waardoor een solide 90% van de hoge doorvoer wordt opgeofferd.

Hoe stel je het in?

In plaats van de normale BEGIN; typ je:

BEGIN ISOLATION LEVEL SERIALIZABLE;

-- and you proceed normally with your hermetically sealed isolation
UPDATE products SET stock = 10;
COMMIT;

Of bij sommige varianten en oudere motoren wijst u dit toe na het starten:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Probeer het zelf