Hvad er transaktionsisoleringsligninger?

Question

Accepted Answer

**Isoleringsligninger** styrer, hvor meget samtidige transaktioner kan se af hinanden's ubekræftede (eller igangværende) ændringer — hvilket handler om at afveje **konsistens** mod **ydeevne/concurrency**. Højere isolering forhindrer flere anomalier, men øger låsning/konkurrence.

## Concurrency-anomalierne (hvad isolering forhindrer)

```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)
```

Disse er de problemer, der kan opstå, når transaktioner køres samtidigt — isoleringsligninger styrer, hvilke der forhindres.

## De fire standard isoleringsligninger

Hver højere niveau forhindrer flere anomalier. **Read Committed** er en almindelig standard (forhindrer dirty reads); **Serializable** er den strengeste (transaktioner opfører sig, som om de kørte én ad gangen), men mest restriktiv for concurrency.

## Indstilling af isoleringsligningen

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

## Den grundlæggende afvejning

```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.).
```

## Hvorfor det betyder noget

Transaktionsisoleringsligninger er vigtig avanceret viden til at forstå **concurrency i databaser** — når flere transaktioner køres samtidigt (som de gør i enhver rigtig flergbruger-applikation), bestemmer isoleringsligninger afvejningen mellem datakonsistens og ydeevne, så forståelse heraf er værdifuld for at bygge korrekte, performante samtidige applikationer.

Kernebegreberne er **concurrency-anomalierne** (dirty reads, non-repeatable reads, phantom reads — de problemer, der opstår, når transaktioner ser hinandens igangværende ændringer) og hvordan de **fire isoleringsligninger** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) gradvist forhindrer flere af dem.

Forståelse heraf er vigtig for korrekthed: at vælge en for lav isolering kan tillade anomalier, der ødelægger data eller producerer forkerte resultater (f.eks. læsning af ubekræftede data, der senere rollback, eller inkonsistente læsninger), mens at vælge for høj reducerer concurrency og ydeevne.

Den **grundlæggende afvejning** — højere isolering betyder mere korrekthed, men mere låsning/konkurrence (lavere concurrency, potentielle langsomheder og deadlocks), lavere isolering betyder mere ydeevne, men risiko for anomalier — er den vigtigste indsigt: du vælger niveauet baseret på datakonsistenskravene (kritiske/finansielle data kan have brug for Serializable; de fleste applikationer bruger Read Committed som en balance).

At vide, at implementeringer varierer (MVCC vs låsning), er også relevant.

Da concurrency er naturligt i rigtige databaseprogrammer, og da isoleringsligninger styrer den kritiske balance mellem konsistens og ydeevne (med forkerte valg, der forårsager enten dataanomalier eller ydeevneproblemer), er forståelse af isoleringsligninger — anomalierne, ligningerne og konsistens-mod-concurrency-afvejningen — værdifuld seniorniveau-viden til at bygge korrekte, performante samtidige systemer og et almindeligt avanceret interviewtema, der demonstrerer forståelse af databaseconcurrency.