Envelopper du code dans une transaction est nécessaire. Ce n'est pas suffisant pour rendre l'opération sûre en termes de concurrence.
C'est à ce niveau que les niveaux d'isolation entrent en jeu. Ils définissent ce qu'une transaction est autorisée à observer pendant que d'autres transactions modifient les mêmes données.
Si vous n'y pensez jamais, vous finissez par livrer un système qui est "correct" lors des tests locaux et subtilement erroné sous une charge concurrente.
Pourquoi le Par Défaut N'est Pas Toujours Suffisant
PostgreSQL par défaut à READ COMMITTED. C'est un bon choix par défaut pour de nombreuses charges de travail, mais cela permet encore des schémas qui sont surprenants si la logique de votre application suppose une vue complètement stable des données au sein d'une transaction.
La bonne question n'est pas :
"Avez-vous utilisé une transaction ?"
C'est :
"Quelles anomalies sont encore possibles à ce niveau d'isolation pour cette règle métier ?"
Un Exemple Pratique
Imaginez deux requêtes qui tentent toutes deux de réserver la dernière unité de stock disponible.
Si l'application lit d'abord la disponibilité, puis décide d'écrire ensuite, le comportement concurrent dépend fortement de la structure de la transaction et de l'utilisation de verrouillage ou d'une isolation plus stricte.
Un modèle simplifié ressemble souvent à ceci :
BEGIN;
SELECT quantity
FROM inventory
WHERE sku = 'book-123';
UPDATE inventory
SET quantity = quantity - 1
WHERE sku = 'book-123';
COMMIT;
Que cela soit sûr dépend de la logique environnante, des verrous, des retries et du niveau d'isolation. La seule délimitation de la transaction ne répond pas à la question.
Ce que Font Réellement les Ingénieurs Seniors
Ils choisissent parmi :
- une isolation par défaut plus simple avec un verrouillage soigné
- une logique de retry pour les échecs de sérialisation
- une isolation plus stricte uniquement lorsque la règle métier justifie le coût
C'est une posture beaucoup plus saine que "utiliser toujours sérialisable" ou "le par défaut est probablement suffisant."
Compromis
Une isolation plus stricte peut améliorer les garanties de correctitude, mais elle :
- augmente la contention
- accroît la probabilité de retries de transactions
- peut réduire le débit sous charge
C'est pourquoi l'isolation est un compromis d'ingénierie, et non un choix moral.
Lectures Complémentaires