Niveaux d'isolation

Prérequis : cours précédent (ACID).

Pourquoi

Deux transactions en même temps : que voit chacune ? Trop strict = lent, trop lâche = anomalies (lectures fantômes, argent qui disparaît). Le niveau d'isolation est le curseur — Postgres défaut READ COMMITTED, à monter en connaissance de cause.

Concepts

• Read committed (défaut PG) : on ne voit que du committé, mais re-lire peut changer (non-repeatable read) et les SELECT concurrents peuvent surprendre (pas de fantômes bloqués).
• Repeatable read : image figée de la transaction. Anomalie restante : écriture biaisée (deux transactions lisent puis écrivent sur des critères qui se chevauchent).
• Serializable : comme si séquentiel. En Postgres via SSI (détection de cycles → erreur 40001 à réessayer !). Le plus sûr, avec retries applicatifs.
• Phénomènes : sale (jamais en PG), non-répétable, fantôme, biais d'écriture. Savoir les nommer, c'est choisir le niveau en conscience.

Exemple : le transfert qui exige du sérieux

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance FROM accounts WHERE id = 1;  -- image figée
-- ... contrôles ...
UPDATE accounts SET balance = ... ;
COMMIT;  -- 40001 possible sous SERIALIZABLE : retry applicatif !

Cas réel

Compteurs de stock décrémentés en READ COMMITTED sous pic : deux commandes lisent 1 restant, vendent 2 fois → stock négatif. Passage en contrainte + transaction sérieuse : survente impossible par construction (cf. Architecture 9.2).

Pièges

• SERIALIZABLE sans retry : l'erreur 40001 doit être rejouée, sinon l'app échoue « aléatoirement ».
• Verrous explicites (SELECT … FOR UPDATE) : puissants, à portée minimale et durée minimale — sinon deadlocks (cours suivant).
• Croire que l'ORM gère : la plupart restent en défaut ; le niveau se choisit par transaction, en connaissance.

À retenir

Défaut committed, image figée en repeatable, séquentiel en serializable + retry ; nommer les phénomènes pour choisir.