Transaction isolation

Wat is transaction isolation?

Transaction isolation bepaalt hoe sterk gelijktijdige transacties van elkaar afgeschermd worden. Een transactie is een groep databasewijzigingen die als één geheel slaagt of faalt. Isolation gaat over wat andere transacties ondertussen mogen zien.

Stel dat twee mensen tegelijk dezelfde factuur aanpassen. Zonder goede isolatie kan de ene wijziging de andere overschrijven, of kan een rapport een tussenstand lezen die later wordt teruggedraaid.

Transaction isolation is de I in ACID-transacties. Ze beschermt tegen vreemde effecten van gelijktijdigheid, maar ze heeft een prijs: meer isolatie betekent vaak meer locks, retries of wachttijd.

Veelgebruikte isolation levels

De precieze werking verschilt per database, maar deze niveaus kom je vaak tegen.

• Read committed. Een transactie leest alleen data die al gecommit is. Dit is in veel databases de standaard.

• Repeatable read. Data die je binnen dezelfde transactie opnieuw leest, blijft consistent voor die transactie.

• Serializable. De database doet alsof transacties één voor één uitgevoerd worden. Dit geeft sterke bescherming, maar kan meer conflicts veroorzaken.

In SQL Server ziet het instellen van een niveau er bijvoorbeeld zo uit:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

Gebruik zulke instellingen gericht. Een hoger niveau maakt je logica niet automatisch beter, het verandert vooral welke conflicten de database moet voorkomen.

Welke problemen voorkomt isolation?

Isolation levels bestaan omdat gelijktijdige transacties anders rare tussenstanden kunnen zien. Denk aan dirty reads, non-repeatable reads en phantom reads.

Een eenvoudig voorbeeld is voorraad. Twee bestellingen zien elk dat er nog één stuk beschikbaar is. Zonder goede controle kunnen ze allebei verkopen, waarna je negatieve voorraad krijgt. Isolation, constraints en applicatielogica moeten samen voorkomen dat dit gebeurt.

Transaction isolation en locks

Databases gebruiken onder meer locks, versies of predicate locking om transacties af te schermen. Een lock zegt tijdelijk: deze rij, pagina of range is in gebruik.

Locks zijn normaal. Ze worden een probleem wanneer transacties lang open blijven, veel rijen raken of elkaar in een kring blokkeren. Dan kom je bij deadlocks en retry policy terecht.

Transaction isolation versus consistency

Consistency zegt dat data na een transactie aan de regels moet voldoen, zoals constraints en referentiële integriteit. Isolation zegt wat andere transacties mogen zien terwijl de transactie bezig is.

Ze werken samen, maar ze zijn niet hetzelfde. Een database kan consistente eindstanden hebben en toch vreemde tusseneffecten tonen als het isolation level te laag staat voor je scenario.

Waar moet je op letten bij transaction isolation

• Hou transacties kort. Lange transacties houden locks langer vast.

• Test met gelijktijdige gebruikers. Veel fouten zie je niet in een single-user test.

• Plan retries. Bij hogere isolatie kan de database een transactie weigeren om consistentie te bewaren.

• Kies per scenario. Een rapport, checkout en batch-update hebben niet dezelfde isolation-behoefte.