Gestion des transactions 1. Le mode transactionnel 2. Les accès concurrents 2.1 Objectifs 2.2 Les bases 2.3 Le verrouillage à deux phases 2.4 L'ordonnancement par estampilles 2.5 Techniques avancées et modèles étendues 3.Gestion de transactions 3.1. Journaux et reprise 3.2. Scénarios de reprise 3.3. Journalisation et modèles étendus 3.4. Cas des systèmes répartis 4. Moniteurs transactionnels

1. Le mode transactionnel (OLTP) Opérations typiques Mises à jour ponctuelles de tuples à partir de vues prédéfinies, souvent répétitive, sur les données les plus récentes Exemple Benchmark TPC-A et TPC-B : débit / crédit sur une base de données bancaire TPC-A benchmark en mode transactionnel, TPC-B benchmark en mode traitement par lot. Mesure le nombre de transactions par seconde (tps) et le coût par tps.

La base des modes TPC-A/TPC-B 1 100000 Agences Comptes Caissiers Historique 100 Taille pour 10 terminaux, avec règle d'échelle ( scaling rule)

La transaction débit - crédit Begin-Transaction Update Account Set Balance = Balance + Delta // Montant Delta Where AccountId = Aid ; Insert into History (Aid, Tid, Bid, Delta, TimeStamp) Update Teller Set Balance = Balance + Delta Where TellerId = Tid ; Update Branch Set Balance = Balance + Delta End-Transaction. Objectif : temps de réponse de 90 % des transactions < 2 s Chaque terminal génère une transaction toute les 10s Performance = Nombre de transactions commises /Temps exécution moyen Temps exécution moyen =Ellapse time

Cohabitation avec le mode décisionnel Les transactions doivent souvent cohabiter avec des requêtes décisionnelles, et traiter un grand nombre de tuples en lecture. Exemple : Moyenne des avoirs des comptes par agence SELECT B.BranchId, AVG(C.Balance) FROM Branch B, Account C WHERE B.BranchId = C.BranchId GROUP BY B.BranchId ;

Les risques de disfonctionnement Problèmes de la gestion des accès concurrents Pertes d'opérations. Introduction d'incohérences. Verrous mortels (deadlock). Panne de transaction Erreur en cours d'exécution du programme applicatif. Nécessité de défaire les mises à jour effectuées quand elles conduisent à des incohérences. Panne système Reprise avec perte du contenu de la mémoire centrale : toutes les transactions en cours doivent être défaites. Panne disque Perte de la base, d'où sauvegardes!

Propriétés fondamentales des transactions Séquence d'opérations liées comportant des mises à jour ponctuelles d'une base de données devant vérifier les propriétés ACID. Atomicité Unité de cohérence : toutes les mises à jour doivent être effectuées ou aucune. Cohérence La transaction doit faire évoluer la base de donnée d'un état cohérent à un autre. Isolation Les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction validée. Durabilité Les modifications d'une transaction validée ne seront jamais perdue

Opérations Commit et Abort Introduction d'actions atomiques Commit (terminaison avec succès) et Abort (terminaison avec échec). Ces actions s'effectuent en fin de transaction. Commit Validation de la transaction. Rend effectives toutes les mises à jour de la transaction. Abort Annulation de la transaction. Défait toutes les mises à jour de la transaction.

Schéma d'une transaction simple Fin avec succès ou échec Begin_Transaction update ..... Commit ou Abort - Provoque l'intégration réelle des mises à jour dans la base - Relâche les verrous - Provoque l'annulation des mises à jour - Relâche les verrous - Reprend la transaction

Effet logique Mémoire de la transaction Update Update Abort Commit Poubelle Bases de données

Interface applicative API pour transaction simple Trid Begin (context*) Commit () Abort() Possibilité de points de sauvegarde : Savepoint Save() Rollback (savepoint) // savepoint = 0 ==> Abort Quelques interfaces supplémentaires ChainWork (context*) // Commit + Begin Trid Mytrid() Status(Trid) // Active, Aborting, Committing, Aborted, Committed

