Quali sono i livelli di isolamento delle transazioni?

Question

Accepted Answer

I **livelli di isolamento** controllano quanto le transazioni concorrenti possono vedere dei cambiamenti non committati (o in corso) delle altre — facendo un compromesso tra **consistenza** e **performance/concorrenza**. Livelli di isolamento più elevati prevengono più anomalie ma aumentano il locking/contention.

## Le anomalie di concorrenza (cosa previene l'isolamento)

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

Questi sono i problemi che possono verificarsi quando le transazioni vengono eseguite contemporaneamente — i livelli di isolamento controllano quali sono prevenuti.

## I quattro livelli di isolamento standard

Ogni livello più elevato previene più anomalie. **Read Committed** è un default comune (previene dirty reads); **Serializable** è il più severo (le transazioni si comportano come se eseguite una per volta) ma il più restrittivo per la concorrenza.

## Impostazione del livello di isolamento

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

## Il compromesso fondamentale

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

## Perché è importante

I livelli di isolamento delle transazioni sono conoscenze avanzate importanti per comprendere la **concorrenza nei database** — quando più transazioni vengono eseguite simultaneamente (come accade in qualsiasi applicazione multi-utente reale), i livelli di isolamento determinano il compromesso tra consistenza dei dati e performance, quindi comprenderli è prezioso per costruire applicazioni concorrenti corrette e performanti.

I concetti fondamentali sono le **anomalie di concorrenza** (dirty reads, non-repeatable reads, phantom reads — i problemi che sorgono quando le transazioni vedono i cambiamenti in corso delle altre) e come i **quattro livelli di isolamento** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) prevengono progressivamente più di loro.

Comprendere questo è importante per la correttezza: scegliere un livello di isolamento troppo basso può consentire anomalie che corrompono i dati o producono risultati errati (ad esempio leggere dati non committati che successivamente eseguono il rollback, o letture incoerenti), mentre scegliere uno troppo elevato riduce la concorrenza e la performance.

Il **compromesso fondamentale** — isolamento più elevato significa più correttezza ma più locking/contention (concorrenza inferiore, potenziali rallentamenti e deadlock), isolamento inferiore significa più performance ma rischio di anomalie — è l'insight chiave: scegli il livello in base ai requisiti di consistenza dei dati (i dati critici/finanziari potrebbero necessitare Serializable; la maggior parte delle applicazioni usa Read Committed come equilibrio).

Sapere che le implementazioni variano (MVCC vs locking) è altrettanto rilevante.

Poiché la concorrenza è intrinseca nelle applicazioni database reali, e poiché i livelli di isolamento governano il critico equilibrio tra consistenza e performance (con scelte sbagliate che causano anomalie dei dati o problemi di performance), comprendere i livelli di isolamento — le anomalie, i livelli e il compromesso consistenza-vs-concorrenza — è una conoscenza di livello senior preziosa per costruire sistemi concorrenti corretti e performanti e un argomento di intervista avanzato comune che dimostra la comprensione della concorrenza nei database.