Service de Transaction
Transcription
Service de Transaction
Introduction Transaction : assure les propriétés ACID Jave EE : repose sur JTA (Java Transaction API) Service de Transaction Exemple classique : un transfert bancaire (débit, crédit) !! !! !! !! Gaël Thomas [email protected] Atomicité : soit les 2 opérations s'effectuent complètement, soit aucune Cohérence : le solde d'un compte ne doit jamais être négatif Isolation : des transferts // doivent fournir le même résultat qu'en séq. Durabilité : les soldes doivent être sauvegardés sur support stable Support complètement intégré au serveur EJB Véritable + / aux middlewares style CORBA Université Pierre et Marie Curie Master Informatique M2 – Spécialité SAR 2008-2009 Master SAR - M2 MDOC - Introduction Introduction Introduction Client léger : navigateur Web HTTP Transaction et EJB3 : deux façon de gérer les transactions Serveur WEB Gérée par le conteneur (CMT) !!La gestion est prise en charge par le conteneur Service de transport : IIOP, RMI ou autre Cache Conteneur EJB 2008-2009 Conteneur EJB Master SAR - M2 MDOC - Introduction •! Transaction coïncident avec des méthodes •! Uniquement dans des EJB Service BD : JDBC Conteneur WEB Service Transaction: JTA/JTX Service Nommage : JNDI JEE Client lourd 2 Gérée par le Bean (BMT) !!La gestion est à la charge du Bean •! Début et fin de transaction explicite •! Peut être créé à l’extérieur d’un Bean Base De Donnée 3 2008-2009 Master SAR - M2 MDOC - Introduction 4 Transaction Gérée par le Conteneur Transaction Gérée par le Conteneur Gestion des transactions dans les conteneurs EJB Définir la démarcation des transactions !!Grain : la méthode !!Passage de transaction d’une méthode à l’autre !!Levée de (certaines) exceptions annulent la transaction !!Couplage avec la base de donnée (quasi) transparent !!@TransactionAttribut : par méthode !!@TransactionManagement : pour la classe Six attributs SUPPORTS, NOT_SUPPORTED, REQUIRED, REQUIRES_NEW, MANDATORY, NEVER !!L’appelant doit, peut ou ne doit pas s’exécuter dans une transaction !!L’appeler doit, peut ou ne doit pas s’exécuter dans une transaction Attention, par défaut le comportement d’une méthode n’est pas spécifié (REQUIRED pour Jonas) 2008-2009 Master SAR - M2 MDOC - Introduction 5 2008-2009 Transaction Gérée par le Conteneur Master SAR - M2 MDOC - Introduction Transaction Gérée par le Conteneur Passage de transaction entre appelant et appelé Passage de transaction entre appelant et appelé SUPPORT !!Si l’appelant s’exécute dans une transaction, l’appelé l’utilise !!Sinon, l’appelé s’exécute en dehors de toute transaction NOT_SUPPORT !!L’appelé s’exécute toujours en dehors d’une transaction Appelant T1 Appelant Appelé 6 Appelant T1 Appelé Appelant Appelé Appelé T1 T1 2008-2009 T1 Master SAR - M2 MDOC - Introduction 7 2008-2009 Master SAR - M2 MDOC - Introduction 8 Transaction Gérée par le Conteneur Transaction Gérée par le Conteneur Passage de transaction entre appelant et appelé Passage de transaction entre appelant et appelé REQUIRED !!Si l’appelant s’exécute dans une transaction, l’appelé l’utilise !!Sinon, l’appelé débute une nouvelle transaction REQUIRED_NEW !!Une nouvelle transaction est systématiquement créée Appelant T1 Appelant Appelant Appelé Appelé T1 T1 T1 T1 2008-2009 Appelant Appelé Appelé T2 T2 T1 Master SAR - M2 MDOC - Introduction 9 2008-2009 Transaction Gérée par le Conteneur Master SAR - M2 MDOC - Introduction Transaction Gérée par le Conteneur Passage de transaction entre appelant et appelé Passage de transaction entre appelant et appelé MANDATORY !!Si l’appelant s’exécute dans une transaction, l’appelé l’utilise !!Sinon, l’appelé lève une exception NEVER !!L’appelant ne doit pas s’exécuter dans une transaction Appelant T1 Appelant Appelé 10 Appelant T1 Appelé Appelant Appelé Appelé T1 T1 2008-2009 throw new TransactionRequiredLocalException() or new TransactionRequiredException() Master SAR - M2 MDOC - Introduction throw new EJBException() or new RemoteException() 11 2008-2009 Master SAR - M2 MDOC - Introduction 12 Transaction Gérée par le Conteneur Transaction Gérée par le Conteneur Rolling Back d’une transaction Annuler la transaction avec une exception !!Automatique lors de la levée d’une exception système Sous type de RuntimeException ou RMIException (note : EJBException hérite de RuntimeException) public class MonException extends RuntimeException {} Ou !!Toute exception non système annotée par @ApplicationException(rollback=true) public class MonException extends Exception {} @ApplicationException(rollback=true) !!Sur appel explicite à setRollbackOnly() (voir suite) Annulation : Comment le rôle back a lieu public void faitQqch() throws MonException { … if(problem) throw new MonException(); } !!Entity Bean : modifications non propagées à la BD !!Session Bean : état à restaurer à la main en implantant l’interface SessionSychronisation 2008-2009 Master SAR - M2 MDOC - Introduction 13 2008-2009 Transaction Gérée par le Conteneur Intercepter les transactions dans un Session Bean @Statefull @Remote(Compte.class) class CompteImpl implements Compte, SessionSynchronization { @Resource SessionContext ctx; public int value; public int copy; boolean pbm; 1.! Accéder au contexte du Bean @Resource SessionContext ctx; @Resource EntityContext ctx; @Resource MessageDrivenContext ctx; public void afterBegin() { copy = value; } !!Donne accès à deux services système : transaction et timer public void afterCompletion(boolean success) { if(!success) value = copy; } 2.! Marquer la transaction comme annulée ctx.setRollbackOnly(); public void beforeCompletion() { if(pbm) ctx.setRollbackOnly(); } … Consulter l’état : ctx.getRollbackOnly() Remarque : le code de la transaction se termine, annulation à la fin Master SAR - M2 MDOC - Introduction 14 Transaction Gérée par le Conteneur Annuler la transaction avec setRollbackOnly() 2008-2009 Master SAR - M2 MDOC - Introduction 15 2008-2009 Master SAR - M2 MDOC - Introduction 16 Transaction Gérée par le Conteneur Transaction Gérée par le Bean Intercepter les transactions dans un EntityBean Problèmes des transactions gérées par le conteneur !!Grain parfois trop gros Ne sert à rien! !!Besoin de lancer la transaction de l’extérieur Solution : gérer les transactions à la main avec l’API JTA 2008-2009 Master SAR - M2 MDOC - Introduction 17 2008-2009 Transaction Gérée par le Bean Master SAR - M2 MDOC - Introduction 18 Transaction Gérée par le Bean Trouver le contexte transactionnel : cas des Beans Trouver le contexte transactionnel : cas des clients externes Context c = new InitialContext(); UserTransaction utx = (UserTransaction)c.lookup("UserTransaction"); 1.! Noter que les transactions ne doivent pas être gérée par le Bean @TransactionManagement(TransactionManagementType.BEAN) 2.! Accéder au contexte du Bean Attention : le nom JNDI peut varier d’un serveur à l’autre @Resource SessionContext c; @Resource EntityContext c; @Resource MessageDrivenContext c; !!Donne accès à deux services système : transaction et timer 3.! Accéder au contexte transactionnel (UserTransaction) utx = c.getUserTransaction() 2008-2009 Master SAR - M2 MDOC - Introduction 19 2008-2009 Master SAR - M2 MDOC - Introduction 20 Transaction Gérée par le Bean Transaction Gérée par le Bean Utilisation des transactions Principales méthodes d’un UserTransaction utx.begin(); cl.deposer(50); boolean ok = cr.retirer(50); if (ok) Master SAR - M2 MDOC - Introduction begin() : création d’une nouvelle transaction !! void commit() : termine la transaction (annulé si rollBackOnly) !! void rollback() : annule la transaction setRollbackOnly() : marque la transaction annulé Annulation au commit, permet de terminer l’appel !! void setTransactionTimeout(int sec) : expire la transaction au bout de sec secondes !! int getStatus() : donne l’état de la transaction (commit, committing, active, rollBackOnly…) !! void utx.commit(); else utx.rollback(); 2008-2009 !! void 21 2008-2009 Principe d’Implantation Master SAR - M2 MDOC - Introduction 22 Isolation et Transaction Principe d’implémentation : Isolation et transaction : accès concurrent lecture/écriture (1/3) !!Un thread est associé à une unique transaction courante Gestion de transactions imbriquées !!Les conteneurs JEE déplacent le contexte transactionnel entre thread Passage local et distant 1.! Lecture sale (version 1) Processus 1 ----------Begin(T1) Read(X) --------------------Commit(T1) Transaction distribuée : commit() deux phases !!Phase 1 : vote centralisé par le coordinateur (celui qui effectue commit()) •! Envoie une demande jusqu’à réception de tous les votes (commit/abort) (possibilité d’utiliser un temporisateur) !!Phase 2 : dépouillement et propagation du vote •! Si un vote négatif (ou timeout expiré), envoie abort à tous les conteneurs •! Si que votes positifs, envoie commit jusqu’à réception de tous les acquittements Processus 2 Begin(T2) --------------------Write(X) Commit(T2) Le processus 1 a travaillé sur une donnée invalide Hypothèse système : aucune faute n’est permanente ! tous décident à terme 2008-2009 Master SAR - M2 MDOC - Introduction 23 2008-2009 Master SAR - M2 MDOC - Introduction 24 Isolation et Transaction Isolation et Transaction Isolation et transaction : accès concurrent lecture/écriture (1/3) Isolation et transaction : accès concurrent lecture/écriture (2/3) 1.! Lecture sale (version 2) 2.! Lecture non répétable Processus 1 Begin(T1) ----------Read(X) Commit(T1) ----------- Processus 2 Begin(T2) Write(X) --------------------Abort(T2) Processus 1 Begin(T1) Read(X) --------------------Read(X) Le processus 1 a travaillé sur une donnée invalide 2008-2009 Master SAR - M2 MDOC - Introduction Processus 2 Begin(T2) ----------Write(X) Commit(T2) Le processus 1 ne lit pas deux fois la même donnée 25 2008-2009 Isolation et Transaction Master SAR - M2 MDOC - Introduction Isolation et Transaction Isolation et transaction : accès concurrent lecture/écriture (3/3) Isolation et transactions : ce que les EJB fournissent 3.! Lecture fantôme Session Bean : isolation complète de fait Processus 1 Begin(T1) select * --------------------select * !!Stateless : un bean par thread !!Statefull : un bean par client Mais attention au clients multi threadés… Processus 2 Begin(T2) ----------delete x; insert y; Commit(T2) Entity Bean : un EntityManager par transaction !!Un ensemble d’EntityBean locaux par transaction •! Modification locale •! Propagée lors du commit Le processus 1 ne trouve pas deux fois les mêmes tuples 2008-2009 26 Master SAR - M2 MDOC - Introduction !!Mais… Ce n’est pas un verrou 27 2008-2009 Master SAR - M2 MDOC - Introduction 28 Isolation et Transaction Isolation et Transaction Isolation et transactions : ce que les EJB fournissent Changer le degré d’isolation Ne résout aucun des problèmes d’isolation! Solution ad-hoc : modifier le degré d’isolation de la base elle-même !! java.sql.Connection.setTransactionIsolation(int level) !!Lecture non répétable et lecture fantôme !!Via descripteurs de déploiement void f() { Film f = …; f.name …; f.name; } avec commit d’une nouvelle version de f entre les deux accès !!Lecture sale (version 1) void debite(float x) { setSolde(getSolde() + x;) } avec commutation après lecture Résout la seconde version de lecture sale void speculative() { … y = 22; … abort(); } cache non propagé 2008-2009 Master SAR - M2 MDOC - Introduction Lecture Sale Lecture non répétable Lecture fantôme READ_UNCOMMITTED Oui Oui Oui READ_COMMITTED Non Oui Oui REPEATABLE_READ Non Non Oui SERIALIZABLE Non Non Non Mais : pas possible pour tous les SGBD Plus l’isolation est forte, plus c’est coûteux 29 2008-2009 Isolation et Transaction Master SAR - M2 MDOC - Introduction 30 Isolation et Transaction Changer le degré d’isolation Assurer l’isolation Pas de solution satisfaisante : Solution pessimiste : poser un verrou !!Solution ad-hoc : trop dépendante de la base !!Le cache transactionnel : ne résout qu’une partie de la lecture sale EntityManager.setLock(Object entity, LockModeType mode) mode = READ/WRITE Pose un verrou sur l’EntityBean entity Solution pour la lecture sale et non répétable mais pas pour la lecture fantôme Problème : le "user think time" Bloque totalement l’accès en écriture à un tuple pendant la transaction qui peut être longue 2008-2009 Master SAR - M2 MDOC - Introduction 31 2008-2009 Master SAR - M2 MDOC - Introduction 32 Isolation et Transaction Isolation et Transaction Assurer l’isolation Assurer l’isolation Solution optimiste : vérifier à postériori les conflits Exemple de conflit écrivain/écrivain !!Ajout d’un timestamp à l’entity bean : @Version int ver; !!Incrémenté dans la base à chaque écriture !!Détection de conflit de version ! annulation de la transaction void debite(float x) { setSolde(getSolde()+x); } exécuté en // P1 : commutation après getSolde() : timestamp : 0 P2 : exécution de debite, commit : timestamp passe à 1 P1 : fin de l’exécution : timestamp invalide (Bean à 0, base à 1) !!Mécanisme orthogonal aux transactions !!Applicable sur les objets détachés !!Pas de verrou Si objets détachés : détection des conflits lors des merge() !!Mais… Très coûteux si conflits fréquents Principe système sous-jacent : les mémoires transactionnelles logicielles (STM) 2008-2009 Master SAR - M2 MDOC - Introduction 33 2008-2009 Master SAR - M2 MDOC - Introduction Isolation et Transaction 34 Conclusion Assurer l’isolation I de ACID reste difficile !!Atomique, Cohérent, Durable : parfaitement géré par les conteneurs Exemple de conflit écrivain/lecteur !!Processus L : lecture avec timestamp T !!Processus E : écriture timestamp T+1 !!Processus L : commit() : annulation car timestamp invalide !!Isolation : demande de réelles connaissances Si objet du lecteur détaché : il faut faire artificiellement un merge() pour vérifier la cohérence du timestamp. 2008-2009 Master SAR - M2 MDOC - Introduction 35 2008-2009 Master SAR - M2 MDOC - Introduction 36