2. Les accès concurrents 2.1 Objectifs 2.2 Les bases 2.3 Le verrouillage à deux phases 2.4 L'ordonnancement par estampilles 2.5 Les applications avancées

2.1 Objectifs Permettre l'exécution simultanée d'un nombre important de transactions. Régler les conflits d'accès lecture (accès partagé)/ écriture (accès exclusif). Conserver de bonnes performances. Eviter les inter-blocages.

Les problèmes des accès concurrents Perte d'une mise à jour effectuée par une autre transaction { T1 : Lire A->a; T2 : Lire A->b; T2 : b+1 -> b; T2 : Écrire b->A; T1: a*2 ->a; T1: Écrire a -> A } Introduction d'incohérences dans la base A = B // contrainte d'intégrité { T1 : A*2->A; T2 : A+1->A; T2 : B+1 -> B; T1 : B*2 -> B

Les problèmes des accès concurrents Non reproductibilité de certaines lectures { T1 : Lire A->a; T2 : Lire A->b; T2 : b+1 -> b; T2 : Écrire b->A; T1: Lire A -> a }

2.2 Les définitions de base Granule de concurrence Unité de données dont les accès sont contrôlés individuellement par le SGBD. Action Unité indivisible exécutée par le SGBD sur un granule pour un utilisateur, constituée généralement par une opération de lecture ou d'écriture. Exécution de transaction Séquence d'actions obtenues en intercalant les diverses actions des transactions T1,T2,…,Tn tout en respectant l'ordre interne de chaque transaction.

2.2 Les définitions de base (suite) Chaque transaction Ti est composée d'une séquence d'actions <a11, a12, ..., a1n>. Une exécution simultanée (histoire) des transactions {T1, T2, .... Tn} est une séquence d'actions H = < ai1j1, ai2j2 .... aikjk > telle que aij < aij+1 pour tout i et tout j et quel que soit aij de T1,…, Tn, aij est dans H C'est une séquence d'actions complète respectant l'ordre des actions des transactions. Une exécution est sérielle si toutes les actions des transactions ne sont pas entrelacées. Elle est de la forme <Tp(1), Tp(2), ...Tp(n)> ou p est une permutation de 1, 2, ... n.

Sérialisabilité Exécution sérialisable Une exécution est dite sérialisable si elle est équivalente à une exécution sérielle. Plusieurs critères d'équivalence possibles Équivalence de vue : tous les résultats visibles sont identiques. Équivalence de conflit : toutes les actions conflictuelles sont effectuées dans le même ordre sur les objets de la base.

Graphe de précédence Précédence : propriété stipulant qu'une transaction a accompli une opération Oi sur une donnée avant qu'une autre transaction Oj n'y accomplisse une opération, les transactions Oi et Oj étant non commutatives. La technique est basée sur la seule sémantique des opérations de lecture / écriture "Ti lit l'objet O" avant "Tj écrit l'objet O" => Ti précède Tj "Ti écrit l'objet O" avant "Tj écrit l'objet O" => Ti précède Tj Condition de sérialisabilité Le graphe de précédence doit rester sans cycle. La sérialisabilité est une condition suffisante de correction. Exercice Démontrer que les cas de perte d'opérations et d'incohérences sont non sérialisables.

2.3 Le Verrouillage à deux phases Verrouillage à deux phases (Two Phases Locking) Technique de contrôle des accès concurrents consistant à verrouiller les objets au fur et à mesure des accès par une transaction et à relâcher les verrous seulement après obtention de tous les verrous demandés. Principes Verrouillage des objets en lecture/écriture. Opérations de verrouillage Lock(g,M) et de déverrouillage Unlock(g) Compatibilité des opérations de lecture/écriture. L : Lecture E : Ecriture Toute nouvelle transaction doit attendre la fin des transactions incompatibles. La théorie garantit un graphe de précédence sans cycle. Rappelons que l'existence d'un cycle peut créer un verrou mortel. L E V F F F

Condition de corrections Transactions à deux phases (Two phases Commit) Principe de base : une transaction ne peut relâcher un verrou avant de les avoir tous acquis. Nombre de verrous temps j

