Risposta

L'isolamento delle transazioni influisce su come le transazioni simultanee vedono le modifiche reciproche. Questo è una parte importante delle proprietà ACID. In ANSI SQL ci sono quattro livelli di isolamento di base:

• READ UNCOMMITTED — Vede anche le modifiche non confermate di altre transazioni (letture sporche, dirty reads).
• READ COMMITTED — Vede solo le modifiche confermate; previene le letture sporche, ma ammette letture non ripetibili (non-repeatable reads).
• REPEATABLE READ — Gli stessi dati in una transazione vengono visti inalterati. Evita letture sporche e non ripetibili, ma possono verificarsi letture fantasma (phantom reads).
• SERIALIZABLE — Il più rigoroso, le transazioni sono completamente isolate, come se fossero eseguite in sequenza; elimina tutti i tipi di anomalie.

La scelta del livello dipende dai requisiti dell'applicazione:

• Per la reportistica, spesso è sufficiente REPEATABLE READ o superiore;
• Per sistemi ad alto carico, il compromesso ottimale è READ COMMITTED;
• Per questioni finanziarie — SERIALIZABLE, nonostante la riduzione delle prestazioni.

Esempio:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Le successive SELECT vedranno valori "congelati"

Domanda trabocchetto

"Il livello REPEATABLE READ garantisce protezione dalle letture fantasma in qualsiasi DB?"

No. In PostgreSQL e in alcuni altri DBMS, il livello REPEATABLE READ previene solo letture sporche e non ripetibili, ma non protegge necessariamente dalle letture fantasma. In MySQL/InnoDB, REPEATABLE READ è in sostanza SERIALIZABLE, ma in altri DBMS no.

Esempio:

-- In una transazione leggiamo SELECT * FROM orders WHERE amount > 100;
-- In un'altra transazione viene inserito un nuovo valore con amount > 100 e viene confermato
-- La prima transazione alla successiva SELECT vedrà una riga "fantasma" se l'isolamento è inferiore a SERIALIZABLE

Esempi di errori reali a causa della mancanza di conoscenza delle sfumature del tema

---

Storia

Un servizio finanziario ha bloccato solo READ COMMITTED per motivi di prestazioni — l'utente ha visto un importo che era già stato modificato da un altro processo, sono emerse discrepanze nel saldo.

---

Storia

Nel sistema di prenotazione alberghiera si sono verificate doppie prenotazioni della stessa camera — le transazioni non isolavano l'estrazione delle prenotazioni attuali, il livello era READ COMMITTED.

---

Storia

Transizione da MySQL a PostgreSQL: lo sviluppatore era abituato a che REPEATABLE READ proteggesse dalle letture fantasma, ma dopo la migrazione sono comparsi ordini "sospesi" che non ci si aspettava di vedere con richieste ripetute nella stessa transazione.