Transaction informatique

En informatique, et particulièrement dans les bases de données, une transaction, telle qu'une réservation, un achat ou un paiement, est mise en œuvre via une suite d'opérations qui font passer la base de données d'un état A — antérieur à la transaction — à un état B postérieur et des mécanismes permettent d'obtenir que cette suite soit à la fois atomique, cohérente, isolée et durable (ACID).

La majorité des systèmes de gestion de base de données hiérarchiques comme relationnels du marché permettent de réaliser des transactions atomiques, cohérentes, isolées et durables. Les systèmes NoSQL n'y prétendent pas.

Les propriétés 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.

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 œuvre 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 par lots (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.

Exemple de transaction dans le monde bancaire

Par exemple lors d'une opération informatique de transfert d'argent d'un compte bancaire sur un autre compte bancaire, il y a une tâche de retrait d'argent sur le compte source et une de dépôt sur le compte cible. Le programme informatique qui effectue cette transaction va s'assurer que les deux opérations peuvent être effectuées sans erreur, et dans ce cas, la modification deviendra alors effective sur les deux comptes. Si ce n'est pas le cas l'opération est annulée. Les deux comptes gardent leurs valeurs initiales. On garantit ainsi la cohérence des données entre les deux comptes.

Utilisation dans les bases de données

Les transactions informatiques sont très utilisées dans les SGBD.

Pseudo transactionnel

Cette ancienne technique très pratiquée avec les moniteurs transactionnels comme CICS d'IBM, TDS de BULL, UTM de Siemens, est aujourd'hui très utilisée dans les architectures des applications web, et dans les applications client-serveur.

En effet rien ne ressemble plus à une page web qu'un écran synchrone :

Le problème posé dans ce mode de fonctionnement est qu'il faut quelquefois un enchaînement de plusieurs écrans ou pages pour élaborer une transaction complète ACID. C'est la méthodologie Merise qui a pour la première fois défini ces concepts :

Cette tâche est assimilée à une pseudo-transaction qui d'un point de vue du moniteur est une transaction technique, mais bien sûr pas vraiment fonctionnelle tant que l'enchaînement n'est pas terminé.

Mais :

Questions :

Les réponses des anciens sont aussi celles utilisées aujourd'hui dans les « nouvelles » technologies :

On comprend bien pourquoi si l'on posait des verrous système (SGBD) pendant tout l'enchaînement dont la durée est incontrôlable, le système s'écroulerait. C'est tout l'intérêt du pseudo transactionnel. Mais la stratégie du contrôle d'isolation est fondamentalement fonctionnelle.

La pseudo transaction est donc bien ACID, mais les règles fonctionnelles sont telles que la cohérence entre chaque pseudo-transaction d'un enchaînement est garantie par l'absence de mise à jour de la base de données.

Une application client/serveur bien conçue utilise aussi des pseudo-transactions, mais le contexte est géré dans l'application cliente, ce qui soulage d'autant le serveur. Le schéma type est le suivant :

Ce qui donne N+1 pseudo-transactions.

Voir aussi

Notes et références

  1. ↑ (en) Philip A. Bernstein et Eric Newcomer, Principles of transaction processing, Morgan Kaufmann - 1997, (ISBN 9781558604155)
  2. ↑ Peter McIntyre et al., Pro PHP Programming, Apress, page 127 : «  NoSQL databases, as the name implies, are not classic SQL databases and do not implement the ACID properties. »

Bibliographie