Le Transactionnel en J2EE JTA/JTS Réalisé par Jarraya Med Haythem Jaziri Med Naceur

Plan Introduction Plateforme J2EE Transaction Le transactionnel en J2EE Conclusion

Introduction Une application entreprise typique accède et sauvegarde les informations dans une ou plusieurs bases de données. Une information doit être correcte, courante et fiable. L’intégrité de l’information serait perdue si des programmes multiples sont autorisés a mettre à jour la même donnée simultanément, elle peut même être perdue si un système tombe en panne lors de l’exécution d’une transaction affectant cette dernière.  Les logiciels de transactions assurent l’intégrité des données.

Plateforme J2EE Qu’est ce que J2EE? Pourquoi J2EE? Concept et spécificités de J2EE Architecture et API’s J2EE

Qu’est ce que J2EE? Un ensemble de spécifications d’API’s. Architecture distribuée. Une méthode de packaging et de déploiements de composants.

Pourquoi J2EE? Portabilité - Standards Réutilisation - Composants Performance et Scalabilité - Répartition des charges - Tolérance aux pannes - Transactions

Concepts et spécificités J2EE Les conteneurs Les servlets Java Les JavaServer Pages Les Entreprise JavaBeans Les services Web Les Transactions La sécurité

Architecture et API’s J2EE API définissant des interfaces standards avec un gestionnaire de transactions. www.commentcamarche.net/j2ee/

Transaction Qu’est ce qu’une transaction? Propriétés d’une transaction Attributs d’une transaction Modèles de transactions Problèmes résolues par les transactions Un peu de vocabulaire

Qu’est ce qu’une transaction? Les Transactions sont en fait des ordres passés à la base de données pour valider des événements effectuées sur les données. Une transaction est une unité d’interaction avec le système de gestion de base de données. Elle est traité d’une manière cohérente et fiable indépendamment des autres transactions. Une transaction unique peut regrouper plusieurs requêtes, chacune avec des ordres de lecture ou d’écriture dans la base de données. La commande COMMIT permet de valider une transaction. A contrario, la commande ROLLBACK permet d’annuler une transaction.

Propriétés d’une transaction Une transaction doit être conforme aux propriétés ACID Atomicité Nombreux acteurs : servlet, corba, rmi-iiop, ejbs, DB… Tous votent pour indiquer si la transaction s'est bien passée… Consistance Le système demeure consistent après l'exécution d'une transaction (comptes bancaires ok!)

Propriétés d’une transaction Isolation Empêche les transactions concurrentes de voir des résultats partiels. Chaque transaction est isolée des autres. Implémenté par des protocoles de synchronisation bas niveau sur les BDs… Durabilité Garantit que les mises à jour sur une BD peuvent survivre à un crash (BD, machine, réseau). En général, on utilise un fichier de log qui permet de faire des undos pour revenir dans l'état avant le crash.

Attributs d’une transaction L’attribut d’une transaction contrôle la portée de cette dernière. La figure ci-dessous illustre l’importance du contrôle de l’étendue d’une transaction: la méthode-A commence la transaction et fait appel à la méthode-B de Bean-2. Lors de l’exécution de la méthode-B, est ce qu’elle s’exécute avec la portée de la transaction démarrée par la méthode-A ou elle s’exécute comme une nouvelle transaction? La réponse dépend de l’attribut de la transaction de la méthode-B!

Attributs d’une transaction Required Si le client exécute une transaction qui invoques la méthode du bean entreprise cette dernière s’exécute au sein de la transaction client. Si le client n’est pas associé à une transaction le conteneur démarrera une nouvelle avant d’exécuter la méthode. Requires New Si le client exécute une transaction qui invoques la méthode du bean entreprise, le conteneur suit ces étapes 1- suspendre la transaction client 2- démarrer une nouvelle transaction 3- déléguer l’appel à la méthode 4- reprendre la transaction client après la fin de la méthode. Si le client n’est pas associé à une transaction le conteneur démarrera une nouvelle avant d’exécuter la méthode

