Niveau d'isolation READ COMMITTED

On va voir ensemble ce que fait le niveau d'isolation READ COMMITTED. Son nom te dit direct que tout ce que tu lis dans une transaction est déjà "committed" par d'autres transactions. C'est un peu comme dans la vraie vie : tu crois que les rumeurs qui sont officiellement écrites dans le procès-verbal.

Plus sérieusement, ce niveau garantit qu'une transaction ne peut pas voir les changements faits par d'autres transactions qui ne sont pas encore validées. Ça règle le souci qu'on appelle "lecture sale" (Dirty Read). Mais attention, les données que tu lis peuvent changer si une autre transaction fait un commit entre tes requêtes. C'est là qu'on peut avoir le problème de "lecture non répétable" (Non-Repeatable Read).

Dans PostgreSQL, le niveau d'isolation READ COMMITTED est activé par défaut. C'est le mode par défaut — t'as rien à configurer de spécial pour l'utiliser.

Exemple d'utilisation du niveau d'isolation READ COMMITTED

Voyons comment ça marche en vrai. Imaginons qu'on a une table accounts qui contient des infos sur les utilisateurs et leurs soldes :

CREATE TABLE accounts (
    account_id SERIAL PRIMARY KEY,
    account_name TEXT NOT NULL,
    balance NUMERIC(10, 2) NOT NULL
);

INSERT INTO accounts (account_name, balance)
VALUES ('Alice', 1000.00), ('Bob', 500.00);

Maintenant, imagine la situation suivante. Session 1 et Session 2 — nos deux héros, tous les deux bossent sur la table accounts. Voilà ce qui se passe :

Session 1 :

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_name = 'Alice';
-- Pas de COMMIT ni de ROLLBACK pour l'instant.

À ce moment-là, 100 unités sont temporairement retirées du balance d'Alice, mais le résultat n'est pas encore validé.

Session 2 :

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

BEGIN;
SELECT balance FROM accounts WHERE account_name = 'Alice';

Résultat : Session 2 voit le solde d'Alice comme 1000.00, parce que la transaction de Session 1 n'est pas encore terminée (COMMIT pas fait). Le niveau READ COMMITTED nous protège de la "lecture sale".

Session 1 termine la transaction :

COMMIT;

Maintenant, le solde d'Alice est mis à jour, et la base de données a bien 900.00 enregistré.

Session 2 refait la requête :

SELECT balance FROM accounts WHERE account_name = 'Alice';

Résultat : maintenant Session 2 voit le nouveau solde d'Alice — 900.00. Fais gaffe, le résultat est différent de la requête précédente qui renvoyait 1000.00. C'est le souci de la "lecture non répétable".

Quand utiliser READ COMMITTED ?

Le niveau d'isolation READ COMMITTED c'est un bon compromis entre perf et cohérence. Mais y'a des cas où il est juste parfait :

1. Opérations CRUD simples : quand tu fais juste des lectures ou des updates sans relations compliquées.

2. Mise à jour de lignes : genre une update massive dans une table où c'est important de voir direct les changements validés.

3. Traitement de transactions : systèmes de paiement où tu veux que les users voient que les données confirmées.

Mais si tu fais des requêtes analytiques complexes ou que tu bosses avec beaucoup de données, tu devrais peut-être regarder un autre niveau d'isolation, genre REPEATABLE READ.

Avantages et inconvénients du niveau d'isolation READ COMMITTED

Le niveau d'isolation READ COMMITTED c'est un peu la voie du milieu. Il te protège des données sales : tu ne verras pas les changements qu'une autre transaction a commencés mais pas terminés. Donc personne ne lit de l'info "crue" qui pourrait être rollback direct.

Ce mode est plus rapide que les niveaux plus stricts (REPEATABLE READ ou SERIALIZABLE), parce qu'il n'a pas besoin de locks compliqués ou de checks en plus. Il est assez léger et fiable — c'est pour ça qu'il est utilisé par défaut et qu'il va super bien pour la plupart des tâches du quotidien.

Même s'il évite la lecture sale, READ COMMITTED ne protège pas contre :

• "Lecture non répétable" (Non-Repeatable Read) : la valeur des données peut changer si une autre transaction fait des modifs entre tes requêtes.
• "Lecture fantôme" (Phantom Read) : une autre transaction peut ajouter des lignes qui vont changer le résultat de ta requête.

Tips pour bosser avec READ COMMITTED

Toujours finir tes transactions : pense à utiliser COMMIT ou ROLLBACK, sinon tu risques d'avoir des soucis de locks.

Vérifie que le niveau d'isolation suffit : si tu veux être sûr que les données ne changent pas pendant ta transaction, regarde du côté de REPEATABLE READ.

Utilise les index : ça aide PostgreSQL à trouver les données plus vite et à appliquer les changements.

Exemple : gestion des commandes

Imaginons qu'on a une table orders où on stocke les infos sur les commandes :

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_name TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'pending'
);

INSERT INTO orders (customer_name, status)
VALUES ('Alice', 'pending'), ('Bob', 'pending');

On veut mettre à jour le statut des commandes qui sont en "pending" :

BEGIN;
SELECT * FROM orders WHERE status = 'pending';
UPDATE orders SET status = 'completed' WHERE status = 'pending';
COMMIT;

Si, pendant l'exécution, une autre transaction ajoute une nouvelle commande avec le statut "pending" et fait un COMMIT, notre transaction ne prendra pas en compte cette ligne, car elle a été ajoutée après le début de la lecture.

C'est un exemple de "lecture fantôme". Si tu veux éviter ça, il faut utiliser SERIALIZABLE.

Le niveau d'isolation READ COMMITTED c'est le choix par défaut pour la plupart des bases de données, y compris PostgreSQL. Il protège contre les lectures sales, ce qui en fait une bonne option pour la majorité des opérations standards. Mais dans les scénarios où tu as besoin d'une cohérence stricte, il te faudra peut-être des niveaux d'isolation plus costauds. Le choix du niveau d'isolation doit dépendre de tes besoins précis et de tes exigences de perf.