Algorithmes de l'opération Lock Bool Function Lock(Transaction t, Objet O, Mode M) {Cverrou := 0 ; Pour chaque transaction i  t ayant verrouillé l'objet O faire { Verrou := Verrou  t.verrou(O) } ; // cumul des verrous sur l'objet si Compatible (Mode, Verrou) alors {t.verrou(O) = t.verrou(O)  M; // marquer l'objet verrouillé Lock := true ; } sinon {insérer (t, Mode) dans la queue de O ; // mise en attente de transaction bloquer la transaction t ; Lock := false ; } ;

Algorithme de l'opération Unlock Procédure Unlock(Transaction t, Objet O) {t.verrou(O) := 0 ; Pour chaque transaction i dans la queue de O {si Lock(i, O,M) alors {enlever (i,M) de la queue de O ; débloquer i ;} ; }

Problèmes liés au verrouillage Verrou mortel Risques de cycles d'attente entre transactions. Granularité des verrous au niveau page : de petits objets risquent d'être verrouillés en trop grands nombres au niveau objet : nombre trop important de verrous, d'où une gestion difficile T1 T2 T3

Résolution du verrou mortel Prévention Définition de critères de priorité pour éviter que le problème ne se pose. Exemple : priorité aux transactions les plus anciennes. Détection Gestion du graphe des attentes. Lancement d'un algorithme de détection de cycles dès qu'une transaction attend trop longtemps. Choix d'une transaction victime pour briser le cycle.

Améliorations du verrouillage Relâchement des verrous en lecture après opération - : non garantie de la reproductibilité des lectures. + : verrous conservés moins longtemps. Accès à la version précédente lors d'une lecture rendue bloquante - : nécessité de conserver une version antérieure (journaux). + : une opération de lecture n'est pas bloquante en général.

Granularité variable Plusieurs granules de verrouillage sont définis, imbriqués les uns dans les autres. Le verrouillage s'effectue en mode intention sur les granules supérieurs et en mode effectif sur les granules choisis Les modes intentions sont compatibles. Les modes effectifs et intentions obéissent aux règles de compatibilité classiques. base classe cluster page objet

Algorithme du verrouillage altruiste Restitution des verrous sur les données qui ne sont plus utilisées L'abandon d'une transaction provoque des cascades d'abandons. Nécessité d'introduire la portée d'une transaction (transaction ouverte). Temps Objets a b c d e T1 - T2 T3 ,

Degré d'isolation en SQL2 Définition de degrés d'isolation emboîtés Degré 0 Garantit les non pertes des mises à jour. Pose de verrous exclusifs courts lors des écritures. Degré 1 Garantit la cohérence des mises à jour. Pose de verrous exclusifs longs en écriture. Degré 2 Garantit la cohérence des lectures individuelles. Pose de verrous partagés courts en lecture. Degré 3 Garantit la reproductibilité des lectures. Pose de verrous partagés longs en lecture.

Bilan sur le principe du verrouillage C'est une approche pessimiste prévient les conflits, assez coûteuse, assez complexe. Approche retenue Dans tous les SGBD industriels. Difficile de faire mieux !

2.4 Ordonnancement par estampillage Estampille (TimeStamp) associée à chaque transaction Date de lancement, Garantie d'ordre total (unicité). Conservation des estampilles Dernier écrivain Écrire r Plus jeune lecteur Lire er Contrôle d'ordonnancement En écriture: estampille écrivain > Écrire r et > Lire er En lecture: estampille lecteur > Écrire r Problèmes Reprise de transaction en cas d'accès non sérialisé Risque d'effet domino en cas de reprise de transaction

Algorithme d'ordonnancement Fonction Lire (Transaction t, Objet O) { si O.Écrire r  t alors { Lire := Get(O) ; // effectuer la lecture O.Lire er := MAX (O.Lire er,t) ; // mettre à jour dernier lecteur } sinon Abort(t); } . Fonction Écrire (Transaction t, Objet O, Contenu C){ si O.Écrire r  t et O. Lire er  t alors{ Set(O,C) ; // effectuer l'écriture O.Écrire r := t ; // mettre à jour dernier écrivain }

