Introduction aux niveaux d'isolation des transactions

Imagine que tu bosses dans un café où un serveur vérifie le stock de gâteaux en cuisine, pendant qu’un autre prend une commande de gâteau d’un nouveau client. Dans un monde parfait, ils devraient tous les deux bosser avec les mêmes infos sur le nombre de gâteaux, histoire d’éviter des bugs du genre “double réservation”. Mais dans la vraie vie, il peut y avoir des soucis à cause de l’exécution parallèle des opérations.

Voilà les trois galères principales qui peuvent arriver :

1. Dirty Read (lecture sale) : Une requête voit des modifs faites par une autre, mais pas encore validées. Si ces modifs sont annulées, la première requête se fait avoir comme un étudiant à son premier entretien.

2. Non-Repeatable Read (lecture non répétable) : Une requête lit deux fois les mêmes données, mais entre-temps quelqu’un d’autre les a changées. C’est comme arriver à la gare, regarder les horaires des trains, revenir une minute après — et découvrir que le train a été annulé. Ou alors ton billet a été acheté par quelqu’un d’autre pendant que tu cherchais ta monnaie :)

3. Phantom Read (lecture fantôme) : Une requête voit un sous-ensemble de lignes, mais entre deux exécutions, quelqu’un ajoute de nouvelles lignes qui changent le résultat. C’est comme si ta boîte perdait un appel d’offres, puis toutes les candidatures sauf la tienne et celle de la femme du maire étaient annulées.

Niveaux d'isolation des transactions

Maintenant qu’on connaît les problèmes, il est temps de regarder l’outil que PostgreSQL propose pour les gérer — les niveaux d’isolation des transactions. C’est comme poser des règles pour que les transactions parallèles ne se marchent pas dessus. Plus le niveau d’isolation est élevé, plus tu as de garanties que les transactions ne vont pas se gêner. Mais ça se paie par une baisse de la “vitesse de service”, donc de la perf.

Les niveaux d'isolation dans PostgreSQL

1. Read Uncommitted (Lecture des données non validées) :

   • Permet de lire des changements qui ne sont pas encore validés (ouais, c’est le dirty read dans toute sa splendeur).
   • Dans PostgreSQL, ce niveau est en fait implémenté comme Read Committed, donc il n’est pas vraiment supporté. PostgreSQL refuse de l’implémenter parce que c’est trop craignos.

2. Read Committed (Lecture des changements validés) :

   • Empêche le dirty read.
   • La transaction ne voit que les données validées au moment où elle exécute sa commande.
   • Mais tu peux quand même avoir des Non-Repeatable Read et des Phantom Read.

3. Repeatable Read (Lecture répétable) :

   • Garanti que les données que tu lis ne changeront pas pendant la transaction.
   • Empêche le dirty read et le non-repeatable read.
   • Mais les lignes fantômes sont toujours possibles.

4. Serializable (Sérialisable) :

   • Garanti que les transactions s’exécutent comme si elles étaient faites l’une après l’autre, en série.
   • Empêche les trois problèmes : dirty read, non-repeatable read et lignes fantômes.
   • C’est le niveau le plus strict — et le plus lent — d’isolation.

Pourquoi l'isolation des transactions est importante ?

Imagine une base de données d’un site e-commerce où mille utilisateurs essaient de passer commande en même temps. Sans un niveau d’isolation bien réglé, tu risques d’avoir plein de conflits : des produits “disparus” ou des commandes en double.

Choisir le bon niveau d’isolation aide à gérer la concurrence entre transactions, en trouvant le bon équilibre entre perf et intégrité des données. Par exemple :

• Dans les systèmes d’analytics, on prend souvent les niveaux d’isolation minimaux (genre Read Committed), parce que la précision des données n’est pas toujours critique.
• Dans les systèmes financiers, on préfère le niveau Serializable, pour éviter les erreurs de calcul ou les opérations en double.

Exemples d'utilisation des niveaux d'isolation

1. Read Committed

Ce niveau garantit que tu ne liras jamais des données qui auraient pu être annulées.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;

-- Lire le solde du compte.
SELECT balance FROM accounts WHERE account_id = 1;

-- Si une autre transaction met à jour le solde, ces données seront mises à jour direct.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

2. Repeatable Read

Ce niveau garantit que si tu lis des données, elles resteront inchangées pour toi pendant toute la transaction.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;

-- Lire le solde du compte.
SELECT balance FROM accounts WHERE account_id = 1;

-- Même si une autre transaction met à jour ce solde, tu ne verras pas le changement.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

3. Serializable

À ce niveau, la transaction fonctionne comme si elle était la seule sur le système.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;

-- Lire le solde du compte.
SELECT balance FROM accounts WHERE account_id = 1;

-- Toute autre transaction qui essaie de modifier ces données sera bloquée jusqu’à la fin de ta transaction.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

Comment choisir le niveau d'isolation ?

Le choix du niveau d’isolation dépend de tes besoins :

• Si la vitesse est plus importante que la précision, et que tu peux tolérer les lignes fantômes — prends Read Committed.
• Si la précision compte, mais que tu veux quand même garder de la perf — utilise Repeatable Read.
• Si tu veux une garantie à 100% de la correction des données, même si c’est plus lent — Serializable est fait pour toi.

Fais gaffe ! Les niveaux d’isolation stricts peuvent causer des blocages et ralentir le système. Le mieux, c’est de trouver un compromis entre perf et cohérence des données.

1

Étude/Quiz

Introduction aux transactions, niveau 39, leçon 4

Indisponible

Introduction aux transactions

Introduction aux transactions

Ouvrir