Wat zijn transactie-isolatieniveaus?

Question

Accepted Answer

**Isolatieniveaus** bepalen hoeveel gelijktijdige transacties van elkaar's niet-vastgestelde (of lopende) wijzigingen kunnen zien — waarbij **consistentie** tegen **prestatie/gelijktijdigheid** wordt afgewogen. Hogere isolatie voorkomt meer anomalieën maar verhoogt de vergrendeling/contentie.

## Gelijktijdige anomalieën (wat isolatie voorkomt)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

Dit zijn de problemen die kunnen optreden wanneer transacties gelijktijdig worden uitgevoerd — isolatieniveaus bepalen welke worden voorkomen.

## De vier standaard isolatieniveaus

Elk hoger niveau voorkomt meer anomalieën. **Read Committed** is een veel voorkomende standaard (voorkomt dirty reads); **Serializable** is het strengst (transacties gedragen zich alsof ze één voor één worden uitgevoerd) maar het meest beperkend voor gelijktijdigheid.

## Het isolatieniveau instellen

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## De fundamentele afweging

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## Waarom het belangrijk is

Transactie-isolatieniveaus zijn belangrijke geavanceerde kennis voor het begrijpen van **gelijktijdigheid in databases** — wanneer meerdere transacties gelijktijdig worden uitgevoerd (zoals in elke echte multi-user-applicatie), bepalen isolatieniveaus de afweging tussen gegevensconsistentie en prestatie, dus het begrijpen ervan is waardevol voor het bouwen van correcte, performante gelijktijdige toepassingen.

De kernconcepten zijn de **gelijktijdige anomalieën** (dirty reads, non-repeatable reads, phantom reads — de problemen die ontstaan wanneer transacties elkaars lopende wijzigingen zien) en hoe de **vier isolatieniveaus** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) progressief meer ervan voorkomen.

Begrijpen is belangrijk voor correctheid: het kiezen van een te laag isolatieniveau kan anomalieën toestaan die gegevens beschadigen of verkeerde resultaten opleveren (bijv. het lezen van niet-vastgestelde gegevens die later worden teruggedraaid, of inconsistente lezingen), terwijl te hoog kiezen gelijktijdigheid en prestatie vermindert.

De **fundamentele afweging** — hogere isolatie betekent meer correctheid maar meer vergrendeling/contentie (lagere gelijktijdigheid, mogelijke vertragingen en deadlocks), lagere isolatie betekent meer prestatie maar risico op anomalieën — is het kernidee: u kiest het niveau op basis van de consistentievereisten van de gegevens (kritieke/financiële gegevens kunnen Serializable nodig hebben; de meeste toepassingen gebruiken Read Committed als balans).

Weten dat implementaties variëren (MVCC versus vergrendeling) is ook relevant.

Aangezien gelijktijdigheid inherent is aan echte database-applicaties, en aangezien isolatieniveaus het kritieke evenwicht tussen consistentie en prestatie bepalen (met verkeerde keuzes die ofwel gegevensanomalieën ofwel prestatieproblemen veroorzaken), is het begrijpen van isolatieniveaus — de anomalieën, de niveaus en de consistentie-versus-gelijktijdigheid afweging — waardevol kennis op seniorniveau voor het bouwen van correcte, performante gelijktijdige systemen en een veelgebruikt geavanceerd interviewonderwerp dat het begrip van database-gelijktijdigheid aantoont.