La certification optimiste Les contrôles sont effectués seulement en fin de transaction Phase d'accès: les OIDs des objets lus/écrits sont conservés. Phase de certification : vérification de l'absence de conflits (L/E ou E/E sur un même objet) avec les transactions certifiée pendant la phase d'accès. Phase d'écriture (commit) pour les transactions certifiées. Avantages et inconvénients: + : test simple d'intersection d'ensembles d'OIDs en fin de transaction. - : tendance à trop de reprises en cas de conflits fréquents (effondrement).

Bilan Estampillage Approche optimiste Guérison difficile coût assez faible, détection et guérison des problèmes. Guérison difficile Catastrophique en cas de nombreux conflits. Absorbe mal les pointes de charge. Sophistication Ordonnancement multi-versions

2.5 Techniques avancées et modèles étendus Transactions longues Mise à jour d'objets complexes. Sessions de conception. Prise en compte de la sémantique des applications Opérations commutatives (e.g., ajouts d'informations). Essais concurrents. Travail coopératif Modèles concurrents plutôt que séquentiels.

Commutativité d'Opérations Possibilité de distinguer d'autres opérations que celles de Lecture/Ecriture Chaque objet est doté de sa liste d'opérations (méthodes). Les opérations commutatives n'entraînent pas de conflits. La commutativité peut dépendre du résultat. Cas des ensembles [Ins,ok] insertion avec succès [Del,ok] suppression avec succès [In, true] appartenance avec succès [In, False] appartenance avec échec

Commutativité d'Opérations [Ins,ok] [Del,ok] [In, true] [In, False] [Ins,ok] 1 0 0 0 [Del,ok] 0 1 0 1 [In, true] 0 0 1 1 [In, False] 0 1 1 1 Matrice de commutativité

Contrôleur de Commutativité Un contrôle de concurrence défini au niveau de la classe opère sur chaque objet. Il autorise les opérations commutatives. Il bloque les opérations non commutatives (ordonnancement). Le modèle est ouvert et nécessite soit des transactions de compensations, soit la gestion de listes de transactions dépendantes. Un potentiel pour les SGBDO non encore implémenté (complexe)

Transactions Imbriquées Objectifs Obtenir un mécanisme de reprise multi-niveaux Permettre de reprendre des parties logiques de transactions Faciliter l'exécution parallèle de sous-transactions Schéma Reprises et abandons partiels Possibilité d'ordonner ou non les sous-transactions Begin(T) Begin(t'1) Begin(t1) Commit(t1) Commit(t'1) Commet t1 Begin(t2) Begin(t21) Commit(t21) Abort(t2) Commit(T) Annule t2 et t21

Verrouillage et Transactions Imbriquées Chaque transaction peut acquérir ou relâcher des verrous. Un verrou est accepté si l'objet est libre ou verrouillé par un ancêtre. Les verrous non relâchés sont restitués à la transaction mère. Problèmes de conflits entre sous-transactions parallèles Risque de verrous mortels, L'ancêtre commun peut trancher. Gestion de journaux multi-niveaux Organisation sous forme de piles, Nécessité de journaux multiples en cas de parallélisme.

Sagas Groupe de transactions ordonnées avec transactions compensatrices. En cas de panne du groupe, les transactions de compensation sont exécutées. T1 T2 T3 ... Tn T1 T2 CT2 CT1

Activités : propriétés souhaitées Contexte persistant. rollforward, rollback avec compensations. Flot de contrôle dépendant des succès et échecs. différencier les échecs systèmes des échecs de programmes. Monitoring d'activités: état d'une activité, arrêt, ...

Langage de Contrôle d'Activités Exemple: réservation pour départ en vacances T1 : réservation avion alternative : location voiture T2 : réservation hôtel T3 : location voiture Activité Ensemble d'exécution de transactions avec alternative ou compensation. Langage de contrôle d'activités Possibilité de définir un transaction vitale (ex: réservation hôtel). Langage du type : If abort, If commit, Run alternative, Run compensation, …

Transaction multi-niveaux BD PARTAGEE BD PERSONNELLE Objet Versionnable V1 CheckOut Version Personnelle CheckIn V2 V3 CheckOut Version Personnelle V4 CheckIn