Attributs d’une transaction Mandatory Si le client exécute une transaction qui invoques la méthode du bean entreprise cette dernière s’exécute au sein de la transaction client. Si le client n’est pas associé à une transaction le conteneur lève l’exception TransactionRequiredException NotSupported Si le client exécute une transaction qui invoques la méthode du bean entreprise, le conteneur suspend cette dernière avant l’appel de la méthode. Après la fin de la méthode, le conteneur reprend la transaction client. Si le client n’est pas associé à une transaction, le conteneur ne démarrera pas une nouvelle transaction avant l’exécution de la méthode.

Attributs d’une transaction Supports Si le client exécute une transaction qui invoques la méthode du bean entreprise, la méthode s’exécute au sein de la transaction client. Si le cleint n’est pas associé à une transaction le conteneur ne démarrera pas une novelle transaction avant l’appel de la méthode. Never Si le client exécute une transaction qui invoques la méthode du bean entreprise, le conteneur lève l’exception RemoteException.

Attributs d’une transaction(résumé) Attribut de la transaction Transaction Client Méthode métier de la transaction Required Aucun T2 T1 RequiresNew Mandatory Erreur NotSupported Supports Never erreur

Modèles de transaction Il existe deux modèles transactions Flat transactions ou transactions à plat Supportées par les EJBs Nested transactions ou transactions imbriquées Non supportées par les EJBs pour le moment…

Flat Transactions Modèle le plus simple. Après qu'une transaction ait démarré, on effectue des opérations… Si toutes les opérations sont ok, la transaction est confirmée (commited), sinon elle échoue (aborted) En cas de commit, les opérations sont validées (permanent changes) En cas d'abort, les opérations sont annulées (rolledback). L'application est également prévenue…

Transactions Imbriquées Cas simple : on veut faire un tour du monde 1. Notre application achète un billet d’avion de Tunis à Paris, 2. Puis un billet d'avion de Paris à Londres, 3. Puis un billet d'avion de Londres à New-York, 4. L'application s'aperçoit qu'il n'y a plus de billet d'avion disponible ce jour-là pour New-York…  Tout échoue et on annule toutes les réservations ! Avec un modèle de transactions imbriquée, une transaction peut inclure une autre transaction.

Problèmes résolus par les transactions Un transaction est une série d'opérations qui apparaissent sous la forme d'une large opération atomique. Soit la transaction réussit, soit elle échoue. Les transactions s'accordent avec les pannes machines ou réseau. Répondent aux problèmes du partage de données.

Un peu de vocabulaire Objet ou composant transactionnel Un composant bancaire impliqué dans une transaction. Un EJB compte bancaire, un composant .NET, CORBA… Gestionnaire de transaction Celui qui en coulisse gère l'état de la transaction Ressource L'endroit où on lit et écrit les données : un DB, une queue de messages, autre… Gestionnaire de ressource Driver d'accès à une BD, à une queue de message… Implémentent l'interface X/Open XA, standard de facto pour la gestion de transactions…

Le transactionnel en J2EE Transaction gérée par le conteneur Transaction gérée par le bean JTA(Java Transaction API) JTS(Java Transaction Service) Transaction JDBC vs Transaction JTA Récapitulatif

Transaction gérée par le Conteneur Le conteneur EJB définit les frontières de la transaction. On peut utiliser les transactions gérées par le conteneur avec n’importe quel type de Bean entreprise: -session -entité -message Les transactions gérées par le conteneur simplifient le développement : Le code du Bean n’inclut pas des instructions qui délimitent le début et la fin de la transaction.

Transaction gérée par le Conteneur Le conteneur commence la transaction immédiatement avant que la méthode du Bean entreprise démarre et la termine juste avant la sortie de la méthode. Chaque méthode peut être associée à une transaction unique. Les transactions imbriqués ou multiples sont interdites au sein d’une méthode. Les transactions gérées par le conteneur ne requièrent pas que toutes les méthodes soient associées avec des transactions. En déployant le Bean, on doit indiquer quel méthode est associée avec les transactions en spécifiant les attributs de la transaction.

Attribut de la transaction <?xml version="1.0" encoding="UTF-8"?> … <display-name>BankBean</display-name> <ejb-name>BankBean</ejb-name> <home>BankHome</home> <remote>Bank</remote> <ejb-class>BankBean</ejb-class> <session-type>Stateful</session-type> <transaction-type>Container</transaction-type> <container-transaction> <method> <method-intf>Remote</method-intf> <method-name>getCheckingBalance</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> Ejb-jar.xml

