Le Transactionnel Réparti UV B : Systèmes et Applications répartis Laurence Duchien CNAM-CEDRIC, 292, rue st Martin 75141 Paris Cedex 03 tel : 40 27 25 83 e_mail : duchien@cnam.fr http://cedric.cnam.fr/personne/duchien/poly.html Laurence DUCHIEN - CNAM 1 Le transactionnel réparti
Plan du cours Introduction Exemples de transactions Quelques définitions Les propriétés des transactions L'Atomicité Cohérence (Sérialité) Isolation Durabilité Définition de quelques concepts utiles pour la réalisation de transactions réparties Espace de travail privé Journal des inscriptions Les problèmes liés aux transactions Principe de sérialisabilité Modèle de transaction avec contrôle de concurrence Conflit et dépendance Dépendances entre transactions Construction du graphe de dépendances Règles de création des dépendances Exemple de graphe de dépendance Graphe de dépendance sans circuit Dans un univers réparti Graphe de dépendance en environnement réparti Les solutions apportées au problème de concurrence Le verrouillage à deux phases L'interblocage dans le verrouillage à deux phases Le contrôle de concurrence optimiste L'estampillage L'atomicité Exemple d'écriture d'une transaction avec validation atomique Protocole de validation atomique La validation à deux phases Problèmes liés aux pannes Le pseudo-code du coordinateur Pseudo-code de l'exécutant Phase de Terminaison par dialogue entre les participants La validation à trois phases Idée générale du protocole Gestion des timers Algorithme du coordinateur Algorithme du participant Le protocole de terminaison du (nouveau) coordinateur Algorithme de terminaison d'un participant Laurence DUCHIEN - CNAM 2 Le transactionnel réparti
OSI-TP" Distributed Transaction Processing " Principes généraux de conception Vocabulaire de base Notion de dialogue Arbre de dialogue Arbre des transactions Bibliographie Laurence DUCHIEN - CNAM 3 Le transactionnel réparti
Introduction Objectif => Donner un moyen simple de préserver la cohérence des informations manipulées par des activités concurrentes Transaction atomique ou action atomique: - permet d'isoler chaque activité des effets dûs à la concurrence et aux pannes. - très utilisée dans le domaine des bases de données centralisées et réparties, mais aussi dans les systèmes d'exploitation répartis tolérant les pannes. Deux aspects importants : - Le contrôle de concurrence = permet de synchroniser (coordonner) les activités parallèles de plusieurs applications (transactions) et accède à des objets partagés, - La reprise arrière = mécanisme système de sauvegarde qui assure que les pannes ne peuvent corrompre les données persistantes. Laurence DUCHIEN - CNAM 4 Le transactionnel réparti
Exemples de transactions - Dans la vie courante : négociation d'une transaction commerciale - Dans le monde informatique mise à jour d'une bande magnétique Dernier inventaire Mise à jour inventaire Nouvel inventaire Mise à jour application bancaire mettant à jour une base de données en ligne Un client équipé d'un micro-ordinateur et d'un modem appelle sa banque pour un transfert d'une somme d'argent d'un compte à un autre : 1. retirer (somme, compte1) 2. déposer (somme, compte2) Laurence DUCHIEN - CNAM 5 Le transactionnel réparti
- Système d'objets partagés : Quelques définitions Ensemble d'objets à manipuler localement ou à distance - Actions : Opérations sur les objets - Contraintes d'intégrité : - enregistrement d'un fichier - des données de base de données - des données d'un objet persistant - lire (x), écrire (x, val) - créer, détruire, autres opérations plus complexes Ensemble des relations que doivent vérifier les objets - État cohérent (du système d'objets) Un état du système où les contraintes d'intégrité sont satisfaites -Transaction : Application qui exécute des actions sur les objets Exemple : Transaction T t_début lire(x); écrire (x,val1); écrire (x,val2); t_fin; Laurence DUCHIEN - CNAM 6 Le transactionnel réparti
Les propriétés des transactions 4 propriétés essentielles : - Atomicité : du monde extérieur la transaction apparaît comme indivisible - Cohérence : la transaction ne viole pas les invariants du système - Isolation : les transactions concurrentes n'interfèrent pas entre elles - Durabilité : lorsque qu'une transaction réussit, son résultat est permanent => on appelle l'ensemble de propriétés les propriétés ACID Laurence DUCHIEN - CNAM 7 Le transactionnel réparti
L'Atomicité Forme générale : Pour un observateur extérieur, toutes les opérations associées à l'action atomique sont soit réalisées complètement soit pas du tout. Cas du transactionnel : Il faut garantir qu'en cas de défaillance : - ou bien l'exécution est totale : l'ensemble des actions correspondant à la transaction est complètement effectué et amène la base jusqu'à un nouvel état. - ou bien l'exécution n'a aucun effet sur les objets car l'exécution est impossible: toutes les modifications partielles engagées sont complètement annulées et l'on reste à l'ancienne version Exemple : Soit un fichier de 10 octets et une transaction qui ajoute des éléments dans ce fichier. Si d'autres processus lisent ce fichier pendant la transaction en cours, ils ne voient que les 10 octets d'origine quel que soit le nombre d'octets ajoutés. Lorsque la transaction est validée, le fichier grossit instantanément. Laurence DUCHIEN - CNAM 8 Le transactionnel réparti
Cohérence (Sérialité) Forme générale : Les résultats d'un ensemble d'opérations sont consistants avec les spécifications d'une application. Cas du transactionnel L'objectif est de garder la cohérence de la base d'objets. Une transaction est correcte (constante avec la sémantique de cohérence de l'ensemble des objets) lorsque, exécutée seule, elle amène la base d'un état cohérent à un autre état cohérent. Etat cohérent i Contraintes d'intégrité Transaction T Etat cohérent i +1 Contraintes d'intégrité Exemple : Invariant bancaire : la loi de conservation de l'argent Après tout transfert interne, la somme d'argent en compte doit toujours être la même. Mais pendant un bref instant (le moment de la transaction) cet invariant est violé. La violation n'est pas visible en dehors de la transaction. Laurence DUCHIEN - CNAM 9 Le transactionnel réparti
Isolation Forme générale : Un utilisateur ne peut avoir accès à aucun résultat intermédiaire d'une action atomique avant la terminaison de la totalité de la transaction Cas du transactionnel L'isolation est la propriété qui permet à un ensemble de transactions s'exécutant simultanément (concurremment dans le même environnement) d'apparaître comme s'exécutant de façon indépendante les unes des autres (sérialisables) C'est le travail de contrôle de concurrence proprement dit Exemple : Begin-Transaction Begin-Transaction Begin-Transaction x=0 x=0 x=0 x=x+1 x=x+2 x=x+3 End-Transaction End-Transaction End-Transaction Différents ordonnancements possibles : O1 x=0 x=x+1 x=0 x=x+2 x=0 x=x+3 légal O2 x=0 x=0 x=x+1 x=x+2 x=0 x=x+3 légal O3 x=0 x=0 x=x+1 x=0 x=x+2 x=x+3 illégal Laurence DUCHIEN - CNAM 10 Le transactionnel réparti
Durabilité Forme générale : C'est la propriété qui garantit que les effets d'un ensemble d'opérations ne sont altérés par aucune sorte de panne Cas du transactionnel : Les effets des opérations décidées (validées) définitivement doivent être durables (persistants) même en cas de défaillance (de processeurs ou de communication) La base de données gère des objets persistants Laurence DUCHIEN - CNAM 11 Le transactionnel réparti
Définition de quelques concepts utiles pour la réalisation de transactions réparties Stockage stable : Prévu pour survivre à tout sauf aux catastrophes majeures (raz de marée, tremblement de terre,...) Peut être implanté sur deux disques ordinaires : - chaque bloc du disque 2 est une copie rigoureuse du bloc correspondant du disque 1. - lors de la mise à jour d'un bloc, on commence par mettre à jour et à vérifier le bloc du disque 1, puis celui du disque 2 Lecteur 1 q z b g a e h d q z b g a ' e h d q z b g a ' h d e Lecteur 2 q z b g a e h d q z b g a e h d q z b g a ' e h d Maiva somm de con (a) (b) (c) (b) Le système se plante après la mise à jour du disque 1, mais avant celle du disque 2. Au redémarrage les disques sont comparés bloc après bloc. Quand deux blocs diffèrent, on peut supposer que c'est le disque 1 qui contient les données correctes. (c) La détoriation spontanée d'un bloc est à prendre en compte. On le détecte par une somme de contrôle fausse, on regénère alors le bloc défectueux à partir du bloc correspondant de l'autre disque. Laurence DUCHIEN - CNAM 12 Le transactionnel réparti
Espace de travail privé Quand un processus commence une transaction, on lui donne un espace de travail privé contenant tous les fichiers (objets) dont il a besoin. => Jusqu'à ce que la transaction soit terminée ou abandonnée, toutes ses lectures et écritures se feront dans cet espace. Mais on ne peut pas attribuer à toutes les transactions un espace privé avec copie des fichiers nécessaires. Optimisation : 1) quand un processus lit un fichier, il ne le modifie pas, il n'a pas besoin d'avoir de copie privée. Quand une transaction commence, on lui crée un espace de travail privé composé d'un pointeur vers l'espace de travail de son père. 2) Quand un fichier est ouvert en écriture, il est copié dans l'espace privé. Mais pour éviter une copie complète, on ne copie que son index. L'index est le bloc qui indique où se trouve les blocs du fichiers sur le disque (Unix => i-node). 0 1 2 index 0 1 2 0' 1 2 3' espace de travail privé nouvel index 0' 1 2 3' 1 2 0 1 2 0 0' 3' 1 2 0 0' 3' (a) (b) (c) Laurence DUCHIEN - CNAM 13 Le transactionnel réparti
Journal des inscriptions ou encore liste des intentions (writehead log) - Les fichiers sont réellement modifiés, mais avant que le bloc ne soit changé, on écrit un enregistrement dans le journal (en stockage stable) - Vont y figurer l'indication de la transaction, du fichier et du bloc modifiés ainsi que les anciennes et les nouvelles valeurs. Exemple x=0; y=0; Begin_Transaction x=x+1 y=y+2 x=y*y End_Transaction journaljournaljournal x=0/1 x=0/1 x=0/1 y=0/2 y=0/2 x=1/4 - Si la transaction se termine avec succès, une indication de bonne fin est écrite au journal. Il n'y a pas à mettre à jour les données qui ont été changées au fur et à mesure - Si la transaction se termine prématurément, on utilise le journal pour revenir à l'état initial. Il s'agit d'un repositionnement avec restauration. Laurence DUCHIEN - CNAM 14 Le transactionnel réparti
Les problèmes liés aux transactions Modèle de transaction : T={op1;op2;...;opn} => Programme séquentiel qui manipule des objets au moyen d'opérations indivisibles lire et écrire => indivisibilité des opérations : garantit qu'en cas d'exécution concurrente de deux ou plusieurs opérations, celles-ci sont exécutées les unes après les autres dans un ordre quelconque. => Les objets utilisés dans une transaction ne sont pas indépendants : ils sont liés par un ensemble de relations appelées Contraintes d'intégrité Laurence DUCHIEN - CNAM 15 Le transactionnel réparti
Exemple : Objets x et y avec contrainte y=2x Écritures incohérentes : Transaction T1 : Action 1 : écrire(x, 10) {x=10} Action 4 : écrire(y, 20) {y=20} Transaction T1 : Action 2 : écrire(x, 30) {x=30} Action 3 : écrire(y, 60) {y=60} A la fin de l'exécution : état incohérent {x=30} {y=20} Lectures incohérentes : Transaction T1 : Action 1 : lire(x) Action 4 : lire(y) {x=10} {y=60} Transaction T2 : Action 2 : écrire(x, 30) {x=30} Action 3 : écrire(y, 60) {y=60} Les valeurs lues par T1 sont incohérentes : {x=10} {y=60} Laurence DUCHIEN - CNAM 16 Le transactionnel réparti
Principe de sérialisabilité La cohérence :. Chaque transaction exécutée seule maintient la cohérence. Toute séquence de transactions exécutée dans un ordre quelconque doit conduire à un état cohérent des objets. Tous les états résultant d'une exécution séquentielle en ordre quelconque des transactions sont valides. Exécutions entrelacées :. Une exécution concurrente de transactions avec entrelacement des opérations de lecture et d'écriture permet de gagner sur l'aspect performance.. Il faut malgré tout garder la cohérence sur les objets Une exécution parallèle est dite sérialisable si son résultat est le même que celui obtenu par l'une des exécutions séquentielles. Laurence DUCHIEN - CNAM 17 Le transactionnel réparti
Modèle de transaction avec contrôle de concurrence => Réaliser les lectures dans un espace de travail privé => Régler alors les conflits éventuels On utilise alors des opérations effectuées dans l'espace de travail : action tlire(x) : lecture à partir de la base ou de l'espace de travail si une écriture a déjà eu lieu action préécrire(x,val) : annonce l'intention de modifier la valeur de x Exemple : t_début t_lire(x) préécrire(x,val1) préécrire(x,val2) t_fin /* Validation de la transaction */ écrire(x, val1) écrire(x,val2) Laurence DUCHIEN - CNAM 18 Le transactionnel réparti
Conflit et dépendance Un conflit apparaît entre deux transactions T et T' dès que les conditions suivantes sont vérifiées : - l'une des deux transactions, T' par exemple, exécute une opération op'j sur un objet que T a déjà manipulé par une opération opi - Les deux opérations opi et op'j, dans cet ordre, ne commutent pas, i.e. l'exécution de (opi;op'j) n'est pas équivalente à celle de (op'j;opi) Un conflit impose un ordre sur ces transactions pour que leur exécutions concurrentes soit équivalente à un exécution en série. On exprime cet ordre par une relation de dépendance (->) entre transactions. Pour les opérations lire et écrire, cette dépendance correspond à l'une des trois formes suivantes: T : lire(x) -> T' : écrire(x) T : écrire(x) -> T' : lire(x) T : écrire(x) -> T' : écrire(x) Les deux opérations de lecture commutent : elles n'induisent pas de conflit entre transactions. Laurence DUCHIEN - CNAM 19 Le transactionnel réparti
Dépendances entre transactions L'exécution concurrente d'un ensemble de transactions peut être représentée par un graphe de dépendances : G={T,->} La théorie de la sérialisibilité (Papadimitriou) : Une exécution concurrente de transactions est correcte si et seulement si le graphe de dépendances correspondant est sans circuit => On dit alors que les transactions sont sérialisables Dans le cas d'une exécution "non-sérialisable", il est nécessaire de rejeter des transactions en les annulant de manière à ne conserver que les transactions sérialisables. Laurence DUCHIEN - CNAM 20 Le transactionnel réparti
Construction du graphe de dépendances L'existence d'un conflit entraîne une contrainte sur l'ordre des transactions pour que leur exécution soit sérialisable. Dépendances entre transactions. Dépendance effective : T1 ---->T2 On fixe dès le premier conflit l'ordre entre les 2 transactions. On note par la notation de précédence que T1 passe avant T2.. Dépendance potentielle : T1-----T2 T1 et T2 doivent être traitées dans un certain ordre qu'il n'est pas indispensable de fixer immédiatement (sera fixé au moment de la validation) Transactions vivantes et transactions validées:. Une transaction en cours (vivante) est notée T. Une transaction validée est notée T* Laurence DUCHIEN - CNAM 21 Le transactionnel réparti
Règles de création des dépendances. Dépendance entre une transaction vivante T2 et une transaction validée T1* Règle naturelle : T1*---->T2 Optimisation : règle de Thomas Si entre T1 et T2 il n'existe qu'un conflit d'écriture alors on peut imposer T2---->T1* L'écriture de T2 n'a pas de besoin d'être passée puisque l'on peut imaginer qu'elle a eu lieu avant celle de T1.. Dépendances entre transactions vivantes T1 et T2 - conflit lecture-écriture T1 T2 lire(x); préécrire(x,val) L'utilisation par T1 d'un objet qui sera ensuite modifié par T2 entraîne la dépendance suivante : T1---->T2 Laurence DUCHIEN - CNAM 22 Le transactionnel réparti
- conflit écriture-lecture T1 T2 préécrire(x,val) lire(x); Deux solutions sont possibles : : - T2 prend la valeur actuelle de l'objet (celle avant T1 et T2) et force alors la dépendance T2---->T1 - On met T2 en attente de la validation de T1 et on fournit ensuite à T2 la valeur résultant de l'exécution de T1. On a la dépendance suivante : T1*---->T2 - conflit écriture-écriture T1 T2 préécrire(x,val1) préécrire(x,val2) On ne sait quelle transaction va être validée la première, donc on note l'existence d'une dépendance potentielle : T1----T2 Dès que l'une des deux transactions est validée, la dépendance est fixée et devient selon l'ordre de validation : T1*---->T2 T2*---->T1 Laurence DUCHIEN - CNAM 23 Le transactionnel réparti
Exemple de graphe de dépendance T1 T2 T3 T4 2:préécrire(x) 3:préécrire(x) 5:préécrire(y) 1:lire(x) 8: valider 4:lire(y) 6:lire(z) 7:préécrire(z) T4 2 3 T1* 3 7 T2 5 T3 - L'absence de circuits dans le graphe est une condition suffisante de maintien de la cohérence - il existe des exécutions entrelacées de transactions qui bien que non sérialisables laissent les données dans un état cohérent => instant de rejet d'une transaction :. abandon des transactions qui entraînent la création des circuits,. rejet d'une transaction vivante dès que l'une de ses dépendances conduit à un circuit. Compte-tenu du caractère irréversible de la validation, il suffit que le graphe des transactions validées soit sans circuit pour assurer la sérialisibilité des transactions => rejet uniquement au moment de la validation. Laurence DUCHIEN - CNAM 24 Le transactionnel réparti
Graphe de dépendance sans circuit. L'ordre de sérialisation n'est pas unique puisque le graphe G présente le plus souvent un ordre partiel avec lequel plusieurs ordres totaux sont compatibles. T1 T2 T3 T4 1: lire(x) 2: préécrire(x) 4:préécrire(y) 6:préécrire(z) 3:lire(y) 5:lire(z) 7:valider 8:valider 9:valider 10:valider T1* 2 6 T2* T4* 3 T3* Graphe des dépendances avant validation Les transactions sont sérialisables dans l'ordre suivant : T1 T2 T3 T4 T1 T2 T4 T3 T1 T3 T2 T4 Laurence DUCHIEN - CNAM 25 Le transactionnel réparti
Dans un univers réparti T1 T2 GT1 GD1 x T3 T4 GT2 GD2 y............ T5 T6 GTn GDn z. GT gestionnaire de transaction. GD gestionnaire de données. Une transaction s'adresse à un seul GT. Une donnée x est le plus souvent en copie unique.. x peut-être en copie multiple x1,..., xk dans k noeuds. Laurence DUCHIEN - CNAM 26 Le transactionnel réparti
Graphe de dépendance en environnement réparti. La connaissance du graphe des dépendances des transactions par les gestionnaires de données est partielle T1 T2 T3 T4 2: préécrire(x) 3:préécrire(x) 5:préécrire(y) 1:lire(x) 8:valider 4:lire(y) 6:lire(z) 7:préécrire(z) 2 T4 T1* 7 3 2 T4 T1* 3 8 5 T2 Graphe complet 8 T3 5 T2 T3 Sur le site de y T2 7 Sur le site de x T3 T4 Sur le site de z Graphes partiels : univers réparti avec localisation différente des objets x, y, z. Laurence DUCHIEN - CNAM 27 Le transactionnel réparti
Les solutions apportées au problème de concurrence Deux grandes catégories : Le contrôle continu : Pour toute opération d'accès (lecture ou écriture) on vérifie que la sérialisation reste possible:. Pour toute transaction vivante T qui effectue une nouvelle action. Le graphe de dépendances G*(T) de toutes les transactions validées augmenté de la transaction vivante T et de ses relations de dépendance avec les transactions validées. reste sans circuit Ce qui permet de dire : => La transaction T peut valider à tout instant sans créer de circuit => Toute transaction peut valider à tout instant sans créer de circuit Remarque : Très coûteux => Approche pessimiste (peu utilisée) On vérifie sans cesse la sérialisabilité Laurence DUCHIEN - CNAM 28 Le transactionnel réparti
Le contrôle par certification: On ne recherche l'existence de circuits : - que dans G* le graphe de dépendance des transactions validées - au moment de la validation d'une nouvelle transaction s'il existe un circuit, la transaction qui valide est rejetée Lectures Préécritures Phase de Certification Etape d'écriture dans la base tdébut tfin Point de validation Laurence DUCHIEN - CNAM 29 Le transactionnel réparti
Le verrouillage à deux phases => L'algorithme de contrôle de concurrence le plus ancien et le plus utilisé. Avant d'effectuer une opération de lecture ou d'écriture, une transaction pose un verrou en lecture (resp. en écriture) sur l'objet considéré.. La granularité de l'objet peut être très variable : base, fichier, page, enregistrement,...plus la granularité est fine, plus on permet d'actions en //. Ce verrou est maintenu jusqu'à la fin des opérations d'écriture dans la base. Des verrous sont conflictuels s'ils portent sur le même objet et si au moins un des deux verrous en écriture.. Deux transactions ne peuvent détenir en même temps deux verrous conflictuels. Attributions des verrous : Mode d'accès en cours : Demande d'accès en lecture Demande d'accès en écriture Non verrouillé Verrouillé en lecture Verrouillé en Ecriture Oui Oui Non Oui Non Non Laurence DUCHIEN - CNAM 30 Le transactionnel réparti
Le principe du verrouillage à deux phases Règle : après avoir relâché un verrou, une transaction ne peut plus en obtenir un autre => Deux phases Point de verrouillage Verrous Acquisitions Restitutions 1ère phase 1 ère phase : l'acquisition 2 ème phase Temps Du début jusqu'au point de verrouillage, la transaction acquiert des verrous. 2 ème phase : le relâchement Du point de verrouillage jusqu'à la fin, la transaction réalise des écritures dans la base et relâche les verrous. Laurence DUCHIEN - CNAM 31 Le transactionnel réparti
Remarques générales : - La méthode de verrouillage à deux phases consiste à forcer quelque soit le conflit la dépendance : T1---->T2 si l'action de T1 précède dans le conflit l'action de T2 T2 reste bloquée en attente de la validation de T1 qui peut donc intervenir à tout instant. - l'ordre de la sérialisation correspond à l'ordre chronologique des validations - Les conflits qui existent entre transactions vivantes sont ignorées tant que ces transactions restent bloquées. Résultat : Si toutes les transactions utilisent le verrouillage à deux phases, alors tout ordonnancement formé par leurs entrelacements peut être sérialisé (Eswaran 76) Soit un ordonnancement non sérialisable avec la méthode de verrouillage à deux phases Il existe un circuit dans le graphe de dépendances : Ti-->Tj -->Tk-->...-->Ti a) soit Ti--->Tj alors nécessairement Ti a relâché un verrou avant que Tj ne l'obtienne. b) soit Tj-->Tk-->...->Ti, Tj a relâché un verrou avant que Tk ne l'obtienne et ainsi de suite Les deux situations a et b sont contraire au principe du verrouillage à deux phases. Laurence DUCHIEN - CNAM 32 Le transactionnel réparti
L'interblocage dans le verrouillage à deux phases Le principe classique: T1 détient le verrou en écriture pour l'objet x et souhaite obtenir un verrou pour y T2 détient le verrou en écriture pour l'objet y et souhaite obtenir un verrou pour x Les deux transactions sont interbloquées Solution : détecter l'interblocage et détruire l'une des deux transactions Détecter l'interblocage : trouver un circuit dans le graphe des attentes de ressources ( ou graphe des dépendances réduit aux transactions vivantes) Difficile en univers réparti : suivre les chemins du graphe réparti. Utilisation également de temporisateurs pour limiter les accès aux objets. Si un objet est bloqué pendant plus de T secondes par un même utilisateur, c'est qu'il y a interblocage. Laurence DUCHIEN - CNAM 33 Le transactionnel réparti
Le contrôle de concurrence optimiste Kung et Robinson 1981 Idée : Allez de l'avant et faites tout ce que vous voulez, sans faire attention à ce que font les autres. S'il arrive un pb, on s'en occupe plus tard. Solution : Le contrôle de concurrence optimiste note les lectures et écritures des fichiers. Au moment de la validation, on regarde si chacune des autres transactions a modifié un de ces fichiers. Si c'est le cas la transaction est annulée Résultat : Bien adapté aux implémentations fondées sur les espaces de travail privés. Chaque transaction modifie dans son espace ses fichiers, sans interférer avec les autres. A la fin, les fichiers nouveaux sont soit validés soit abandonnés. Avantages : - absence de blocage - parallélisme maximum (pas d'attente de verrou) Inconvénients : - de temps en temps, il y a échec et la transaction doit être recommencée - en cas de forte charge, la probabilité d'échec augmente Laurence DUCHIEN - CNAM 34 Le transactionnel réparti
L'estampillage Autre solution au problème de concurrence : Association d'une estampille à chaque début de transaction (Reed 1983) Avec l'algorithme de Lamport, les estampilles seront uniques. Chaque fichier possède une estampille de lecture et d'écriture correspondant à la dernière transaction de lecture et d'écriture validée. Si les transactions sont courtes et espacées dans le temps, les estampilles de lecture et d'écriture du fichier auquel tente d'accéder une nouvelle transaction sont plus anciennes que l'estampille de la transaction courante, donc la transaction peut être validée. Si l'ordre est incorrect, une transaction commencée après la transaction en cours, a accédé au fichier et a été validée. Ce la signifie que la transaction courante est actuelle est en retard et doit être interrompue. Exemple : - Soit trois transactions T1, T2, T3 et leurs estampilles respectives T(Tx). T1 a été une transaction longue et a utilisé un fichier FC T2 et T3 démarrent de manière concurrente et vont aussi utiliser FC. On a T(T1)<T(T2)<T(T3) et les estampilles actuelles du fichier Trd et Twr ont pour valeur l'estampille de la dernière transaction (E1) Plusieurs cas de figures : Laurence DUCHIEN - CNAM 35 Le transactionnel réparti
Ecriture Trd(T1) Twr(T1) T(T2) (a) Twr(T1) Trd(T1) T(T2) Ecriture provisoire (b) (c) T(T2) Trd(T3) T(T2) Twr(T3) Abandon (d) Lecture Twr(T1) T(T2) (e) Twr(T1) Ttent T(T2) (f) OK Attente (c) (d) T(T2) Twr(T3) T(T2) Ttent(T3) Abandon Laurence DUCHIEN - CNAM 36 Le transactionnel réparti
L'atomicité Définition : Pour un observateur extérieur, toutes les opérations associées à l'action atomique sont soit réalisées complètement soit pas du tout. Lorsque l'on passe à un monde distribué, il faut mettre en place un mécanisme de coordination permettant de réaliser l'atomicité On définit donc un ensemble de participants: - un site coordinateur (C) - des sites exécutants S1, S2, S3,..., Sn qui enregistrent dans une mémoire stable les opérations pour pouvoir survivre aux pannes Principes des mécanismes de reprise : - travailler sur des copies lors de la phase de préparation, - lorsque que l'on est prêt à effectuer la transaction, chaque objet écrit pendant la phase de préparation est recopié en mémoire stable, - il existe un point de validation (Commit) à partir duquel la transaction sera obligatoirement terminée (les valeurs en mémoire stable sont intégrées de façon définitive) ou abandonnée (tout est défait). Laurence DUCHIEN - CNAM 37 Le transactionnel réparti
Exemple d'écriture d'une transaction avec validation atomique /* Code d'un exécutant : tout se passe bien */ t_début tlire(x) préécrire(x,val1) préécrire(y,val2) t_fin /* Pas de problème pour ce site : début de la phase de validation */ ecrire_stable(x,val1) ecrire_stable(y,val2) /* point de validation */ /* pas de problème pour tous les exécutants */ /* écriture de la mémoire stable dans la base */ écrire (x, val1) écrire (y,val2) /* destruction des informations dans la mémoire stable */ Laurence DUCHIEN - CNAM 38 Le transactionnel réparti
Protocole de validation atomique ACP, Atomic Commitment Protocol Deux possibilités de décision pour tous les participants: - oui : validation ou commit - non : abandon (abort) On atteint un consensus sur l'exécution d'une transaction selon les règles suivantes : 1- Tout participant ayant atteint une décision atteint la même décision que les autres => Tous terminent de façon cohérente 2- Un participant ne peut plus revenir sur sa décision s'il en a émis une => La décision d'un site est irrévocable 3- La décision générale de validation est prise si tous les participants ont voté oui (validation) => La validation n'est atteinte que si tous ont voté oui. 4- Si la décision de tous est la validation et s'il n'y pas de pannes, la validation est réalisée 5- Si la décision générales est validation et qu'il n'y a pas de pannes que l'algorithme peut tolérer => lorsque les pannes sont réparées et s'il n'y a pas de nouvelles pannes la validation est réalisée => pour éviter qu'une indécision perpétuelle ne soit possible Laurence DUCHIEN - CNAM 39 Le transactionnel réparti
La validation à deux phases 1. Le coordinateur fait réaliser par les exécutants un ensemble d'actions sur des copies d'objets 2. Le coordinateur initialise la phase terminale d'une transaction en envoyant un message de demande de vote : C_Prepare en CCR 3. Les exécutants répondent par C_Ready s'ils votent oui ou C_Refuse s'ils votent non 4. Le coordinateur attend toutes les réponses et décide de valider ou d'abandonner par des messages C_Commit ou C_Rollback 5- Après avoir reçu l'ordre de validation, chaque exécutant recopie ses données dans la base de données et peut notifier la fin de la transaction au coordinateur pour ce qui le concerne Laurence DUCHIEN - CNAM 40 Le transactionnel réparti
Problèmes liés aux pannes Trois types de pannes possibles :. Panne du coordinateur. Panne des exécutants. Coupure de réseau Utilisation de délais de garde pour détecter les pannes Terminaison de la validation en cas de panne Délai dépassé chez le coordinateur: cas 1 : Coordinateur en attente de validation exécutant => Décision d'abandon cas 2 : Coordinateur en attente d'acquittement final => répétition (sur demande) du message de validation ou d'abandon Délai de garde dépassé chez un exécutant: cas 1 : En phase de préparation non réponse du coordinateur => Décision d'abandon de l'exécutant cas 2 : Après avoir voté : situation d'incertitude chez un exécutant qui peut durer très longtemps. Laurence DUCHIEN - CNAM 41 Le transactionnel réparti
Notion de phase d'incertitude d'un exécutant Le site Sk ayant notifié sa réponse de vote "oui" ne reçoit pas de réponse du coordinateur en raison de pannes => il ne sait pas s'il doit valider ou abandonner Exemple :. Coupure de Sk du reste du réseau. Relation de Sk avec seulement des sites en états d'incertitudes. Pannes de Sk en état incertain et réparation. Pannes du coordinateur Solutions : => se reconnecter avec le coordinateur opérationnel (après réparation) => dialogue entre exécutants : certains sites peuvent connaître le statut de la transaction Laurence DUCHIEN - CNAM 42 Le transactionnel réparti
Traitement de reprise après panne Reprise après panne du coordinateur Reprise dans la phase préparatoire avant diffusion du statut de la transaction : => abandonner la transaction, recommencer Reprise après décision prise de valider ou d'abandonner => ne rien faire Reprise après panne chez un exécutant Reprise encore dans la phase préparatoire => abandon de la transaction Reprise après abandon (message envoyé ou non) => ne rien faire Reprise après validation (message envoyé ou non) => traitement identique à celui décrit précédemment concernant la phase d'incertitude Reprise en état de décision connue (transaction validée ou abandonnée) => ne rien faire Laurence DUCHIEN - CNAM 43 Le transactionnel réparti
Le pseudo-code du coordinateur Début /* Début de transaction -- phase 1 */ Envoyer C_Begin à tous les exécutants Envoyer les opérations à effectuer à tous les exécutants /* Réaliser la préparation de la transaction */ Envoyer C_Prepare à tous les exécutants Ecrire_stable début_validation (ident_transaction) Armer_délai_réponse Attendre (événement) Si retombée_garde ou C_Refuse alors /* un ou plusieurs sites n'ont pas répondu ou refusent la transaction */ Ecrire_stable abandon (ident_transaction) /* Début phase 2*/ Envoyer C_Rollback à tous les exécutants Finsi; Si tous les exécutants ont voté C_Ready alors Ecrire_stable validation (ident_transaction) Finsi Envoyer C_Commit à tous les exécutants Laurence DUCHIEN - CNAM 44 Le transactionnel réparti
Pseudo-code de l'exécutant début_phase 1 /* Commencer une transaction */ Attendre (Événement) Si message C_Begin alors Armer (délai de garde) Attendre (Evenement) Si message_opération alors vérouiller les données nécessaires; faire les tests de cohérence effectuer les calculs ranger les résultats en mémoire stable fsi Si délai de garde alors abandon Armer (délai de garde) Attendre (Evenement) Si message C_Prepare Si tout OK alors envoyer message C_Ready sinon envoyer message C_Refuse fsi fsi Si délai de garde alors exécuter programme de terminaison fin_phase 1 - début_phase 2 Armer (délai de garde) Attendre(événement) Si message C_commit alors valider définitivement le résultat déverrouiller la base fsi Si message C_Rollback alors détruire les résultats en mémoire stable déverrouiller la base fsi fin_phase 2 Laurence DUCHIEN - CNAM 45 Le transactionnel réparti
Phase de Terminaison par dialogue entre les participants Algorithme du demandeur de statut de la transaction début envoyer Demande_Statut (transaction) à tous armer (délai de garde) attendre (événement) si message réponse C_Commit alors écrire en mémoire stable (validation (ident_transaction)) écrire définitivement les modifications fin_si si message réponse C_Rollback alors écrire en mémoire stable (abandon(ident_transaction)) détruire les modifications en mémoire stable fsi si retombée délai de garde alors incertitude non encore levée -- recommencer fsi fin terminaison demandeur Laurence DUCHIEN - CNAM 46 Le transactionnel réparti
Algorithme du répondeur début attendre (événement) si message Demande_Statut alors si le site a voté non ou a un enregistrement abandon alors envoi C_Roll_Back sinon si le site a un enregistrement validation (ident_transaction) alors envoyer (C_Commit) sinon /* le répondeur est lui-même dans une période incertaine*/ fsi fsi fsi fin Terminaison_répondeur Laurence DUCHIEN - CNAM 47 Le transactionnel réparti
La validation à trois phases Les deux propositions suivantes sont les règles de base dans l'élaboration d'un protocole atomique: - Si des liens de communication ou des machines tombent en panne, alors le protocole atomique peut se bloquer. - Aucun protocole atomique ne peut garantir un recouvrement indépendamment des processus tombés en panne. => Le protocole à deux phases peut se bloquer dans le cas de panne de sites. La phase de terminaison ne peut s'exécuter si tous les sites sont dans un état incertain. Définition d'une première version du protocole à trois phases : Seules les pannes de sites sont gérées, pas les pannes de liens. Ce qui veut dire : 1- Tous les processus opérationnels peuvent communiquer les uns avec les autres 2- Un processus p attendant un message de q et dont le timer tombe, sait que q est en panne. De plus aucun autre processus ne peut communiquer avec q La règle de non-blocage que l'on applique dans le protocole à trois phases est la suivante : Si il existe un processus opérationnel dans un état incertain, alors aucun processus (qu'il soit opérationnel ou en panne) ne peut avoir décidé de commuter. Dans le protocole à deux phases, si des processus opérationnels sont incertains, ils sont bloqués, ils ne peuvent pas décider d'abandonner parce qu'ils savent que les processus en panne avaient pu décider une validation avant de tomber en panne. Laurence DUCHIEN - CNAM 48 Le transactionnel réparti
Idée générale du protocole 1. Le coordinateur envoie à la fin de la première phase une demande de vote (C_Prepare) 2. Quand un participant reçoit une demande de vote, il répond oui (C_Ready) ou non (C_Refuse). Si un participant vote non, il décide alors d'abandonner et d'arrêter. 3. Le coordinateur collecte le vote de tous les participants. Si l'un d'entre eux vote non, le coordinateur abandonne et envoie un message d'abandon à tous (on reste dans le cadre du protocole à deux phases. Dans le cas où tous votent oui, le coordinateur envoie une pré-validation (Pré_Commit) à tous les participants. 4. Un participant ayant voté oui attend un message de pré validation ou d'abandon du coordinateur. - S'il reçoit un abandon, le participant décide d'abandonner et arrête. - S'il reçoit un Pré_Commit, il répond par un message d'acquittement (ACK) au coordinateur. 5. Le coordinateur collecte les acquittements et envoie la validation (C_Commit) vers tous et arrête. 6. Un participant attend un message de validation du coordinateur (C_Commit). Quand il reçoit ce message, il décide de valider et d'arrêter. Laurence DUCHIEN - CNAM 49 Le transactionnel réparti
Les messages reçus à l'étape 5 et 6 ont une propriété particulière : Ils sont connus par le récepteur avant d'être reçu. A l'étape 5, le coordinateur sait qu'il peut recevoir seulement ACK A l'étape 6, un participant sait qu'il peut seulement recevoir le message de validation (Commit). => Leur but est d'informer les récepteurs de l'occurrence de certains événements - La réception d'un Ack du participant p indique au coordinateur que p n'est plus incertain. Comme une validation est envoyée après réception de tous les ack, un participant lorsqu'il reçoit un commit sait qu'aucun participant n'est plus incertain. => il peut décider de valider sans violer la règle de non-blocage. Laurence DUCHIEN - CNAM 50 Le transactionnel réparti
Gestion des timers Il y 5 endroits où un processus attend un message dans le protocole à 3 phases : (a) - à l'étape 2 les participants attendent une demande de vote (b) - à l'étape 3 le coordinateur attend les différents votes (c) - à l'étape 4 les participants attendent soit une pré-validation, soit un abandon (d) - à l'étape 5 le coordinateur attend un acquittement (e) - à l'étape 6 le participant attend une validation (a) et (b) sont gérés comme dans le protocole à deux phases => Aucun processus n'a décidé de valider - dans le cas (a) le participant décide simplement d'arrêter - dans le cas (b) le coordinateur devra envoyer un abandon à tous les participants qui ont voté oui. - dans le cas (d) le timer du coordinateur arrive expiration parce qu'un ou plusieurs participants sont "tombés" avant d'envoyer un acquittement. Le coordinateur ne sait pas si les participants sont tombés avant ou après avoir reçu une pré-validation. Mais il sait que les participants ont voté Oui et ils se sont préparés à décider de valider. => il ignore la panne et décide alors d'envoyer un message de validation (commit) vers les participants opérationnels. Lorsque les participants en panne reviennent, ils seront responsable de leur retour à l'état commit. Laurence DUCHIEN - CNAM 51 Le transactionnel réparti
Les case (c) et (e) sont plus gênants : Les processus ne peuvent agir de manière autonome, ils doivent communiquer avec d'autres processus pour prendre une décision cohérente Soit le cas suivant : Le coordinateur est tombé en panne après avoir envoyé vers p une pré-validation, mais avant de l'avoir envoyer à q. p (dans le cas e) a dèja reçu une pré-validation et n'est donc plus dans l'incertain. Il sait que seul un commit est possible venant du coordinateur. q (dans le cas c) est dans la période incertaine. => Avant de valider p doit être sûr que tous les participants ont reçu un pre-commit et sont donc hors de la période d'incertitude. => Utilisation d'un protocole de terminaison Laurence DUCHIEN - CNAM 52 Le transactionnel réparti
On définit quatre états possibles d'un processus en fonction des messages envoyés ou reçus : abandon : le processus n'a pas voté, a voté non, ou a reçu un message d'abandon incertain : le processus est dans une période d'incertitude validable : le processus a reçu un Pré-Commit mais n'a pas encore reçu de Commit validé : le processus a reçu un Commit. Laurence DUCHIEN - CNAM 53 Le transactionnel réparti
Le protocole de terminaison travaille comme suit : - Quand un participant a un timer qui arrive à expiration dans le cas (c) ou (e), il initialise un protocole d'élection pour définir un nouveau coordinateur. - Le nouveau coordinateur, une fois élu, envoie un message de demande d'état à tous les processus qui ont participé à l'élection - Chaque processus envoie son état au nouveau coordinateur - Le coordinateur collecte ces états et agit selon les règles de terminaison suivantes: TR1 : Si un processus est dans l'état abandon, le coordinateur décide d'abandonner envoie un message d'abandon à tous. TR2 : Si un processus est dans l'état vlaidé, le coordinateur décide de valider. Il envoie un message de validation à tous et arrête. TR3 : Si tous les processus indiquent qu'ils sont dans l'état incertain, le coordinateur décide d'abandonner et envoie des message d'abandon à tous TR4 : Si tous les processus sont validable, mais aucun n'a été validé, le coordinateur envoie des messages Pre_Commit à tous les processus qui ont indiqué qu'ils étaient dans l'état incertain, attend leur acquittement, et envoie ensuite le message de validation. Laurence DUCHIEN - CNAM 54 Le transactionnel réparti
Algorithme du coordinateur Début Envoyer à tous une demande de vote (C_Prepare) à tous Écrire début protocole 3PC dans le journal des transactions armer timer Attendre (événement) Si timer expire alors Écrire abandon dans le journal des transactions envoyer abandon à tous les processus qui avaient voté oui fsi Si tous les messages reçus = Oui et coordinateur est d'accord alors envoyer un pre_commit à tous les participants armer timer Attendre (événement) /* (message d'acquittement de tous les participants) */ Si timer expire alors ignorer les pannes fsi Écrire Validation dans le journal des transactions envoyer un Commit à tous les participants fin sinon / * quelques participants ont voté non */ Écrire Abandon dans le journal des transactions envoyer Abort à tous les participants fsi Laurence DUCHIEN - CNAM 55 Le transactionnel réparti
Algorithme du participant Début Armer timer Attendre (événement) Si timer expire alors écrire abandon dans le journal des transactions ; retour fsi Si message=c-prepare et tout OK alors écrire Oui dans le journal des transactions envoyer le message "Oui" au coordinateur Armer timer Attendre (événement) /* pre-validation ou abandon*/ Si timer expire alors initialiser le protocole d'élection Si élu alors appel de l'algorithme de terminaison du coordinateur sinon appel de l'algorithme de terminaison du participant Fsi retour; Fsi Si message reçu = Pre_Commit alors début envoyer un ack au coordinateur Armer timer Attendre (événement) /* Validation*/ Si timer expire alors initialiser le protocole d'élection Si élu alors appel de l'algorithme de terminaison du coordinateur ; retour; sinon appel de l'algorithme de terminaison du participant; retour; Fsi écrire Commit dans le journal des transactions sinon /* abandon a été reçu du coordinateur */ écrire abandon dans le journal des transactions sinon /* Le vote du participant est non */ envoyer Non au coordinateur écrire abandon dans le journal des transactions Fsi Fin Laurence DUCHIEN - CNAM 56 Le transactionnel réparti
Le protocole de terminaison du (nouveau) coordinateur Begin Envoyer une demande d'état à tous les participants Attendre les messages de rapports de tous les participants /* on ignore les pannes */ Si un message a pour valeur "Abandon" ou si le coordinateur est dans un état d'abandon alors début /* Cas TR1*/ si journal du coordinateur ne contient pas de message d'abandon alors écrire abandon dans le journal fsi envoyer Abort vers tous les participants sinon si un message a pour valeur Validation ou que le coordinateur est dans l'état validé alors début /* cas TR2*/ si le journal des transactions du coordinateur ne contient pas d'enregistrement de validation alors écrire validation dans le journal fsi envoyer Commit vers tous les participants sinon si tous les messages de rapports étaient dans l'état incertain et que le coordinateur est dans l'état incertain aussi alors début /* cas TR3*/ écrire abandon dans le journal envoyer Abort vers tous les participants sinon /* Quelques processus sont validables */ envoyer un Pre_commit vers tous les participants qui ont répondu par l'état incertain Attendre les acquittements de tous ces processus Écrire validation dans le journal des transactions envoyer un Commit vers tous les participants fsi Laurence DUCHIEN - CNAM 57 Le transactionnel réparti
Algorithme de terminaison d'un participant Début Start :Armer(timer) Attendre une demande d'état du coordinateur Si expiration du timer alors Initialiser le protocole d'élection si élu alors commencer l'algorithme du nouveau coordinateur fsi fsi Si le processus n'a pas voté ou a voté non ou a reçu un abandon alors Etat = Abandon sinon Si le processus a reçu une validation alors état=validé sinon Si le processus a reçu une pré-valisation alors état= validable sinon état=incertain; envoyer l'état au coordinateur Armer(timer) Attendre une réponse du coordinateur Si expiration du timer alors Initialiser le protocole d'élection si élu alors commencer l'algorithme du nouveau coordinateur sinon goto start fsi Fsi Si réponse = abandon alors si le journal ne contient pas d'enregistrement abandon alors écrire abandon dans le journal des transactions fsi Sinon si réponse=commit alors si le journal ne contient pas d'enregistrement validation alors écrire validation dans le journal des transactions fsi Sinon /* la réponse = Pré-Validation */ envoyer un ack au coordinateur Armer(timer) Attendre une validation du coordinateur Si expiration du timer alors Initialiser le protocole d'élection si élu alors commencer l'algorithme du nouveau coordinateur sinon goto start fsi fin Écrire validation dans le journal des transactions fin Laurence DUCHIEN - CNAM 58 Le transactionnel réparti
Laurence DUCHIEN - CNAM 59 Le transactionnel réparti
OSI-TP" Distributed Transaction Processing " Principes généraux de conception a) Définir un environnement de support de transactions réparties. - Organiser une transaction sous forme d'un arbre. - Fournir une coordination "multi-partie" des ressources. - Permettre suite à une panne la restauration d'un état cohérent. - Détecter les pannes (communications, systèmes,... ). - Permettre de redémarrer une transaction suite à une restauration. - Indiquer la bonne ou la mauvaise fin d'une transaction. b) Fournir la possibilité de délimiter et de structurer un ensemble de transactions apparentées logiquement - Permettre le regroupement de transactions à l'intérieur d'une application - Permettre l'organisation en arbre des transactions. c) Supporter différentes politiques de contrôle de concurrence. - Le protocole considère qu'il n'est pas de son ressort de choisir une technique de contrôle de concurrence mais simplement d'offrir les moyens à un utilisateur d'implanter la sienne... (grande variété des méthodes, performances) d) Offrir des moyens de contrôle d'accès - Supporter différentes politiques de contrôle d'accès (au moins celles définies dans la recommandation de sécurité 7498-2). - Classifier les objets dans des groupes afin de faciliter le contrôle d'accès. - Authentifier les activités utilisatrices. - Permettre la non répudiation à la participation à une transaction. Laurence DUCHIEN - CNAM 60 Le transactionnel réparti
Vocabulaire de base - Une application utilisatrice du service transactionnel: TPSU : Transaction Processing Service User. - L'objet exécution d'une application utilisatrice sur un site donné: TPSUI : Transaction Processing Service User Invocation. - Le prestataire du service transactionnel TPSP : Transaction Processing Service Provider Laurence DUCHIEN - CNAM 61 Le transactionnel réparti
Notion de dialogue - Un traitement transactionnel est constitué par un ensemble de dialogues entre entités utilisatrices paires : - qui communiquent entre elles dans une relation point à point. - Au moyen d'un "dialogue" deux entités utilisatrices ("TPSUI") peuvent :. échanger des données.. notifier des erreurs.. réaliser une transaction (valider, invalider... ). ordonner la fin du dialogue. se synchroniser (en fonction des besoins). - Modes de contrôle des dialogues. Mode polarisé ("Polarized control mode") Un utilisateur (TPSUI) contrôle le dialogue à un instant donné Il doit disposer d'un jeton (voir le service de session) pour réaliser des opérations autres qu'urgentes (notification d'erreurs, reprise (rollback), terminaison non négociée). Mode Partagé ("Shared mode") Les deux TPSUI possèdent le contrôle du dialogue simultanément. Les dialogues sont donc réalisés sans contrôle de jeton. Laurence DUCHIEN - CNAM 62 Le transactionnel réparti
Arbre de dialogue C'est un arbre qui a comme noeuds les entités utilisatrices et comme arcs les dialogues ("dialogue branch"). Branche de dialogue A B C D Sous-arbre d'une transaction emboitée dans l'arbre global Exemple: Le site A (direction) interroge B (comptabilité) pour connaître le montant des ventes du mois de l'entreprise. Les ventes sont réalisées dans deux divisions qui ont leurs propres systèmes de gestion C et D. B créé une transaction emboîtée à l'intérieur de la transaction demandée par A pour collecter les chiffres nécessaires. Laurence DUCHIEN - CNAM 63 Le transactionnel réparti
Niveau de coordination d'un dialogue A) Si l'opération d'un dialogue est simple. Exemple l'interrogation consiste en une simple lecture (comme celle de A vers B). Son niveau de coordination de dialogue peut-être sans contrôle "NONE". les propriétés ACID sont prises en charge par l'utilisateur. B) Si la branche de dialogue concerne une vraie transaction (avec des écritures ou des lectures incohérentes). Son niveau de coordination devient "COMMITMENT". Les propriétés ACID doivent être satisfaites par le prestataire du service transactionnel (sauf concurrence). Laurence DUCHIEN - CNAM 64 Le transactionnel réparti
Arbre des transactions C'est un arbre emboîté dans l'arbre des dialogues qui a comme noeuds des entités utilisatrices qui définissent elles aussi des transactions (qui doivent satisfaire les propriétés ACID). Exemple: (précédent modifié) - Une transaction racine émise par A doit satisfaire les propriétés acid - Elle utilise une sous-transaction sur B qui elle aussi doit satisfaire ces propriétés. A Transaction racine A Transaction racine B Sous Transaction B C D Arbre de dialogue C D Sous Transaction Arbre de transaction Laurence DUCHIEN - CNAM 65 Le transactionnel réparti