CheckOut/CheckIn ChechOut CheckIn Opération d'extraction d'un objet de la BD pour en dériver une nouvelle version. CheckIn Opération de réinstallation d'une nouvelle version de l'objet dans la BD. Lecture Ecriture COut P COut E Lecture 1 0 1 0 Ecriture 0 0 0 0 COut Partagée 1 0 1 0 COut Exclusif 0 0 0 0

Fusion des Versions Maintient différentiel Seuls les objets/pages modifiés sont maintenus. Aucun objets communs n'est modifié La fusion est une union des "deltas". Des objets communs sont modifiés Nécessité d'intervention manuelle (choix).

2.6 Conclusions Technique d'amélioration du verrouillage Transactions ouvertes. Granularité variable. Commutativité des opérations. Transactions imbriquées. Versions. Amélioration des modèles transactionnels Gestion des transactions imbriquées. Sagas, Activités, Versions. Beaucoup d'idées, peu d' implémentations originales La plupart des systèmes utilise le verrouillage type SQL

3.Gestion de transactions 3.1. Journaux et reprise 3.2. Scénarios de reprise 3.3. Modèles étendus 3.4. Cas des systèmes répartis

3.1 Journaux des mises à jour Journal des images avant Journal contenant les débuts de transactions, les valeurs d'enregistrement avant mises à jour, les fins de transactions (commit ou abort) Il permet de défaire les mises à jour effectuées par une transaction Journal des images après Journal contenant les débuts de transactions, les valeurs d'enregistrement après mises à jour, les fins de transactions (commit ou abort) Il permet de refaire les mises à jour effectuées par une transaction

Journal des images avant Utilisé pour défaire les mises à jour : Undo 2.Log Page lue Page modifiée 3.Update 1.Read 4.Write Base de données

Journal des images après Utilisé pour refaire les mises à jour : Redo 3.Log Page lue Page modifiée 2.Update 1.Read 4.Write Base de données

Gestion des journaux Journaux avant et après sont unifiés. Écrits dans un tampon en mémoire et vidés sur disque en début de l'opération commit Structure d'un enregistrement : N° transaction (Trid) Type enregistrement {début, update, insert, commit, abort} TupleId [Attribut modifié, Ancienne valeur, Nouvelle valeur] ... Problème de taille On travaille avec N fichiers de taille fixe. Possibilité d'utiliser un fichier haché sur Trid/Tid.

Sauvegarde Sauvegarde périodique de la base toutes les heures, jours, ... Doit être effectuée en parallèle aux mises à jour. Point de Reprise (Checkpoint) Un Point de Reprise est écrit dans le journal pour le synchroniser par rapport à la sauvegarde. Il permet de situer les transactions effectuées après la sauvegarde. Pose d'un point de reprise écrire les tampons de journalisation (Log). écrire les tampons de pages (DB). écrire un enregistrement spécial "checkpoint" dans le journal.

3.2 Scénarios de Reprise Les mises à jour peuvent être effectuées directement dans la base (en place) la base est mise à jour immédiatement, ou "dès que possible" pendant que la transaction est active. Les mises à jour peuvent être effectuées en mémoire et installées dans la base à la validation (commit) le journal est écrit avant l'écriture des mises à jour.

Stratégie do-undo (faire/défaire) Mises à jour en place l'objet est modifié dans la base. Utilisation des images avant copie de l'objet avant mise à jour. utilisée pour défaire en cas de panne. Update 2. LogPage Mémoire cache Journal avant 3. WritePage Undo 1. LirePage Base

Stratégie do-redo (faire/refaire) Mises à jour en mode différentiel L'objet est modifié en page différentielle (non en place/journal). Utilisation des images après copie de l'objet en journal après mise à jour (do), utilisée pour refaire en cas de panne (redo). Update 3. LogPage Journal après Mémoire cache 2. WritePage 1. LirePage Redo Ombre Base Commit

Nouvelle Table des Pages Pages ombres Nom Fichier Adresse Table des Pages Table des Pages Ombres Page Ombre Nouvelles Pages Nouvelle Table des Pages COMMIT

