Une transaction regroupe plusieurs opérations en une unité : soit elles sont toutes validées, soit aucune ne l’est. PostgreSQL exécute chaque instruction seule dans une transaction implicite, mais BEGIN permet de contrôler explicitement un ensemble cohérent.
Le cycle minimal
BEGIN ouvre la transaction. Les lectures et écritures suivantes voient un état cohérent selon le niveau d’isolation. COMMIT rend les modifications durables et visibles ; ROLLBACK les annule. Après une erreur SQL, la transaction reste généralement en échec jusqu’au rollback : continuer les requêtes sans le gérer ne fonctionne pas.
Exemple métier
Pour transférer un montant, débitez un compte, créditez l’autre et enregistrez l’opération dans la même transaction. Vérifiez les lignes affectées et contraintes avant COMMIT. Si une étape échoue, ROLLBACK évite un débit sans crédit. Les contraintes en base restent indispensables même si le code valide déjà.
Isolation et concurrence
Le niveau par défaut convient à beaucoup de cas, mais deux transactions peuvent modifier les mêmes données. Utilisez verrous explicites ou niveaux plus forts seulement lorsque l’invariant l’exige. Préparez-vous aux deadlocks et erreurs de sérialisation avec des retries bornés et idempotents.
Transactions courtes
N’attendez pas un appel réseau ou une validation humaine au milieu d’une transaction. Les transactions longues retiennent verrous et anciennes versions de lignes, augmentant contention et maintenance. Ouvrez tard, effectuez le minimum, validez tôt. Un SAVEPOINT permet d’annuler une partie sans perdre tout le travail.
FAQ
ROLLBACK annule-t-il un appel API externe ?
Non. Il ne concerne que la base ; utilisez idempotence ou outbox pour coordonner les effets.
Faut-il une transaction pour une seule requête ?
PostgreSQL en crée déjà implicitement.
COMMIT garantit-il que le métier est correct ?
Il garantit la transaction en base, pas la justesse de vos règles.