Middleware transactionnel
Transcription
Middleware transactionnel
extension des moniteurs transactionnels « anciens » (CICS d ’IBM par exemple) à la gestion de transactions réparties hétérogènes implantation du modèle DTP (Distributed Transaction Processing) de X/Open TUXEDO (BEA), CICS (IBM), ENCINA (Transarc), TopEnd (Nixdorf, ATT) Celles d ’un middleware de données en environnement multi-serveurs équilibrage de charge administration centralisée des systèmes gestion répartie des transactions : si SGBD homogènes (même vendeur) : peut être assurée directement par ces SGBD si SGBD hétérogènes : besoin de standardiser les interfaces du protocole de validation 2 phases Programme accédant et/ou modifiant des données persistantes (fichier ou BD) avec propriétés : A : atomicité (tout ou rien) C : cohérence (respect des contraintes définies sur les données) I : isolation (garantie de non interférence entre des transactions s ’exécutant concurremment) D : durabilité (état produit par la transaction ne peut être perdu) Transaction réservation(date, nbplace) select reste into r from RESERVATION where dateresa=:date si (r >= nbplace) alors update RESERVATION set reste=reste-nbplace where panne dateresa=:date éditer-place(date, nbplace) valider transaction sinon imprimer ‘ réservation impossible ’ annuler transaction finsi Fin transaction Transaction centralisée : toutes les opérations d ’accès et de maj aux données persistantes ont lieu sur le même site (et le même système) Transaction répartie : les opérations d ’accès et/ou de maj aux données ont lieu sur au moins deux sites ! Agence de voyage Réserver un voyage (transaction globale) Réserver avion Réserver hôtel Réserver Transactions voiture locales " #!$%&! ' Composition de transactions n ’est pas atomique atomicité d ’une transaction répartie doit être assurée par un protocole de synchronisation des sites impliqués dans la transaction (protocole de validation à deux phases ou V2P) les SGBD commerciaux implantent une version propriétaire du V2P ) #! ) moniteurs transactionnels ouverts implantent DTP tout SGBD supportant l ’interface XA peut être piloté par un moniteur transactionnel (plupart des SGBD commerciaux) XA et TX ne gère que l ’aspect transactionnel (début et fin de la transaction, démarrage d ’un nouveau site, …) repris par OTS (Corba) et JTS (Java) Application program Interface native (SQL,…) Resource manager Interface XA #! Interface TX Transaction manager ( + , Participant 1 Début T1 + , Avantages : Participant 2 assure l ’atomicité globale beaucoup d ’implantations Inconvénients : prepare OK (not OK) OK - coordinateur Début T2 prepare Commit (abort) * OK (not OK) décision Commit (abort) OK performances (beaucoup de messages échangés) blocage (site reste bloqué depuis la fin de la transaction locale jusqu ’au prepare) sensibilité aux pannes difficile à mettre en oeuvre sur Internet # . / Transaction = séquence d’invocations url (gestion du contexte par le web?) Transaction = propriétés ACID (assurées par le SGBD) HTTP = pas de support de session gérer le contexte côté client (cookies) simuler des sessions http (web transactionnel) # 0 12 Contexte est géré chez le client (cookies) avantages : simplicité de la mise en œuvre accès en maj de la BD se fait en une fois à la fin (pas de ressources bloquées) si pas de terminaison de la transaction par l ’utilisateur, rien à faire # 0 Client browser cgi Serveur http 1 1 1’ c1 2 c1 2’ c1, c2 3 fin c1, c2 5’ del(c1, c2) 1’ c1 2 c1 2’ c1, c2 3 fin c1, c2 5’ del(c1, c2) 4’ ok 1 : premier accès 4 sql(c1, c2) 1’ : retour du cookie c1 2 : autre accès avec transport du cookie c1 2’ : retour des cookies c1, c2 3 : fin transaction avec transport c1, c2 4 : construction de la transaction et exécution sur le SGBD 5’ : suppression des cookies SGBD # 0 12 Inconvénients pas vraiment transactionnel fonctionnalité limitée beaucoup de cgi à écrire (sauf programme de maj générique qui prenne une séquence d ’instructions SQL en entrée) Problèmes des cookies global à l ’utilisateur (pas de différenciation entre fenêtres) global à une url (pas deux transactions en même temps sur le même site) ! ! Client browser Serveur http cgi démon passerelle SGBD ! Avantages vraiment transactionnel solution générique Inconvénients architecture complexe blocage des ressources nécessité de détecter un « abandon » de l ’utilisateur (timeout) pas très adapté sur Internet (plutôt cookies) Contexte géré par un démon côté serveur besoin d ’un identifiant de transaction stocké côté client (cookie ou variable selon client) et côté démon (dans une table) passerelle ne traite pas une seule requête mais toute une transaction (plusieurs requêtes)