Transactions GLG 204java.cnam.fr/iagl/glg204_2010/cours/Transaction.pdf · Flat transactions • Modèle le plus simple. • Après qu'une transaction ait démarré, on effectue des

TransactionsGLG 204

Transactions Locales

• Crash

• logs

• ACiD

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 commité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 (rolled back). L'application est également prévenue…

Comment s'effectue le rollback ?

• Tant qu'il n'y a pas de commit, les modifications à une BD ne sont pas permanentes…

• Dans un contexte de composants, tout est fait en coulisse. Vous n'avez pas à vous préoccuper de l'état de votre bean… Il sera restauré en cas de rollback.

Les propriété 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!)

• 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.

JDBC

Gestion des transactions

• Par défaut : auto-commit

• Pour modifier

• Pour un commit explicite :

• Pour un rollback :

uneConnection.setAutoCommit(false);

uneConnection.commit();

uneConnection.rollback();

Exemple

• public static void executeTransaction(Connection con) { • try { //Switch to manual transaction mode by setting //autocommit to false.

Note that this starts the first manual transaction.con.setAutoCommit(false);– Statement stmt = con.createStatement(); stmt.executeUpdate("INSERT INTO

Production.ScrapReason(Name) VALUES('Wrong size')"); – stmt.executeUpdate("INSERT INTO Production.ScrapReason(Name)

VALUES('Wrong color')"); • con.commit(); //This commits the transaction and starts a new one.

– stmt.close(); //This turns off the transaction. – System.out.println("Transaction succeeded. Both records were written to the

database."); • } catch (SQLException ex) • { ex.printStackTrace(); • try { con.rollback();• System.out.println("Transaction failed. No records were written to the

database."); • } catch (SQLException se) { se.printStackTrace(); } } }

Transactions JDBC

• When one user is accessing data in a database, another user maybe accessing the same data at the same time. If, for instance, thefirst user is updating some columns in a table at the same time thesecond user is selecting columns from that same table, it is possible for the second user to get partly old data and partly updated data. For this reason, DBMSs use transactions to maintain data in a consistent state (data consistency) while allowing more than oneuser to access a database at the same time (data concurrency).

• A lock is a mechanism that prohibits two transactions frommanipulating the same data at the same time.

• For example, a table lock prevents a table from being dropped if there is an uncommitted transaction on that table.

• A row lock prevents two transactions from modifying the same row, or it prevents one transaction from selecting a row while anothertransaction is still modifying it.

Multi-Processus

• http://www-poleia.lip6.fr/~doucet/CoursBDR/BDR9-transactions.pdf

• http://www-valoria.univ-ubs.fr/Michele.Raphalen/cours/bd2.pdf

• http://www.hec.unil.ch/gcampono/Teaching/BDA/Slides/BDA11_Concurrence.pdf

Historique

Fonctions d’un TM

• Fonctions transactionnelles

• Etapes du traitement transactionnel

– – traduire la requête utilisateur en format interne au moniteur

– – déterminer le type de transaction et le programme nécessaire

– à son exécution

– – débuter la transaction et lancer son exécution

– – valider, ou abandonner, la transaction

– – retourner le résultat à l’émetteur de la requête

• Fonctions systèmes

Un moniteur assure aussi :

– – équilibrage de charge entre requêtes et serveurs

– – résistance aux pannes (client, serveur)

– – gestion de configuration (processus, sessions, ...)

– – contôle de performances et réglage

– – sécurité par certification des requêtes

Historique

HistoriqueOTS, JTS, and JTA

• Motivation: Need an API to start and end transactions• EJB/J2EE transaction control dates back to CORBA

days– Control CORBA transactions via the Object Transaction Service

(OTS)

• Sun took the Java mapping of OTS and split it into two parts:– JTS: Interfaces that make any database work with any

transaction service– JTA: Enables you to control when transactions begin and end

• The takeaway point:– Vendors care about JTS.– We care only about JTA.

CORBA et OTS

• http://www-poleia.lip6.fr/~doucet/CoursBDR/BDR9-transactions.pdf

• http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html

• http://www.ciaranmchale.com/corba-explained-simply/object-transaction-service.html

Transactions distribuées

http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html

JTA Transactions

• javax.transaction.UserTransaction interface.

• Cette API fournit les interfaces pour travailler avec des transactions distribuées sur plusieurs bases de données, ou même des ressources quine sont pas des bases de données, d’une façonindépendante de l’implémentation du gestionnaire de transactions

• Elle est utilisée par les serveurs d’applications pour les transactions gérées par le container

avax.transaction Interface UserTransaction

public abstract interface UserTransactionThe UserTransaction interface defines the methods that allow an application to explicitly manage transaction boundaries.

Method Summary

void beginbeginbeginbegin()Create a new transaction and associate it with the current thread.

void commitcommitcommitcommit()Complete the transaction associated with the current thread.

int getStatusgetStatusgetStatusgetStatus()Obtain the status of the transaction associated with the current thread.

void rollbackrollbackrollbackrollback()Roll back the transaction associated with the current thread.

void setRollbackOnlysetRollbackOnlysetRollbackOnlysetRollbackOnly()Modify the transaction associated with the current thread such that the only possible outcome of the transaction is to roll back the transaction.

void setTransactionTimeoutsetTransactionTimeoutsetTransactionTimeoutsetTransactionTimeout(int seconds)Modify the value of the timeout value that is associated with the transactions started by the current thread with the begin method.

javax.transaction

Interface Transaction

public abstract interface TransactionThe Transaction interface allows operations to be performed against the transaction in the target Transactioin object. A Transaction object is created corresponding to each global transaction creation. The Transaction object can be used for resource enlistment, synchronization registration, transaction completion and status query operations.

Method Summary

void commitcommitcommitcommit()Complete the transaction represented by this Transaction object

boolean delistResourcedelistResourcedelistResourcedelistResource(XAResource xaRes, int flag)Delist the resource specified from the current transaction associated with the calling thread.

boolean enlistResourceenlistResourceenlistResourceenlistResource(XAResource xaRes)Enlist the resource specified with the current transaction context of the calling thread


void registerSynchronizationregisterSynchronizationregisterSynchronizationregisterSynchronization(Synchronization sync)Register a synchronization object for the transaction currently associated with the calling thread.

void rollbackrollbackrollbackrollback()Rollback the transaction represented by this Transaction object.


javax.transaction

Interface TransactionManager

public abstract interface TransactionManagerThe TransactionManager interface defines the methods that allow an application server to manage transaction boundaries.

Method Summary

void beginbeginbeginbegin()Create a new transaction and associate it with the current thread.

void commitcommitcommitcommit()Complete the transaction associated with the current thread.


Transaction

getTransactiongetTransactiongetTransactiongetTransaction()Get the transaction object that represents the transaction context of the calling thread

void resumeresumeresumeresume(Transaction tobj)Resume the transaction context association of the calling thread with the transaction represented by the supplied Transaction object.

void rollbackrollbackrollbackrollback()Roll back the transaction associated with the current thread.


void setTransactionTimeoutsetTransactionTimeoutsetTransactionTimeoutsetTransactionTimeout(int seconds)Modify the value of the timeout value that is associated with the transactions started by the current thread with the begin method.

Transaction

suspendsuspendsuspendsuspend()Suspend the transaction currently associated with the calling thread and return a Transaction object that represents the transaction context being

suspended.

javax.transaction

Interface Synchronization

public abstract interface SynchronizationThe transaction manager supports a synchronization mechanism that allows the interested party to be notified before and after the transaction completes. Using the registerSynchronization method, the application server registers a Synchronization object for the transaction currently associated with the target Transaction object.

Method Summary

void afterCompletionafterCompletionafterCompletionafterCompletion(int status)This method is called by the transaction manager after the transaction is committed or rolled back.

void beforeCompletionbeforeCompletionbeforeCompletionbeforeCompletion()This method is called by the transaction manager prior to the start of the transaction completion process.

javax.transaction.xa

Interface XAResourceMethod Summary

void commitcommitcommitcommit(Xid xid, boolean onePhase)Commit the global transaction specified by xid.

void endendendend(Xid xid, int flags)Ends the work performed on behalf of a transaction branch.

void forgetforgetforgetforget(Xid xid)Tell the resource manager to forget about a heuristically completed transaction branch.

int getTransactionTimeoutgetTransactionTimeoutgetTransactionTimeoutgetTransactionTimeout()Obtain the current transaction timeout value set for this XAResource instance.

boolean

isSameRMisSameRMisSameRMisSameRM(XAResource xares)This method is called to determine if the resource manager instance represented by the target object is the same as the resouce manager instance represented

by the parameter xares.int prepareprepareprepareprepare(Xid xid)

Ask the resource manager to prepare for a transaction commit of the transaction specified in xid.

Xid[] recoverrecoverrecoverrecover(int flag)Obtain a list of prepared transaction branches from a resource manager.

void rollbackrollbackrollbackrollback(Xid xid)Inform the resource manager to roll back work done on behalf of a transaction branch

boolean

setTransactionTimeoutsetTransactionTimeoutsetTransactionTimeoutsetTransactionTimeout(int seconds)Set the current transaction timeout value for this XAResource instance.

void startstartstartstart(Xid xid, int flags)Start work on behalf of a transaction branch specified in xid If TMJOIN is specified, the start is for joining a transaction previously seen by the resource

manager.

The XA interface defines the contract between a Resource Manager and a Transaction Manager in a distributed

transaction processing (DTP) environment. A JDBC driver or a JMS provider implements the this interface to support

association between a global transaction and a database or message service connection.

The UserTransaction interface• You should only care about one JTA interface, UserTransaction:

interface javax.transaction.UserTransaction {public abstract void begin();public abstract void commit();public abstract void rollback();public abstract void setRollbackOnly();public abstract int getStatus();public abstract void setTransactionTimeout(int);

}

interface javax.transaction.Status {public static final int STATUS_ACTIVE;public static final int STATUS_MARKED_ROLLBACK;public static final int STATUS_PREPARED;public static final int STATUS_COMMITTED;public static final int STATUS_ROLLEDBACK;public static final int STATUS_UNKNOWN;public static final int STATUS_NO_TRANSACTION;public static final int STATUS_PREPARING;public static final int STATUS_COMMITTING;public static final int STATUS_ROLLING_BACK;

}

Looking up the UserTransactioninterface

• The JTA UserTransaction interface is actually an interface to the application server’s transaction manager– It’s the public API that the transaction manager exposes

• The app server is responsible for publishing this interface to you• To get a reference to this, you need to lookup the interface via JNDI

– Just like you use JNDI to lookup EJB homes, JDBC drivers, etc.– Application server must publish JTA under

"java:comp/UserTransaction"

– Note that weblogic violates this– Code that works with weblogic:Context ctx = new InitialContext(...);

javax.transaction.UserTransaction userTran =(javax.transaction.UserTransaction)PortableRemoteObject.narrow(

ctx.lookup(“javax.transaction.UserTransaction”),javax.transaction.UserTransaction.class);

Distributed Transactions• Motivation: Have 2 data sources in 1 transaction

– Example: Database and Message Queue

• Normal commit won't work.Bank Teller

Session Bean

Bank Account #1

Entity Bean

Bank Account #2

Entity Bean

Money

Market

Database

1: withdraw() 3: deposit()

2: balance -= amt 4: balance += amt

5: ejbStore() 6: ejbStore()7: commit()

8: Checking

database

CRASHES!!

Checking

Database

The 2-phase commit solution• Idea: split commit into 2 phases

– Phase 1 – Database operations are complete– Phase 2 – Commit or rollback operations

Bank Teller

Session Bean

Bank Account #1

Entity Bean

Bank Account #2

Entity Bean

Money

Market

Database

1: withdraw() 3: deposit()

2: balance -= amt 4: balance += amt

5: ejbStore() 6: ejbStore()

7: prepare()

10: Checking

database

CRASHES!!

Checking

Database

9: commit()

8: prepare()

11: Checking

database

REBOOTS!!

EJB

http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html

Gestion des transactions avec les EJBs

• Seul le modèle flat est supporté.• Le code que le développeur écrit, s'il décide de

gérer les transactions par programmation, demeurera d'un très haut niveau,– Simple vote pour un commit ou un abort,– Le container fait tout le travail en coulisse…

• 3 manières de gérer les transactions1. Par programmation,2. De manière déclarative,3. De manière initiée par le client.

Gestion des transactions par programmation

• Responsable : le développeur de bean

• Il décide dans son code du begin, du commit et du abort

• Ex: le banquier

Gestion des transactions déclarative

• Le bean est automatiquement enrôlé (enrolled) dans une transaction…

• Le container fait le travail…

Gestion des transactions déclarative

• Génial pour le développeur!

Transactions initiées par le client

Que choisir ?

• Par programmation : contrôle très fin possible…

• Déclaratif : super, mais granularité importante,

• Contrôlé par le client– N'empêche pas de gérer les transactions dans le bean (par programmation ou de manière déclarative)

– Ajoute une couche de sécurisation en plus, qui permet de détecter les crashes machine, réseau, etc…

Container-Managed Transactions

• By default if no transaction demarcation isspecified enterprise beans use container-managed transaction demarcation.

• Typically, the container begins a transaction immediately before an enterprise bean methodstarts. It commits the transaction just before themethod exits. Each method can be associatedwith a single transaction. Nested or multiple transactions are not allowed within a method.

Transactions et entity beans

• Dans une transaction, on accède à un entitybean :– À un moment donné : chargement des données de la DB dans le bean,

– Un verrou (lock) est acquis sur la DB, assurant la consistance,

– Juste après l'appel du commit de la transaction, les données sont sauvegardées, la DB est mise à jour et libère le verrou.

– On a donc le code d’accès à la BD, le code des méthodes métiers et l'appel à la sauvegarde dans la BD qui se trouvent dans la transaction.

Transactions et entity beans

• Conséquence : un entity bean n'accède pas à la BD à chaque appel de méthode, mais à chaque transaction.

• Si un entity s'exécute trop lentement, il se peut qu'une transaction intervient pour chaque appel de méthode, impliquant des accès BD.

• Solution : inclure plusieurs appels de méthodes de l'entity dans une même transaction.

• Se fait en précisant les attributs de transaction du bean.

transaction attributeFigure 33-1 Transaction Scope

can have one of the following values:•Required•RequiresNew•Mandatory•NotSupported•Supports•Never

Setting Transaction Attributes

@TransactionAttribute(NOT_SUPPORTED) @Stateful public class TransactionBean implements Transaction {

...

@TransactionAttribute(REQUIRES_NEW) public void firstMethod() {...}

@TransactionAttribute(REQUIRED) public void secondMethod() {...}

public void thirdMethod() {...}

public void fourthMethod() {...}

}

Attributs de transactions gérées par le container

• Pour chaque bean, on précise des attributs de transaction

– On peut spécifier des attributs pour le beanentier ou méthode par méthode,

– On peut préciser les deux… Le plus restrictif gagne.

– Chaque méthode métier doit être traitée (globalement ou individuellement)

Par défaut : attribut = REQUIRED

• Génial pour le développeur!

Valeur des attributs de transaction

• Required– Le bean est toujours dans une transaction.

– Si une transaction pour ce bean existe, alors le bean la rejoint (join), sinon, le container crée une nouvelle transaction.

• La plupart du temps proposé comme valeur par défaut par les IDEs et leurs Wizards/éditeurs de descripteurs…

Attribut de transaction : Required

• Exemple : passage d'une commande– Un session bean utilise deux entity beans : un beancarte de crédit et bean commande,

– Lors d'un passage de commande, on envoie la commande, puis on débite la carte de crédit,

– Si le bean session a comme attribut de transaction Required, une transaction est crée dès que le passage de commande démarre,

– Lors de l'appel au bean Commande, si celui-ci est également en mode Required, il rejoindra la transaction en cours. Idem lors de l'appel au bean Carte de Crédit,

– Si un problème se pose, la carte de crédit ne sera pas débitée et la commande ne sera pas passée.

Attribut de transaction : RequiresNew

• RequiresNew– Le bean est toujours dans une nouvelle transaction.

– Si une transaction existe, elle est suspendue,

– Lorsque la nouvelle transaction se termine (abort ou commit), l'ancienne transaction est résumée.

• Utile si on veut respecter les propriétés ACID dans l'unité du bean, sans qu'une logique externe intervienne.

Attribut de transaction : Supports

• Supports– Semblable à Required sauf que si une transaction n'existe pas, elle n'est pas crée.

– Si l'exécution du bean intervient dans une transaction existante, il la rejoint néanmoins.

• A éviter pour les applications mission-

critical !– Dans ce cas, choisir Required.

Attribut de transaction : Mandatory

• Mandatory– Une transaction doit exister lorsque le bean est exécuté.

– Si ce n'est pas le cas, javax.ejb.TransactionRequiredException estlevée et renvoyée au client.

– Si le client est local, c'estjavax.ejb.TransactionRequiredLocalException qui est

levée…

• Attribut sûr, qui oblige le client à inscrire sa logique dans une transaction avant d'appeler le bean.

Attribut de transaction : NotSupported

• NotSupported– Le Bean ne supporte pas les transactions,

– Si une transaction existe lors de l'appel du bean, la transaction est suspendue, le bean s'exécute, puis la transaction est résumée.

• Utiliser cet attribut lorsque les propriétés ACID ne sont pas importantes…– Exemple : un bean qui fait des statistiques toutes les dix minutes en parcourant une BD. On tolère que les données lues ne sont peut-être pas à jour…

• Gain en performance évident.

Attribut de transaction : Never

• Never– Le Bean ne supporte pas les transactions,

– Une exception javax.rmi.RemoteException oujavax.ejb.EJBException est envoyéeau client si une transaction existe au moment de l'appel du bean.

• A utiliser lors du développement d'une logique non transactionnelle.

Résumé sur les attributs de transaction

• Soit T1 une transaction initiée par le client, T2 la nouvelle transaction initiée par le bean appelé.

Tous les attributs ne s'appliquent pas à tous les

beans

Rolling Back a

Container-Managed Transaction

• There are two ways to roll back a container-managed transaction. – First, if a system exception is thrown, the container will automatically roll back the transaction.

– Second, by invoking the setRollbackOnly method ofthe EJBContext interface, the bean method instructsthe container to roll back the transaction. If the beanthrows an application exception, the rollback is notautomatic but can be initiated by a call to setRollbackOnly.

Methods Not Allowed

• in Container-Managed Transactions

– You should not invoke any method that mightinterfere with the transaction boundaries set by thecontainer. The list of prohibited methods follows:• The commit, setAutoCommit, and rollback methods ofjava.sql.Connection

• The getUserTransaction method of javax.ejb.EJBContext

• Any method of javax.transaction.UserTransaction

– You can, however, use these methods to set boundaries in application-managed transactions.

stateful session bean

• Returning without Committing

• In a stateless session bean with bean-managed transactions, a business method must commit or roll back a transaction beforereturning. However, a stateful session bean does not have thisrestriction.

• In a stateful session bean with a JTA transaction, the association between the bean instance and the transaction is retained acrossmultiple client calls. Even if each business method called by theclient opens and closes the database connection, the association isretained until the instance completes the transaction.

• In a stateful session bean with a JDBC transaction, the JDBC connection retains the association between the bean instance andthe transaction across multiple calls. If the connection is closed, theassociation is not retained.

Isolation de transaction

• Le "I" de ACID !

• L'isolation coûte cher en termes de performances,

• Nécessité de pouvoir régler le niveau d'isolation entre transactions concurrentes !


• Un exemple : deux instances A et B d'un même composant accèdent à une même donnée X dans une BD.

• Chacune1. Lit la valeur de X,

2. Ajoute 10 à la valeur lue,

3. Écrit la nouvelle valeur dans la BD

• Si chaque instance effectue ces opérations de manière atomique, pas de problèmes !


• Ceci n'est pas garanti selon le niveau d'isolation choisi.

• Par exemple, si on ne prend pas de précaution1. A lit X, dans la BD on a X=0,

2. B lit X, dans la BD on a X=0,

3. A ajoute 10 à X et écrit le résultat dans la BD. Dans la BD on a X=10,

4. B ajoute 10 à sa copie de X et écrit le résultat dans la BD. Dans la BD on a X=10, ce qui est anormal !

– On a perdu le traitement effectué par A !


• Solution : utiliser un verrou.

• Chaque composant1. Demande un verrou,

2. Fait le travail précédent sur X,

3. Libère le verrou

• Gestion de file d'attente… exclusion mutuelle, etc…

• Tout ceci peut-être réglé avec les EJBs

Niveau d'isolation avec les EJB

• Le niveau d'isolation limite la façon dont les transactions multiples et entrelacées interfèrent les unes sur les autres dans une BD multi-utilisateur.

• 3 types de violations possibles1. Lecture brouillée,

2. Lecture ne pouvant être répétée,

3. Lecture fantôme.


• Lecture brouillée– La transaction T1 modifie une ligne, la transaction T2 lit ensuite cette ligne,

– Puis T1 effectue une annulation (rollback),

– T2 a donc vu une ligne qui n'a jamais vraiment existé.

• Lecture ne pouvant être répétée– T1 extrait une ligne,

– T2 met à jour cette ligne,

– T1 extrait à nouveau la même ligne,

– T1 a extrait deux fois la même ligne et a vu deux valeurs différentes.


• Lecture fantôme– T1 lit quelques lignes satisfaisant certaines conditions de recherche,

– T2 insère plusieurs lignes satisfaisant ces mêmes conditions de recherche,

– Si T1 répète la lecture elle verra des lignes qui n'existaient pas auparavant. Ces lignes sont appelées des lignes fantômes.


N'autorise aucune

des trois violations

TRANSACTION_SERIALIZABLESerialisable

Autorise les lignes

fantômes mais pas

les deux autres

violations

TRANSACTION_REPEATABLE_READ

Repeatable

Autorise les lectures

ne pouvant être

répétées et les lignes

fantômes, n'autorise

pas les lectures

brouillées

TRANSACTION_READ_COMMITED

Commited

Autorise l'ensemble

des trois violations

TRANSACTION_READ_UNCOMMITED

Uncommite

d

DescriptionSyntaxeAttribut

Quel niveau utiliser

• Uncommited– Uniquement si on est sûr qu'une transaction ne pourra être mise en concurrence avec une autre.

– Performant mais dangereux !– A éviter pour les applications mission-critical !

• Commited– Utile pour les applications qui produisent des rapports sur une base de donnée. On veut lire des données consistances, mêmes si pendant qu'on les lisait quelqu'un était en train de les modifier.

– Lisent un snapshot des données commitées…– Niveau d'isolation par défaut de la plupart des BD(Oracle…)

Quel niveau utiliser

• Repeatable– Lorsqu'on veut pouvoir lire et modifier des lignes, les relire au cours d'une même transaction, sans perte de consistance.

• Serialisable– Pour les applications mission-critical qui nécessitent un niveau d'isolation absolu, ACID 100% !

– Attention ,les performances se dégradent à vitesse grand V avec ce mode !

Comment spécifier ces niveaux ?

• Transactions gérées par le bean– Appel de java.sql.Connection.SetTransactionIsolation(

...).

• Transactions gérées par le container– Non, on ne peut pas spécifier le niveau d'isolation dans le descripteur !

– On le fera via le driver JDBC, ou via les outils de configuration de la DB ou du container,

– Problèmes de portabilité !

Deux stratégies

• Lorsqu'on veut gérer les transactions, on doit toujours choisir entre deux stratégies

1. Stratégie pessimiste– Tout peut foirer, on prend donc un verrou lors des

accès BD, on fait notre travail, puis on libère le verrou.

2. Stratégie optimiste– Peu de chance que ça foire, espère que tout va bien

se passe.

– Néanmoins, si la BD détecte une collision, on fait un rollback de la transaction.

Que faire dans le code EJB ???

• Ok, nous avons vu comment spécifier le type de gestion de transaction, gérée par le bean ou le container,

• Nous avons vu les niveaux d'isolations, que l'on spécifie la plupart du temps via les pilotes JDBC,

• Mais que faire en cas de rollback par exemple– On ne peut pas re-essayer indéfiniment d'exécuter une transaction, on peut envoyer une Exception au client…

– On veut également être tenu au courant de ce qu'il se passe pendant l'exécution d'une transaction.


• En cas de rollback, si on envoie une Exception au client, que faire de l'état du bean ?– Si le bean est stateful, on risque d'avoir un état incorrect (celui qui a provoqué l'échec de la transaction),

– Lors du design d'un bean, il faut prévoir la possibilité de restaurer un état correct,

– Le container ne peut le faire pour vous car le traitement est en général spécifique à l'application,

– Il peut néanmoins vous aider à réaliser cette tâche.


• L'EJB peut implementer une interface optionnelle javax.ejb.SessionSynchronization

public interface javax.ejb.SessionSynchronization {

public void afterBegin();

public void beforeCompletion();

public void afterCompletion(boolean);

}

• Uniquement pour les session beans stateful

Que faire dans le code EJB ???• Le container appelle afterCompletion() que la transaction se soit

terminée par un commit ou par un abort– Le paramètre de la méthode nous signale dans quel cas on se trouve

public class CountBean implements SessionBean, SessionSynchronization {public int val;public int oldVal;

public void ejbCreate(int val) {this.val=val;this.oldVal=val;}

public void afterBegin() { oldVal = val;}public void beforeCompletion() {}public void afterCompletion(boolean b) { if (b == false) val = oldVal; }

public int count() { return ++val; }public void ejbRemove() {}public void ejbActivate() {}public void ejbPassivate() {}public void setSessionContext(SessionContext ctx) {}}

JMS

• http://lsrwww.epfl.ch/webdav/site/lsrwww/shared/Enseignement/SysRep07/Slides/JMS.pdf

• http://camos.buniet.free.fr/LB/Distribue7.pdf

Transactions JMS

Une transaction JMS permet de grouper l'envoi de plusieurs messages oula réception de plusieurs messages.

Exemple d'envoi transactionnel:• un client JMS envoie m1 et m2, mais ne souhaite pas qu'en cas dedéfaillance (du client) seul m1 soit reçu par un serveur JMS.

Exemple de réception transactionnelle:• Un client JMS souhaite recevoir deux messages m1 et m2, et nesouhaite pas qu'en cas de défaillance (du client) seul m1 ait été reçu ettraité.

Transactions et Message-Driven Beans

• Bean-Managed Transactions– La transaction commence et se termine après que le message

a été reçu par le MDB.

– On indique dans le descripteur de déploiement les aknowledgement modes pour indiquer au container comment accuser réception…

• Container-Managed Transactions– La réception du message s'inscrit dans la même transaction

que les appels de méthodes métier du MDB. En cas de problème, la transaction fait un rollback. Le container envoi accusé de réception (message acknowledgement)

• Pas de transaction– Le container accusera réception après réception. Quand

exactement, ce n'est pas précisé…

Transactions et Message-Driven Beans

• Que choisir ?• Si on décide de ne pas laisser le container gérer les

transactions, on a pas de moyen de conserver le message dans la queue de destination si un problème arrive.– On choisit Container-Managed Transaction

• Piège : si un MDB est expéditeur et consommateur du message, le tout intervient dans une même transaction– Impossible de terminer ! Le message expédié n'est pas mis dans

la queue de destination de manière définitive tant que l'envoi n'est pas commité.

– Donc le message ne peut être consommé! Cqfd.– Solution : appeler commit() sur l'objet JMS session juste après

l'envoi.

Transactions JMS (2)• Une transaction JMS est indiquée par un paramètre au moment de lacréation de la connexion entre le client JMS et le serveur JMS• La méthode commit() est appelée pour indiquer la fin de latransaction

Exemple 1: transaction de l’émetteur

Les messages sont gardés par le serveur JMS; ils ne sont pas délivrés à unclient JMS tant que commit() n'a pas été invoqué. Si le client JMS invoquerollback() (au lieu de commit()), les messages sont détruits.

Transactions JMS (3)

Exemple 2: transaction du récepteur

Les messages envoyés au client JMS sont gardés par le serveur JMS;

ils sont détruits uniquement lorsque le client invoque commit().Si le client invoque rollback() (au lieu de commit()), les messagesne sont pas détruits par le serveur JMS.

Transactions JMS (4)

• Il est également possible de grouper dans une transaction une réceptionet un envoi de messages (par ex. réception d'une queue q1 et envoidans une queue q2)

• Par contre, ne jamais grouper dans une transaction (1) un envoi demessages, suivi (2) d'une réception de messages. Cela provoque uninterblocage!

• http://www.peg.com/techpapers/monographs/logging/logging.htmlhttp://www.ibm.com/developerworks/library/j-jtp0305.htmlhttp://www.subbu.org/articles/jts/JTS.htmlhttp://archive.devx.com/java/free/articles/dd_jta/jta-1.asphttp://rangiroa.essi.fr/cours/ejb/03-10-J2EE-buffa-transaction.pdfhttp://edocs.beasys.com/wls/docs60/jta/gstrx.htmlhttp://www.java-tips.org/java-ee-tips/enterprise-java-beans/introduction-to-the-java-transactio.htmlhttp://www.datadirect.com/developer/jdbc/topics/jta/index.ssphttp://www.ibm.com/developerworks/java/library/j-jtp0410/ftp://ftp.omg.org/pub/docs/formal/00-06-28.pdfhttp://www.javaworld.com/jw-07-2000/jw-0714-transaction.htmlhttp://www.jguru.com/faq/view.jsp?EID=2563

• argentera.inria.fr/wiki/pub/cours%20complet.*ppt*

http://www-poleia.lip6.fr/~doucet/CoursBDR/BDR9-transactions.pdf

http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-J2EE-2005/44_JTA.pdf

http://www.peg.com/techpapers/monographs/logging/logging.html

http://www.ibm.com/developerworks/java/library/j-jtp0410/

http://www.ibm.com/developerworks/library/j-jtp0305.html

http://www.subbu.org/articles/jts/JTS.html

research.microsoft.com/~gray/wics_96_tp/06_ORBs.*ppt* www.srdc.metu.edu.tr/webpage/seminars/J2EE/Application%20Servers.*ppt

http://www.nyu.edu/classes/jcf/g22.3033-005/slides/session8/g22_3033_011_c81.pdf

• Sérialisation

• http://www-valoria.univ-ubs.fr/Michele.Raphalen/cours/bd2.pdf

• http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html

What is JTA?

• JTA specifies standard Java application programming interfaces (API‘s) between a• transaction manager and the parties involved in a distributed transaction• system: the resource manager, the application server, and the transactional• applications.• The JTA describes 3 API‘s:• 1. UserTransaction: The javax.transaction.UserTransaction API allows the application

to• control the transaction boundaries programmatically. In simple words, this high level

API• allows to mark the beginning and the end of a global (distributed) transaction.• 2. Transaction Manager: The javax.transaction.TransactionManager API is designed

as• interface for the application server. The application server is able to specify

transaction• boundaries in charge of the managed application with this high level API.• 3. XAResource: The javax.transaction.xa.XAResource API is a Java implementation

of the• industry standard XA Interface based on the X/Open CAE specification. This is the

low level• API between transaction manager and the database. This interface will allow you to

speak 2PC• with directly the different databases involved in a distributed transaction.• Attention: the JDBC-Driver has to support the XARessource extensions!

Architecture

Définitions

• EntityManagerFactory– An entity manager factory provides entity manager instances, all instances are configured to

connect to the same database, to use the same default settings as defined by the particularimplementation, etc. You can prepare several entity manager factories to access severaldata stores. This interface is similar to the SessionFactory in native Hibernate.

• EntityManager– The EntityManager API is used to access a database in a particular unit of work. It is used to

create and remove persistent entity instances, to find entities by their primary key identity, and to query over all entities. This interface is similar to the Session in Hibernate.

• Persistence context– A persistence context is a set of entity instances in which for any persistent entity identity

there is a unique entity instance. Within the persistence context, the entity instances andtheir lifecycle is managed by a particular entity manager. The scope of this context can eitherbe the transaction, or an extended unit of work.

• Persistence unit– The set of entity types that can be managed by a given entity manager is defined by a

persistence unit. A persistence unit defines the set of all classes that are related or groupedby the application, and which must be collocated in their mapping to a single data store.

Isolation par verrouillage 2 Phases

• verrous• temps• T• • Les verrous en lecture sont partageables; ceux en écriture sont

exclusifs• • Règle 1• – avant d'accèder à un granule x, une transaction doit acquérir un

verrou sur x. Si x• est déjà verrouillé de façon exclusive, la transaction attend• • Règle 2• – dès qu'une transaction relâche un verrou, elle ne peut plus

acquérir de nouveau• verrou

Updating Multiple Databases

in a single transaction.

Isolation - The "I" in ACID

• Problem: Need to share data safely

• Isolation is the tradeoff between concurrency and safety

• Let’s discuss how to properly use isolation

• We begin by investigating the types of transactional problems

The Dirty Read Problem

• TRANSACTION_READ_UNCOMMITTED isolation level allows for this problem to happen

• TRANSACTION_READ_COMMITTED isolation level solves this problem

Bean 2

Database

Bean 1

1: X = 0

4: Write X=10

2: Begin TX

8: Rollback TX6: Read X=10

3: Begin TX

7: Commit TX

9: X = 0

5: X = 10

The Unrepeatable Read Problem

• TRANSACTION_READ_COMMITTED isolation level allows for this problem to happen

• TRANSACTION_REPEATABLE_READ isolation level solves this problem

Bean 2

Database

Bean 1

1: X = 0

4: Read X=0

2: Begin TX

8: Read X=105: Write X=10

3: Begin TX

6: Commit TX

7: X = 109: Commit TX

The Phantom Problem

• TRANSACTION_REPEATABLE_READ isolation level allows for this problem to happen

• TRANSACTION_SERIALIZABLE isolation level solves this problem

Bean 2

Database

Bean 1

1: 1 row

4: SELECT returns 1 row

2: Begin TX

8: SELECT returns 2 rows

5: INSERT row

3: Begin TX

6: Commit TX

7: 2 rows9: Commit TX

Isolation Summary

NoNoNoSERIALIZABLE

YesNoNoREPEATABLE READ

YesYesNoREAD COMMITTED

YesYesYesREAD UNCOMMITTED

Phantom Reads?

Unrepeatable Reads?

Dirty Reads?Isolation Level

Isolation Summary• READ_UNCOMMITTED (fastest)

– You can see other transactions’ uncommitted updates

– No data sharing, non mission-critical apps.

• READ_COMMITTED (fast)– You can’t see other transactions’ uncommitted updates

– Rough Reporting tools. Data should be committed. Only need a snapshot.

• REPEATABLE_READ (medium)– When you read a row, nobody can touch that row until you’re done

– Mission-critical, high data sharing. You have not performed a query, sophantoms are OK, so long as the data you're working with isn't modified.

• SERIALIZABLE (slow)– After you do a query, nobody can insert new rows that satisfies your

query until you’re done

– Mission-critical, high data sharing. You have performed a query, and you'd like to know about any new phantom rows.

Synchronizing a

Session Bean’s Instance

Variables• The SessionSynchronization interface, which is optional, allows

stateful session bean instances to receive transaction synchronizationnotifications. For example, you could synchronize the instance variables of an enterprise bean with their corresponding values in the database. The container invokes the SessionSynchronization methods (afterBegin, beforeCompletion, and afterCompletion) at each of the main stages of a transaction.

• The afterBegin method informs the instance that a new transaction hasbegun. The container invokes afterBegin immediately before it invokesthe business method.

• The container invokes the beforeCompletion method after the business method has finished, but just before the transaction commits. ThebeforeCompletion method is the last opportunity for the session bean to roll back the transaction (by calling setRollbackOnly).

• The afterCompletion method indicates that the transaction hascompleted. It has a single boolean parameter whose value is true if thetransaction was committed and false if it was rolled back.

Documents

Transactions GLG 204java.cnam.fr/iagl/glg204_2010/cours/Transaction.pdf · Flat transactions • Modèle le plus simple. • Après qu'une transaction ait démarré, on effectue des