Transaction informatique - Définition

Introduction

En informatique, et particulièrement en bases de données, une transaction est un événement au cours duquel une base de données passe d'un état A à un état B à la suite d'une multitude d'opérations. Ce peut être par exemple une réservation, un achat, un paiement...

Des mécanismes permettent d'obtenir une suite d'opérations qui soit globalement à la fois atomique, cohérente, isolée et durable (ACID).

• atomique : la suite d'opérations est indivisible, en cas d'échec en cours d'une des opérations, la suite d'opérations doit être complétement annulée (rollback) quel que soit le nombre d'opérations déja bien réalisées.
• cohérente : le contenu de la base de données à la fin de la transaction doit être cohérent sans pour autant que chaque opération durant la transaction donne un contenu cohérent. Un contenu final incohérent entraînera l'échec et l'annulation de toutes opérations de la transaction.
• isolée : lorsque deux transactions A et B sont exécutées en même temps, les modifications effectuées par A ne sont ni visibles par B, ni modifiables par B tant que la transaction A n'est pas terminée et validée (commit).
• durable : d'un point de vue technique, une transaction terminée ne peut pas être remise en cause, annulée ou recouverte. Lorsque deux transactions sont exécutées en même temps, le résultat de la première transaction ne pourra pas être recouvert par la deuxième. Toute tentative de recouvrement entraînera l'annulation des opérations de la transaction fautive.

La majorité des système de gestion de base de données du marché permettent de réaliser des transactions atomiques, cohérentes, isolées et durables.

Les caractéristiques ACID

Le concept de transaction s'appuie sur la notion de point de synchronisation (sync point) qui représente un état stable du système informatique considéré, en particulier de ses données.

Une transaction doit respecter les quatre contraintes suivantes dites ACID :

• Atomicité : Une transaction doit s'effectuer en tout ou rien, c'est-à-dire complètement ou pas du tout ;
• Cohérence : La cohérence des données doit être assurée dans tous les cas, même dans les cas d'erreur où le système doit revenir au précédent état cohérent. La cohérence est établie par les règles fonctionnelles. Exemple : Une transaction immobilière peut durer longtemps. Informatiquement, elle sera considérée comme une procédure fonctionnelle composée de plusieurs transactions informatiques (réservation, proposition d'achat, compromis, acte notarié). Les étapes intermédiaires sont donc gérées fonctionnellement via l'état de l'objet Appartement. Même si la procédure est en cours, entre chaque étape le système reste cohérent. En cas d'abandon de la procédure (une sorte de rollback de la transaction immobilière), les règles fonctionnelles remettent l'appartement en vente. Il existe de nombreux cas de procédure qui ne peuvent pas être traités par une seule transaction informatique. Le concepteur doit spécifier les règles fonctionnelles qui pilotent les changements d'état des objets concernés et gérer manuellement l'équivalent du commit et du rollback de la procédure ;
• Isolation : La transaction va travailler dans un mode isolé où elle seule peut voir les données qu'elle est en train de modifier, cela en attente d'un nouveau point de synchronisation ; le système garantit aux autres transactions, exécutées en parallèle sur le même système, une visibilité sur les données antérieures. Ceci est obtenu grâce aux verrous système posés par le SGBD. L'exemple suivant illustre une isolation plus fonctionnelle mettant en oeuvre un verrouillage applicatif : Un acteur passe un ordre au vu d'un contexte. Ce contexte ne doit pas avoir changé au moment où il valide son ordre, sinon l'ordre peut perdre tout son sens. Pour éviter que le contexte ne change, il est possible de le verrouiller avant de le lire. Mais c'est souvent consommateur de ressources informatiques et gênant pour les autres surtout si la réflexion et la saisie dure plusieurs minutes. En gestion, il est généralement suffisant de simplement vérifier au moment de la mise à jour que le contexte n'a pas changé : de façon optimiste, l'isolation est vérifiée a posteriori ;
• Durabilité : Lorsque la transaction est achevée, le système est dans un état stable durable, soit à l'issue d'une modification transactionnelle réussie, soit à l'issue d'un échec qui se solde par le retour à l'état stable antérieur. La durabilité est souvent en cause dans les traitements batch ou asynchrones de réplication qui produisent des rejets. L'applicatif aval n'a pas le droit de remettre en cause la transaction antérieure qui a émis l'évènement, sinon cela signifierait que cette transaction n'a pas laissé le système dans un état Cohérent. L'applicatif amont doit donc tout bien contrôler avant de diffuser l'information. Lorsque l'architecture fonctionnelle n'est pas pure, il est fréquent qu'il faille malgré tout gérer des rejets. Ces traitements d'exception doivent alors être spécifiés pour que les rejets soient recyclés par une procédure fonctionnelle souvent complexe. D'où l'importance de la cohérence de la transaction par rapport à l'ensemble du système.