Qu'est-ce qu'une transaction en base de données ?

Lorsque vous effectuez une requête à l'intérieur d'une base de données (SQL ou NoSQL, peu importe), cette requête va être exécutée, la base de données va être modifiée (ou non) et éventuellement vous retourner des données.

Si jamais, pour X ou Y raison votre base de données rencontre un problème (logiciel, système, matériel ou d'ordre extérieur) à cet instant précis, vous aurez alors à corriger l'incident avant de pouvoir continuer à utiliser vos données avec le dernier état connu.

Disons avant votre dernière requête car l'incident a empêché la requête de finir de s'exécuter.

Théoriquement (hors perte de données dues à l'incident), votre programme pourra être relancé et fonctionner normalement.

Imaginons désormais le même scénario, mais sur une application plus critique comme un système de virements bancaires.

Le scénario

En simplifiant au maximum le système de virement, disons que chaque transfert d'argent nécessite au minimum deux opérations :

• Le retrait de l'argent envoyé sur le compte débiteur
• L'ajout de l'argent reçu sur le compte créditeur

Ces deux opérations successives , représentées de manière logicielles par deux requêtes distinctes à la base de données introduisent une possibilité de perte de l'intégrité des données contenues dans la base.

Imaginons à nouveau que notre serveur de base de données subisse un incident lors de l'opération, il y a deux possibilités :

• Soit l'un des comptes a reçu de l'argent mais personne n'a été débité, le système a donc virtuellement créé de l'argent.
• Soit l'un des comptes à été débité mais l'argent n'a jamais été reçu, il a disparu.

C'est impensable pour un système de gestion financière (mais pas seulement) de laisser la porte ouverte à un tel risque, c'est donc pour cette raison que la majorité des systèmes de gestion de bases de données implémentent une fonctionnalité pour palier à ce problème : les transactions.

Les transactions

Pour comprendre ce mécanisme, il faut que nous revenions rapidement sur un autre concept plus général : l'atomicité.

L'origine du mot "atome" signifie "insécable", et en informatique on parle d'opérations atomiques lorsque plusieurs opérations sont réalisées de manière séquentielles mais indissociables.

Dans notre exemple précédent, c'est exactement ce genre d'opérations (atomiques) dont nous aurions besoin, que le débit et le crédit ne puisse exister l'un sans l'autre.

Et bien pour effectuer un ensemble d'opérations atomiques dans une base de données, nous allons créer une transaction qui va faire en sorte que l'intégrité des données soit conservée même en cas d'incident.

Commit et rollback

Pour simplifier la compréhension, nous allons décomposer la création d'une transaction et des requêtes qu'elle contient en plusieurs étapes :

• Création et configuration d'une nouvelle transaction
• Création d'une copie totale ou partielle de l'état actuel de la base (snapshot) réservée à la transaction
• Exécution de plusieurs opérations atomiques au sein de la transaction, sur les données du snapshot

Et selon le résultat de l'exécution des opérations, deux solutions s'offrent à nous :

• Si tout s'est bien passé, alors on demandera de "commit" le résultat des opérations, le snapshot sera alors "fusionné" avec la base.
• Si un problème est survenu, alors on demandera un rollback, le snapshot sera supprimé et aucune des opérations n'aura été exécutée sur la base de données.

Bien sûr l'implémentation des transactions peut en réalité différer quelques peu de ce fonctionnement, mais le principe général est le même et vous comprendrez donc son importance cruciale dans la gestion des données.

Pour aller plus loin

Pour les plus curieux et curieuses qui se demandent comment plusieurs transactions concurrentes peuvent s'orchestrer et ne pas se marcher dessus, je vous recommande cet article (en anglais) qui explique bien les différentes stratégies misent en place :