Antwoord

Transacties isolatie beïnvloedt hoe gelijktijdige transacties elkaars wijzigingen zien. Dit is een belangrijk onderdeel van de ACID-eisen. In ANSI SQL zijn er vier basis isolatieniveaus:

• READ UNCOMMITTED — Ziet zelfs niet-gecommitteerde wijzigingen van andere transacties (vuile leesoperaties, dirty reads).
• READ COMMITTED — Ziet alleen gecommitteerde wijzigingen; voorkomt vuile leesoperaties, maar staat niet-herhaalbare leesoperaties toe (non-repeatable reads).
• REPEATABLE READ — Dezelfde gegevens binnen één transactie worden ongewijzigd gezien. Voorkomt vuile en niet-herhaalbare leesoperaties, maar kan leiden tot spookleesoperaties (phantom reads).
• SERIALIZABLE — De strengste, transacties zijn volledig geïsoleerd, alsof ze sequentieel worden uitgevoerd; elimineert alle soorten anomalieën.

De keuze van het niveau hangt af van de vereisten van de applicatie:

• Voor rapportages is vaak REPEATABLE READ of hoger voldoende;
• Voor highload-systemen is de optimale compromis — READ COMMITTED;
• Voor financiën — SERIALIZABLE, ondanks de verminderde prestaties.

Voorbeeld:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Verdere SELECTs zullen "bevroren" waarden zien

Vraag met een twist

"Garandeert het niveau REPEATABLE READ bescherming tegen spookleesoperaties in elke DB?"

Nee. In PostgreSQL en sommige andere DBMS voorkomt het niveau REPEATABLE READ alleen vuile en niet-herhaalbare leesoperaties, maar beschermt niet noodzakelijk tegen spookleesoperaties. In MySQL/InnoDB is REPEATABLE READ in wezen SERIALIZABLE, maar in andere DBMS — niet.

Voorbeeld:

-- Binnen één transactie lezen we SELECT * FROM orders WHERE amount > 100;
-- In een andere transactie wordt een nieuwe waarde met amount > 100 ingevoerd en gecommitteerd
-- De eerste transactie zal bij een herhaalde SELECT een "spook" rij zien, als de isolatie onder SERIALIZABLE ligt

Voorbeelden van echte fouten door gebrek aan kennis van de nuances van het onderwerp

---

Verhaal

De financiële dienst blokkeerde alleen READ COMMITTED voor de prestaties — de gebruiker zag een bedrag dat al door een ander proces was gewijzigd, wat leidde tot een discrepantie in het saldo.

---

Verhaal

In het hotelsysteem kwamen dubbele boekingen van dezelfde kamer voor — transacties isolededen de actueel gemaakte boekingen niet, het niveau was READ COMMITTED.

---

Verhaal

Overgang van MySQL naar PostgreSQL: de ontwikkelaar was gewend dat REPEATABLE READ beschermt tegen spookjes, maar na de migratie kwamen er "vastgelopen" bestellingen aan het licht die niet verwacht werden bij herhaalde aanvragen binnen dezelfde transactie.