La gestion des tampons (buffers) Gestion des caches et des des journaux Écriture du journal lorsqu'un tampon est plein, ou lorsqu'une transaction commet. Gestion des caches et des bases Modification de la la page en mémoire. Vidage du cache sur disque effectué en différé (processus E/S). Synchronisation journaux / base Le journal doit toujours être écrit avant la modification de la base !

Commits bloqués Afin d'éviter 3 e/s pour 1: Résultat Le système reporte l'enregistrement des journaux à la phase commit. Plusieurs transactions sont commises simultanément. Les transactions à commettre sont mises en attente pour bloquer un unique tampon d'écriture dans le journal. Résultat La technique des "commits" bloqués permet d'améliorer les performances lors des pointes sans excès d'attente trop sensible pour les transactions.

Reprise à froid En cas de perte d'une partie de la base, on repart de la dernière sauvegarde. Le système retrouve le checkpoint associé. Il ré-applique toutes les transactions commises depuis ce point . (for each committed Ti : redo (Ti))

3.3 Journalisation et modèles étendus Rappelons qu'ils s'agit d'applications longues composées de plusieurs transactions coopérantes. Seules les mises-à-jour sont journalisées. Si nécessité de défaire une suite de transactions : contexte ad-hoc stocké dans une table temporaire, nécessité d'exécuter des compensations.

Points de Sauvegardes Introduction de points de sauvegarde intermédiaires (savepoint, commitpoint) Begin_Trans update savepoint Commit unité d'oeuvre Non perte du contexte unité d'oeuvre

3.4 Transactions réparties Objectif Garantir que toutes les mises à jour d'une transaction sont exécutées sur tous les sites ou qu'aucune ne l'est. Exemple Transfert de la somme X du compte A vers le compte B DEBUT site 1: A = A - X site 2: B = B + X // Une panne provoque une incohérence des données FIN Problème Le contrôle étant réparti, chaque site peut librement décider de valider ou d'annuler ... 3

Commit à 2 Phases : principes et définitions Division de l'opération COMMIT en deux phases : Phase 1 Préparation de l'écriture des résultats des mises à jour dans la BD. Centralisation du contrôle. Phase 2 Écriture des résultats dans la BD. Coordinateur de l'opération Le composant système d'un site qui applique le protocole. Participant Le composant système d'un autre site participant à l'exécution de la transaction. 4

Commit en 2 Phases : protocole C/S 1. Préparer Le coordinateur demande aux autres sites s'ils sont prêts à commettre leur mise à jour. 2a. Succès : commettre Tous les participants effectuent leur validation sur ordre du client. 2b. Echec : abort Si un participant n'est pas prêt, le coordinateur demande à tout les autres sites de défaire la transaction. Remarque Le protocole nécessite la journalisation des mises à jour préparées et des états des transactions dans un journal local à chacun des sites participants. 5

Cas favorable SITE COORDINATEUR SITE PARTICIPANT 2 SITE PARTICIPANT 1 PREPARE PREPARE OK OK COMMIT COMMIT ACK ACK 6

Cas défavorable (1) SITE COORDINATEUR SITE PARTICIPANT 2 PREPARE PREPARE OK KO ABORT ABORT ACK ACK 7

Cas défavorable (2) SITE COORDINATEUR SITE PARTICIPANT 2 PREPARE PREPARE OK OK COMMIT COMMIT ACK STATUS COMMIT ACK 8

Commit distribué ou centralisé Validation à deux phases centralisée Possibilité de diffuser la réponse au PREPARE chaque site peut décider localement dans un réseau sans perte Prepare OK Commit 9

Transitions d'états Initial CCommit/Prepare Wait VoteKO/GAbort VoteOK/GCommit Initial Abort Commit Prepare/VoteOK COORDINATEUR Ready GAbort/Ack GCommit/Ack Abort Commit PARTICIPANT 11

Transactions bloquées Que faire en cas de doute ? Demander l'état aux autres transactions : STATUS conservation des états nécessaires. message supplémentaire. Forcer la transaction locale : ABORT toute transaction annulée peut être ignorée. cohérence garantie avec un réseau sans perte de message. Forcer la transaction locale : COMMIT toute transaction commise peut être ignorée. non garantie de cohérence avec le coordinateur. 12

