Hva er transaksjonsisolasjonnivåer?

Question

Accepted Answer

**Isolasjonnivåer** kontrollerer hvor mye samtidige transaksjoner kan se av hverandres ubekreftet (eller pågående) endringer — og balanserer **konsistens** mot **ytelse/samtidighet**. Høyere isolasjon forhindrer flere anomalier, men øker låsing/konkurranse.

## Concurrency-anomaliene (hva isolasjon 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 problemene som kan oppstå når transaksjoner kjøres samtidig — isolasjonnivåer kontrollerer hvilke som forhindres.

## De fire standard isolasjonnivåene

Hvert høyere nivå forhindrer flere anomalier. **Read Committed** er en vanlig standard (forhindrer dirty reads); **Serializable** er den strengeste (transaksjoner oppfører seg som om de kjøres etter hverandre) men mest restriktiv for samtidighet.

## Innstilling av isolasjonnivå

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

## Den fundamentale avveiingen

```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 betyr noe

Transaksjonsisolasjonnivåer er viktig avansert kunnskap for å forstå **concurrency i databaser** — når flere transaksjoner kjøres samtidig (som de gjør i enhver virkelig fleruppsettapplikasjon), bestemmer isolasjonnivåer avveiingen mellom datakonsistens og ytelse, så å forstå dem er verdifullt for å bygge korrekte, ytelsesfylte samtidige applikasjoner.

Kjernekonseptene er **concurrency-anomaliene** (dirty reads, non-repeatable reads, phantom reads — problemene som oppstår når transaksjoner ser hverandres pågående endringer) og hvordan de **fire isolasjonnivåene** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) progressivt forhindrer flere av dem.

Å forstå dette er viktig for korrekthet: å velge et for lavt isolasjonnivå kan tillate anomalier som korrupterer data eller produserer feil resultater (f.eks. å lese ubekreftet data som senere rulles tilbake, eller inkonsistente lesinger), mens å velge for høyt reduserer samtidighet og ytelse.

Den **fundamentale avveiingen** — høyere isolasjon betyr mer korrekthet men mer låsing/konkurranse (lavere samtidighet, potensielle nedturer og deadlocks), lavere isolasjon betyr mer ytelse men risiko for anomalier — er nøkkelinnsikten: du velger nivået basert på datakonsistenskrav (kritisk/finansdata kan trenge Serializable; de fleste applikasjoner bruker Read Committed som en balanse).

Å vite at implementeringer varierer (MVCC vs låsing) er også relevant.

Siden samtidighet er iboende i virkelige databaseapplikasjoner, og siden isolasjonnivåer styrer den kritiske balansen mellom konsistens og ytelse (med feil valg som forårsaker enten dataanomalier eller ytelsesproblemer), er forståelse av isolasjonnivåer — anomaliene, nivåene, og konsistens-vs-samtidighet avveiingen — verdifull senior-nivå kunnskap for å bygge korrekte, ytelsesfylte samtidige systemer og et vanlig avansert intervjutema som demonstrerer forståelse av databasesamtidighet.