Annulation d’une transaction gérée par le conteneur Il existe deux manières pour annuler une transaction gérée par le conteneur: Si une exception système est levée, le conteneur annule automatiquement la transaction. En invoquant la méthode setRollbackOnly de l’interface EJBContext. Si le Bean lève une exception d’application, l’annulation n’est pas automatique mais peut être initialisé par la méthode setRollbackOnly.

Annulation d’une transaction gérée par le conteneur Si une balance négative est détectée transfertToSaving invoque setRollbackOnly et lève une exception d’application (InsufficientBalanceException ). public void transferToSaving(double amount) throws InsufficientBalanceException { checkingBalance -= amount; savingBalance += amount; try { updateChecking(checkingBalance); if (checkingBalance < 0.00) { context.setRollbackOnly(); throw new InsufficientBalanceException(); } updateSaving(savingBalance); } catch (SQLException ex) { throw new EJBException ("Transaction failed due to SQLException: " + ex.getMessage()); Si la mise à jour échoue, ces méthodes lèvent une exception SQLException et la méthode transfertToSaving lève l’exception EJBException.

Annulation d’une transaction gérée par le conteneur Lorsque le conteneur annule une transaction, il annule tous les changements effectués sur les données par les appels SQL au sein de la transaction. le conteneur annule les variables d’instance affectées par un Bean entité(invocation de la méthode EJBLoad). Pour un Bean session, le reset des variables d’instance, modifiées par la transaction, doit être fait explicitement.  Implémentation de l’interface SessionSynchronization.

Synchroniser les variables d’instance d’un Bean session public void afterBegin() { System.out.println("afterBegin()"); try { checkingBalance = selectChecking(); savingBalance = selectSaving(); } catch (SQLException ex) { throw new EJBException("afterBegin Exception: " +ex.getMessage()); }

Synchroniser les variables d’instance d’un Bean session public void afterCompletion(boolean committed) { System.out.println("afterCompletion: " + committed); if (committed == false) { try { checkingBalance = selectChecking(); savingBalance = selectSaving(); } catch (SQLException ex) { throw new EJBException("afterCompletion SQLException:       " + ex.getMessage()); }

Transaction gérée par le Bean Dans une transaction gérée par le Bean, c’est le Bean(session ou message) qui marque explicitement les frontières de la transaction. Un Bean entité ne peut pas gérée une transaction, c’est le conteneur qui s’encharge. Une transaction gérée par le Bean peut être - Une transaction JDBC - Une transaction JTA

JDBC Transaction Une transaction JDBC est contrôlée par le gestionnaire de transaction du DBMS. Pour coder une transaction JDBC, on invoque les méthodes commit et rollback de l’interface java.sql.Connection La transaction démarre avec la première instruction sql qui suit la plus récente commande commit,rollback ou connect .

JDBC Transaction public void ship (String productId, String orderId, int quantity) { try { makeConnection(); // annule la validation requête par requête con.setAutoCommit(false); updateOrderItem(productId, orderId); updateInventory(productId, quantity); //valider toutes les requêtes si succès des mises à jour con.commit(); } catch (Exception ex) { //annuler toutes les requêtes con.rollback(); throw new EJBException("Transaction failed: " + ex.getMessage()); } catch (SQLException sqx) { //si le rollback échoue une exception EJB est levée throw new EJBException("Rollback failed: " + sqx.getMessage()); } } finally { releaseConnection();

JTA transaction JTA est l’abréviation de Java Transaction API. Cette API permet de délimiter les transactions de manière à les rendre indépendante de l’implémentation du gestionnaire de transaction. Le serveur d’application implémente le gestionnaire de transaction avec le Java Transaction Service, mais les méthodes JTS sont appelées indirectement.  les méthodes JTA invoquent les procédures bas niveau JTS. Une transaction JTA est contrôlée par le gestionnaire de transaction J2EE. Le gestionnaire de transaction J2EE ne supporte pas les transactions imbriquées.

JTA transaction JTA permet au programmeur de contrôler la gestion de transaction dans une logique métier. Il pourra faire les begin, commit, rollback, etc… Il peut utiliser JTA dans des EJB mais aussi dans n'importe quelle application cliente. JTA se compose de deux interfaces distinctes.

javax.transaction.UserTransaction JTA : deux interfaces Une pour les gestionnaires de ressources X/Open XA Une pour le programmeur désirant contrôler les transactions : javax.transaction.UserTransaction

L'interface javax.transaction.UserTransaction

Mise à jour de bases de données multiples. JTA Transaction JTA permet la mise à jour de bases de données multiples dans la même transaction. Le gestionnaire de transaction s’assure que toutes les bases de données sont misent à jour au cours de la même transaction. Mise à jour de bases de données multiples. Mise à jour de bases de données multiples à travers deux serveurs J2EE différents.

JTS (Java Transaction Service) JTS spécifie l’implémentation d’un gestionnaire de transaction qui supporte: - La spécification JTA(haut niveau). - L’implémentation du mapping Java de l’OMG Object Transaction Service OTS (bas niveau) . JTS utilise les interfaces CORBA OTS pour l’interopérabilité et la portabilité. JTS offre des méthodes pour démarrer,valider et annuler des transactions ainsi que les moyens de retrouver le contexte des transactions courantes.

JTS (Java Transaction Service) Les spécifications JTS sont destinés aux développeurs de gestionnaires de transaction et de serveurs d’application avec le langage de programmation Java.

JTS (Java Transaction Service) Les services de transactions distribués dans Enterprise Java middleware font appel a cinq acteurs - Un gestionnaire de transaction(Transaction Manger): Il offre les services et les fonctions requises pour supporter les limites, la synchronisation et le contexte de propagation des transactions. -Un serveur d’application: Il offre l’infrastructure requise pour l’environnement d’exécution d’une application. - Un gestionnaire de Ressource (Resource Manager): Exemple serveur de base de données.

JTS (Java Transaction Service) -Une application transactionnel basée sur les composants opèrant dans un serveur d’application qui gère les transactions à travers une configuration déclarative d’attributs. Exemple une application développée a base d’EJB. - Un gestionnaire de ressources de communication(comminucation resource manager): Supporte la propagation du contexte de transaction et l’accès aux services de transactions pour les requêtes entrantes et sortantes.

Interface privée qui permet l’interaction entre le module JTA et l’implémentation bas niveau OTS.

Le TellerBean Exemple Accès à JTS L’invocation de begin et commit délimite les mises à jour de la base de données import javax.transaction.*; public void withdrawCash(double amount) { UserTransaction ut = context.getUserTransaction(); try { ut.begin(); updateChecking(amount); machineBalance - = amount; insertMachine(machineBalance); ut.commit(); } catch (Exception ex) { ut.rollback(); } catch (SystemException syex) { throw new EJBException ("Rollback failed: " + syex.getMessage()); } throw new EJBException ("Transaction failed: " + ex.getMessage()); Si la mise à jour échoue, le code appelle la méthode rollback et lève une exception EJBException.

JDBC vs JTA Transaction JDBC Transaction JTA Appelle l’interface java.sql.Connection Appelle l’interface javax.transaction.UserTransaction Auto validée à la fermeture de la connexion Validation explicite avec la commande commit Confiné à une seule base de données Permet la mise à jour de bases de données multiples

Récapitulatif CMP EJB Entité BMP Géré par le Bean EJB Session Géré par le conteneur Spécification des attributs de transaction appropriés dans le descripteur de déploiement. En cas de rollback, restauration de l’état initial grâce à la méthode ejbLoad(). BMP En cas de rollback, les variables d’instance sont restaurés par le conteneur. EJB Session Géré par le Bean Le développeur se charge de tous les aspects de la transaction. Utilisation des transactions JDBC ou JTA. Conteneur Spécification des attributs de transaction appropriés dans le descripteur de déploiement Le Bean implémente SessionSynchronisation pour avoir une notification de l’état de la transaction en cours. Le conteneur annule toute transaction JDBC dont la méthode a échoué.

Conclusion Les transactions sont une des bases fondamentale des applications entreprises Nécessité de savoir les orchestrées et les manipuler. Engouement mondial pour le commerce en ligne.  Nécessité de la prise en charge des transactions imbriquées.

Bibliographie www.java.sun.com/products/jta www.java.sun.com/products/jts www.java.sun.com/j2ee www.rangiroa.essi.fr/cours/ejb www.eyrolles.com www.j2eeolympus.com