Réponse

L'isolation des transactions influence la manière dont les transactions simultanées voient les modifications effectuées par les autres. C'est une partie importante des propriétés ACID. En ANSI SQL, il existe quatre niveaux d'isolation de base :

• READ UNCOMMITTED — voit même les modifications non validées des autres transactions (lectures sales, dirty reads).
• READ COMMITTED — ne voit que les modifications validées ; empêche les lectures sales, mais permet les lectures non répétables (non-repeatable reads).
• REPEATABLE READ — les mêmes données dans une transaction sont vues de manière constante. Évite les lectures sales et non répétables, mais permet les lectures fantômes (phantom reads).
• SERIALIZABLE — le plus strict, les transactions sont complètement isolées, comme si elles étaient exécutées séquentiellement ; élimine tous les types d'anomalies.

Le choix du niveau dépend des exigences de l'application :

• Pour le reporting, il suffit souvent de REPEATABLE READ ou supérieur ;
• Pour les systèmes à haute charge, le compromis optimal est READ COMMITTED ;
• Pour le domaine financier — SERIALIZABLE, malgré la diminution des performances.

Exemple :

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
-- Les SELECT suivants verront des valeurs "gelées"

Question piège

"Le niveau REPEATABLE READ garantit-il une protection contre les lectures fantômes dans toutes les bases de données ?"

Non. Dans PostgreSQL et certaines autres SGBD, le niveau REPEATABLE READ empêche uniquement les lectures sales et non répétables, mais ne protège pas nécessairement contre les lectures fantômes. Dans MySQL/InnoDB, REPEATABLE READ est essentiellement SERIALIZABLE, mais pas dans d'autres SGBD.

Exemple :

-- Dans une transaction, on lit SELECT * FROM orders WHERE amount > 100;
-- Dans une autre transaction, une nouvelle valeur avec amount > 100 est insérée et validée
-- La première transaction, lors d'un SELECT répété, verra une ligne "fantôme" si l'isolation est inférieure à SERIALIZABLE

Exemples d'erreurs réelles en raison d'une méconnaissance des subtilités du sujet

---

Histoire

Un service financier a limité uniquement READ COMMITTED pour des raisons de performance — l'utilisateur a vu un montant déjà modifié par un autre processus, des écarts de solde sont apparus.

---

Histoire

Dans un système de réservation d'hôtels, des doubles réservations d'une même chambre ont eu lieu — les transactions n'isolaient pas le déchargement des réservations actuelles, le niveau était READ COMMITTED.

---

Histoire

Passage de MySQL à PostgreSQL : le développeur était habitué à ce que REPEATABLE READ protège contre les fantômes, mais après la migration, des commandes "bloquées" sont apparues, qui n'étaient pas censées être vues lors de requêtes répétées dans la même transaction.