Transaction informatique - Définition

Utilisation dans les bases de données

Les transactions informatiques sont très utilisées dans les bases de données.

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.

Pseudo transactionnel

Cette ancienne technique très pratiquée avec les moniteurs transactionnels comme par exemple 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 :

• la saisie est stockée en local après quelques contrôles basiques de surface,
• et quand on tape sur 'Entrée' l'ensemble des champs saisis est globalement envoyé sur le serveur central qui analyse, traite puis renvoie un nouvel écran ou une nouvelle page.

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 :

• L'enchaînement s'appelle 'Procédure fonctionnelle'
• Le traitement entre deux écrans ou pages s'appelle 'Tâche'.

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 :

• Il n'est pas possible d'utiliser les mécanismes de verrouillage système pour garantir l'isolation d'un enchaînement, sinon le système s'auto-verrouille car de nombreux utilisateurs accèdent en même temps aux mêmes ressources. Les applications client/serveur utilisant les mécanismes de verrouillage des SGBD tombent souvent avec une charge de 20 utilisateurs à cause de cela.
• Il n'est pas possible de renvoyer toutes les données contextuelles déjà acquises (Utilisateur, Droits, Données déjà saisies ou lues) dans l'écran ou la page sinon les échanges deviennent trop lourds.

Questions :

• Comment garantir l'isolation d'un enchaînement de pseudo-transactions ?
• Comment gérer le contexte entre deux pseudo-transactions ?

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

• Il faut gérer un contexte par 'Enchaînement' sur le serveur : dans le SGBD, un fichier ou en mémoire.
• Ce contexte doit avoir un identifiant, et une durée de vie limitée c'est-à-dire s'auto-détruire au bout d'un certain temps.
• Les objets de la base sont marqués d'une date-heure (timestamp) laquelle est modifiée à chaque mise à jour.
• Les objets nécessaires sont lus au cours des différentes tâches.
• L'information acquise utile est conservée dans le contexte : lectures, saisies, messages, notamment la DateHeure de chaque objet lu dont nous allons vérifier l'isolation a posteriori.
• Aucune mise à jour du système persistant (base de données) n'est faite en dehors de la dernière tâche.
• Lors de la dernière tâche, le programme fait ses contrôles d'intégrité fonctionnelle, et vérifie l'isolation des données en comparant la DateHeure des objets du contexte avec celle relue dans la base avant de faire la mise à jour : update where DateHeure=DateHeure-lue. Cette tâche assure les propriétés ACID de l'enchaînement.
• Evidemment, si un autre utilisateur a mis à jour un objet devant rester isolé, l'enchaînement doit être recommencé. En gestion, on peut souvent s'organiser pour que ce cas soit rare.
• S'il devait être nécessaire de réserver l'objet lors de sa lecture, il suffirait de mettre dans sa DateHeure, celle de fin de réservation, par exemple 'Maintenant' + 1/4 heure. Dans ce cas, à la lecture, il faut s'assurer que personne n'a réservé l'objet en vérifiant que sa DateHeure est bien inférieure à 'Maintenant'.
• Il peut être nécessaire de contrôler qu'un objet non mis à jour n'a pas bougé. Dans ce cas, le principe reste le même : on vérifie sa DateHeure.
• Il peut être suffisant de ne contrôler qu'une donnée de l'objet. Dans ce cas, on limitera le test à cette donnée sans se soucier de la DateHeure.
• Dans une base de données, 50% des objets sont de type 'table de code' mis à jour épisodiquement par un administrateur centralisé. Il n'est pas utile de contrôler l'isolation de ces données.
• Il faut savoir évaluer le risque d'une perte d'isolation pendant l'enchaînement, et se limiter à ne contrôler que ce qui est utile.
• Dans la dernière tâche de l'enchaînement, la pseudo-transaction pose normalement et automatiquement tous les verrous système habituels garantissant l'isolation technique de l'ensemble des données mises à jour. Ce traitement ne dure que quelques centièmes de seconde, si bien que les contentions avec les autres utilisateurs sont faibles.

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 :

• N requêtes de lectures
• Manipulations dans la mémoire de l'application cliente
• 1 requête de maj de tous les objets modifiés avec contrôle d'isolation a postériori

Ce qui donne N+1 pseudo-transactions.

Voir aussi

• Mise à jour perdue
• Commit
• Rollback
• Moniteur transactionnel