Commit en 3 Phases Inconvénient du commit à 2 phases Initial Wait Abort PréCommit Commit CCommit/Prepare Inconvénient du commit à 2 phases en cas de time-out en état “Prêt”, le participant est bloqué le commit à 3 phases permet d'éviter les blocages Messages du commit à 3 phases Prepare, Prepare to Commit, Global-Commit, Global-Abort. VoteKO/GAbort VoteOK/PréCommit PréOK/GCommit Initial Ready Abort PréCommit Commit Prepare/VoteOK GAbort/Ack PréCommit/PréOK GCommit/Ack 13

Protocole arborescent TP TP est le standard proposé par l'ISO dans le cadre OSI Protocole arborescent Tout participant peut déclencher une sous-transaction. Un responsable de la validation est choisi. Un coordinateur est responsable de ses participants pour la phase 1. collecte les PREPARE demande la validation Le point de validation est responsable de la phase 2 envoie les COMMIT. Coordinateur global Coordinateur local Coordinateur local Point de validation (Noeud critique) 14

4. Moniteurs transactionnels Support de transactions ACID Accès continu aux données Reprise rapide du système en cas de panne Sécurité d'accès Performances optimisées Partage de connexions. Réutilisation de transactions. Partage de charge Distribution de transactions. Support de bases hétérogènes Respect des normes et standards 15

Moniteur transactionnel : modèle Modèle DTP de l'X/OPEN Programme d'application AP Gestionnaire de transactions TM Gestionnaire de communication CRM Gestionnaire de ressources RM Interfaces standards TX = interface du TM XA = interface du RM intégration de TP Types de RM gestionnaire de fichiers SGBD périphérique AP TX TM CRM TM XA RM 16

Interface applicative TX tx_open ordonne au TM d'initialiser la communication avec tous les RM dont les librairies d'accès ont été liées à l'application. tx_begin ordonne au TM de demander aux RM de débuter une transaction. tx_commit ou tx_rollback ordonne au TM de coordonner soit la validation soit l'abandon de la transaction sur tous les RM impliqués. tx_set_transaction_timeout positionne un “ timeout ” sur les transactions tx_info permet d'obtenir des informations sur le statut de la transaction. 17

Interface ressource XA xa_open ouvre un contexte pour l'application. xa_start débute une transaction. xa_end indique au RM qu'il n'y aura plus de requêtes pour le compte de la transaction courante. xa_prepare lance l'étape de préparation du commit à deux phases. xa_commit valide la transaction. xa_rollback abandonne la transaction. 18

Principaux moniteurs (1) Encina de Transarc Issu de CMU (1992), racheté par IBM Construit sur DCE (OSF) pour la portabilité et la sécurité Transactions imbriquées Conformité DTP : Xa, CPI-C, TxRPC Open CICS de IBM Construit sur Encina (et DCE) Reprise de l'existant CICS (API et outils) Conformité DTP : Xa, CPI-C

Principaux moniteurs (2) Tuxedo de USL Éprouvé (depuis 1984), à la base de DTP Supporte l'asynchronisme, les priorités et le routage dépendant des données Conformité DTP: Xa, Tx, XaTMI, CPI-C, TxRPC Top End de NCR Produit stratégique d'AT&T Respecte le modèle des composants DTP (AP, RM, TM, CRM) Haute disponibilité Conformité DTP: Xa, Xa+, Xap-Tp, Tx Autres : UTM de Siemens, Unikix 18

Le marché Gartner Group

MTS de Microsoft Microsoft Transaction Server Intégré à DCOM Partage de grappes de NT (cluster) Les disques sont supposés partagés. Allocation des ressources en pool aux requêtes : pool de connexion aux ressources (SQL Server), pool de transactions (support), pool de machines. Ne respecte pas les standards !

Conclusion sur les moniteurs transactionnels Des techniques complexes. Un problème bien maîtrisé dans les SGBDR. La concurrence complique la gestion de transactions. Les transactions longues restent problématiques. Enjeu essentiel pour le commerce électronique. validation fiable reprise et copies partage de connections partage de charge