Académique Documents
Professionnel Documents
Culture Documents
19/10/2004
Gestion de transactions
n n
Service cl pour le dveloppement ct serveur, Permet des applications de fonctionner de manire robuste, Les transactions sont trs utiles lorsqu'on effectue des oprations de persistance, comme des mises--jours dans une base de donnes Dans ce chapitre nous prsentons le concept de transaction et sa mise en application au sein des EJB.
19/10/2004
Ex : transfert de compte compte bancaire : on enlve sur un compte, on dpose sur l'autre n Si une des deux oprations choue, perte de cohrence ! n On veut que soit les deux oprations russissent, mais si une d'elles choue, on annule le tout et on remet les comptes dans l'tat initial ! n On dit que les deux oprations forment une seule et mme transaction !
try {
} catch (Exception e){ // Si une erreur est apparue, on arrte. return; } try { // Sinon, on dpose l'argent sur le compte 2 } catch (Exception e){ // Si une erreur est apparue, o s'arrte, mais avant, on red pose //l'argent sur le compte 1 return; }
Qu'en pensez-vous ?
19/10/2004
Et si on choue la dernire opration et qu'on arrive pas remettre l'argent sur le compte 1 ? Et si au lieu d'un traitement simple on a un gros traitement faire qui se compose de 20 oprations diffrentes ? Comment on teste tous les cas d'erreur ?
19/10/2004
Le rseau plante, le client reoit une RMI Remote Exception L'erreur est intervenue avant qu'on enlve l'argent, ou aprs ?
n
Impossible de savoir
Peut-tre que le SGBD s'est crash ? La machine ? La BD est peut-tre devenue inconsistante ? Le traitement par Exception est vraiment inacceptable ici, il n'est pas suffisant !
19/10/2004
Plusieurs clients consultent et modifient les mmes donnes On ne peut tolrer de perte d'intgrit des donnes !
Un transaction est une srie d'oprations qui apparaissent sous la forme d'une large opration atomique. Soit la transaction russit, soit elle choue.
n
n n
Les transactions s'accordent avec les pannes machines ou rseau, Rpondent au problmes du partage de donnes.
19/10/2004
Un peu de vocabulaire
n
Gestionnaire de transaction
n Celui qui en coulisse gre l'tat de la transaction
Ressource
n L'endroit o on lit et crit les donnes : un DB, une queue de
messages, autre n
Gestionnaire de ressource
n Driver d'accs une BD, une queue de message
Atomicit
n Nombreux acteurs : servlet, corba, rmi-iiop, ejbs, DB Tous
Consistance
n Le systme demeure consistent aprs l'excution d'une
Isolation
n Empche les transactions concurrentes de voir des rsultats
partiels. Chaque transaction est isole des autres. n Implment par des protocoles de synchronisation bas-niveau sur les BDs n
Durabilit
n Garantit que les mises jour sur une BD peuvent survivre un
19/10/2004
Modles de transactions
n 1.
2.
Flat transactions
n n
Modle le plus simple. Aprs qu'une transaction ait dmarr, on effectue des oprations Si toutes les oprations sont ok, la transaction est commite (commited), sinon elle choue (aborted) En cas de commit, les oprations sont valides (permanent changes) En cas d'abort, les oprations sont annules (rolled back). L'application est galement prvenue
19/10/2004
Flat transactions
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 proccuper de l'tat de votre bean Il sera restaur en cas de rollback.
19/10/2004
Transactions imbriques
n
Transactions imbriques
n
Avec un modle de transactions imbrique, une transaction peut inclure une autre transaction, Si on ne trouve pas de vol pour New-York, on essaiera peut-tre de prendre une correspondance par Philadelphie
19/10/2004
Transactions imbriques
Seul le modle flat est support. Le code que le d veloppeur crit, s'il dcide de grer les transactions par programmation, demeurera d'un trs haut niveau,
n
Simple vote pour un commit ou un abort, n Le container fait tout le travail en coulisse
n
10
19/10/2004
Responsable : le dveloppeur de bean Il dcide dans son code du begin, du commit et du abort Ex: le banquier
Le bean est automatiquement enrl (enrolled) dans une transaction Le container fait le travail
11
19/10/2004
<!DOCTYPE ejb-jar PUBLIC " -//Sun Microsystems ,Inc.//DTD Enterprise JavaBeans 2.0//EN""http:// java.sun.com /dtd/ejb -jar_2_0.dtd"> <ejb -jar> <enterprise -beans> <session> <ejb-name>Hello</ ejb-name> <home>examples.HelloHome </home> <remote >examples.Hello </remote> <ejb-class >examples.HelloBean </ejb -class> <session-type>Stateless</session-type> <transaction -type>Container</transaction-type> // ou Bean... </session> </enterprise-beans> </ejb-jar >
12
19/10/2004
Que choisir ?
n
Par programmation : contrle trs fin possible Dclaratif : super, mais granularit importante, Contrl par le client
n
n n
N'empche pas de grer les transactions dans le bean (par programmation ou de manire dclarative) n Ajoute une couche de scurisation en plus, qui permet de dtecter les crashes machine, rseau, etc
ejbLoad() est appel : chargement des donnes de la DB dans le bean, n Un verrou (lock) est acquis sur la DB, assurant la consistance, n Juste aprs l'appel du commit de la transaction, ejbStore() est appel, qui met jour la DB et libre le verrou. n On a donc les appels ejbLoad(), aux mthodes mtiers et l'appel ejbStore() qui se trouvent dans la transaction.
13
19/10/2004
dbut de ejbLoad(), n Faire le commit la fin de ejbStore() ou juste aprs l'appel ejbStore(). n
Bean-Managed transactions illgales pour les entity beans. Seules les transactions gres par le container sont autorises !
Consquence : un entity bean n'accde pas la BD chaque appel de mthode, mais chaque transaction. Si un entity s'excute trop lentement, il se peut qu'une transaction intervient pour chaque appel de mthode, impliquant des accs BD. Solution : inclure plusieurs appels de mthodes de l'entity dans une mme transaction. Se fait en prcisant les attributs de transaction du bean.
n n
14
19/10/2004
Bean-Managed Transactions
n La transaction commence et se termine aprs que le message
a t reu par le MDB. n On indique dans le descripteur de dploiement les aknowledgement modes pour indiquer au container comment accuser rception n
Container-Managed Transactions
n La rception du message s'inscrit dans la mme transaction
que les appels de mthodes mtier du MDB. En cas de problme, la transaction fait un rollback. Le container envoi accus de rception (message acknowledgement) n
Pas de transaction
n Le container accusera rception aprs rception. Quand
Que choisir ? Si on dcide de ne pas laisser le container grer les transactions, on a pas de moyen de conserver le message dans la queue de destination si un problme arrive.
n On choisit Container-Managed Transaction
Pige : si un MDB est expditeur et consommateur du message, le tout intervient dans une mme transaction
n Impossible de terminer ! Le message expdi n'est pas mis
dans la queue de destination de manire dfinitive tant que l'envoi n'est pas commit. n Donc le message ne peut tre consomm! Cqfd. n Solution : appeler commit() sur l'objet JMS session juste aprs l'envoi.
15
19/10/2004
Obligatoire pour chaque bean, doit figurer dans le descripteur de dploiement, On peut spcifier des attributs pour le bean entier ou mthode par mthode, On peut prciser les deux Le plus restrictif gagne. Chaque mthode mtier doit tre traite (globalement ou individuellement) Pour les entity beans, il faut en plus couvrir les mthode de l'interface home, car elles impliquent des accs BD.
16
19/10/2004
Required
n
Le bean est toujours dans une transaction. n Si une transaction pour ce bean existe, alors le bean la rejoint (join), sinon, le container cre une nouvelle transaction.
n
La plupart du temps propos comme valeur par dfaut par les IDEs et leurs Wizards/diteurs de descripteurs
17
19/10/2004
crdit et bean commande, Lors d'un passage de commande, on envoie la commande, puis on dbite la carte de crdit, Si le bean session a comme attribut de transaction Required, une transaction est cre ds que le passage de commande dmarre, 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 Crdit, Si un problme se pose, la carte de crdit ne sera pas dbite et la commande ne sera pas passe.
RequiresNew
n
Le bean est toujours dans une nouvelle transaction. n Si une transaction existe, elle est suspendue, n Lorsque la nouvelle transaction se termine (abort ou commit), l'ancienne transaction est rsume.
n
Utile si on veut respecter les proprits ACID dans l'unit du bean, sans qu'une logique externe intervienne.
18
19/10/2004
Supports
n
Semblable Required sauf que si une transaction n'existe pas, elle n'est pas cre. n Si l'excution du bean intervient dans une transaction existante, il la rejoint nanmoins.
n
Mandatory
n
Une transaction doit exister lorsque le bean est excut. n Si ce n'est pas le cas, javax.ejb.TransactionRequiredException est leve et renvoye au client. n Si le client est local, c'est
javax.ejb.TransactionRequiredLocalException qui est leve
Attribut sr, qui oblige le client inscrire sa logique dans une transaction avant d'appeler le bean.
19
19/10/2004
NotSupported
n
Le Bean ne supporte pas les transactions, n Si une transaction existe lors de l'appel du bean, la transaction est suspendue, le bean s'excute, puis la transaction est rsume.
n
Utiliser cet attribut lorsque les proprits ACID ne sont pas importantes
n
Exemple : un bean qui fait des statistiques toutes les dix minutes en parcourant une BD. On tolre que les donnes lues ne sont peut-tre pas jour
Never
n
Le Bean ne supporte pas les transactions, n Une exception javax.rmi.RemoteException ou javax.ejb.EJBException est envoye au client si une transaction existe au moment de l'appel du bean.
n
20
19/10/2004
Soit T1 une transaction initie par le client, T2 la nouvelle transaction initie par le bean appel.
21
19/10/2004
Plus complexes manipuler, mais plus puissantes, Le dveloppeur doit utiliser Java Transaction API (JTA)
22
19/10/2004
Dans une transaction de nombreux partis sont impliqus : le driver de DB, le bean, le container, Premier effort pour assurer les transactions dans un systme distribu : le service CORBA Object Transaction Service (OTS) OTS = ensemble d'interfaces pour le gestionnaire de transactions, le gestionnaire de ressources, etc Mortel utiliser !
JTS s'adresse aux vendeurs d'outils capables d'assurer un service de transaction, elle couvre tous les aspects complexes d'OTS, n JTA s'adresse au dveloppeur d'application (vous) et simplifie grandement la gestion de transactions en contexte distribu.
23
19/10/2004
JTA permet au programmeur de contrler la gestion de transaction dans une logique mtier. 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.
n n
Une pour les gestionnaires de ressources X/Open XA (hors sujet pour nous) Une pour le programmeur dsirant contrler les transactions : javax.transaction.UserTransaction
24
19/10/2004
L'interface javax.transaction.UserTransaction
public interface javax.transaction.UserTransaction { public void begin(); public void commit(); public int getStatus(); public void rollback(); public void setRollbackOnly(); public void setTransactionTimeout(int); }
L'interface javax.transaction.UserTransaction
25
19/10/2004
Constantes de la classe
javax.transaction.Status
n
Constantes de la classe
javax.transaction.Status
26
19/10/2004
Transaction dclarative
/** * Dpose de l'argent sur un compte. */ public void deposit(double amt) throws AccountException { System.out.println("deposit(" + amt + ") called."); balance += amt; }
public void deposit(double amt) throws AccountException { try { System.out.println("deposit(" + amt + ") called."); javax.transaction.UserTransaction userTran = ctx.getUserTransaction(); userTran.begin(); balance += amt; userTran.commit(); } catch (Exception e) { throw new AccountException("Deposit failed because of " + e.toString()); } }
27
19/10/2004
Conseil : dmarrer et terminer la transaction dans le mme mthode, sinon on obtient du code-spaghetti !
C'est la dernire des mthodes prsentes au dbut de ce chapitre Il est ncessaire d'obtenir une rfrence sur un objet UserTransaction, fourni par JTA
n
Via JNDI !
Pige classique !
28
19/10/2004
Provider URL, and any login names or passwords necessary to access JNDI. See your application server product's documentation for d etails on their particular JNDI settings. */ java.util.Properties env = ... /* 2: Get the JNDI initial context */ Context ctx = new InitialContext(env ); /* 3: Look up the JTA UserTransaction interface via JNDI. The container is
required to make the JTA available at the location java:comp/UserTransaction. */ userTran = (javax.transaction.UserTransaction)ctx.lookup("java:comp/UserTransaction"); /* 4: Execute the transaction */ userTran.begin(); // perform business operations userTran.commit(); } catch (Exception e) { // deal with any exceptions, including ones // indicating an abort. }
Isolation de transaction
n n
Le "I" de ACID ! L'isolation cote cher en termes de performances, Ncessit de pouvoir rgler le niveau d'isolation entre transactions concurrentes !
29
19/10/2004
Isolation de transaction
n
Un exemple : deux instances A et B d'un mme composant accdent une mme donne X dans une BD. Chacune
Lit la valeur de X, 2. Ajoute 10 la valeur lue, 3. crit la nouvelle valeur dans la BD
1.
Isolation de transaction
n
Ceci n'est pas garanti selon le niveau d'isolation choisi. Par exemple, si on ne prend pas de prcaution
1. 2. 3. 4. n
A lit X, dans la BD on a X=0, B lit X, dans la BD on a X=0, A ajoute 10 X et crit le rsultat dans la BD. Dans la BD on a X=10, B ajoute 10 sa copie de X et crit le rsultat dans la BD. Dans la BD on a X=10, ce qui est anormal ! On a perdu le traitement effectu par A !
30
19/10/2004
Isolation de transaction
n n
Gestion de file d'attente exclusion mutuelle, etc Tout ceci peut-tre rgl avec les EJBs
Le niveau d'isolation limite la faon dont les transactions multiples et entrelaces interfrent les unes sur les autres dans une BD multi-utilisateur. 3 types de violations possibles
Lecture brouille, 2. Lecture ne pouvant tre rpte, 3. Lecture fantme.
1.
31
19/10/2004
Lecture brouille
n La transaction T1 modifie une ligne, la transaction T2 lit
ensuite cette ligne, n Puis T1 effectue une annulation (rollback), n T2 a donc vu une ligne qui n'a jamais vraiment exist. n
diffrentes.
Lecture fantme
n
T1 lit quelques lignes satisfaisant certaines conditions de recherche, n T2 insre plusieurs lignes satisfaisant ces mmes conditions de recherche, n Si T1 rpte la lecture elle verra des lignes qui n'existaient pas auparavant. Ces lignes sont appeles des lignes fantmes.
32
19/10/2004
Syntaxe
TRANSACTION_READ_UNCOMMITED TRANSACTION_READ_COMMITED
Description
Autorise l'ensemble des trois violations Autorise les lectures ne pouvant tre rptes et les lignes fantmes, n'autorise pas les lectures brouilles Autorise les lignes fantmes mais pas les deux autres violations N'autorise aucune des trois violations
Repeatable
TRANSACTION_REPEATABLE_READ
Serialisable
TRANSACTION_SERIALIZABLE
Uncommited
n Uniquement si on est sr qu'une transaction ne pourra tre
mise en concurrence avec une autre. n Performant mais dangereux ! n A viter pour les applications mission-critical ! n
Commited
n Utile pour les applications qui produisent des rapports sur une
base de donne. On veut lire des donnes consistances, mmes si pendant qu'on les lisait quelqu'un tait en train de les modifier. n Lisent un snapshot des donnes commites n Niveau d'isolation par dfaut de la plupart des BD (Oracle)
33
19/10/2004
Repeatable
n
Lorsqu'on veut pouvoir lire et modifier des lignes, les relire au cours d'une mme transaction, sans perte de consistance.
Serialisable
n
Pour les applications mission-critical qui ncessitent un niveau d'isolation absolu, ACID 100% ! n Attention ,les performances se dgradent vitesse grand V avec ce mode !
Non, on ne peut pas spcifier le niveau d'isolation dans le descripteur ! n On le fera via le driver JDBC, ou via les outils de configuration de la DB ou du container, n Problmes de portabilit !
34
19/10/2004
Deux stratgies
n
Lorsqu'on veut grer les transactions, on doit toujours choisir entre deux stratgies Stratgie pessimiste
n
1.
Tout peut foirer, on prend donc un verrou lors des accs BD, on fait notre travail, puis on libre le verrou.
2.
Stratgie optimiste
n
Peu de chance que a foire, espre que tout va bien se passe. n Nanmoins, si la BD dtecte une collision, on fait un rollback de la transaction.
35
19/10/2004
Ok, nous avons vu comment spcifier le type de gestion de transaction, gre par le bean ou le container, Nous avons vu les niveaux d'isolations, que l'on spcifie la plupart du temps via les pilotes JDBC, Mais que faire en cas de rollback par exemple
n On ne peut pas re-essayer indfiniment d'excuter une
En cas de rollback, si on envoie une Exception au client, que faire de l'tat du bean ?
n
Si le bean est stateful, on risque d'avoir un tat incorrect (celui qui a provoqu l'chec de la transaction), n Lors du design d'un bean, il faut prvoir la possibilit de restaurer un tat correct, n Le container ne peut le faire pour vous car le traitement est en gnral spcifique l'application, n Il peut nanmoins vous aider raliser cette tche.
36
19/10/2004
public interface javax.ejb.SessionSynchronization { public void afterBegin(); public void beforeCompletion(); public void afterCompletion(boolean); }
Le container appelle afterCompletion() que la transaction se soit termine par un commit ou par un abort
n Le paramtre de la mthode 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 public public public public } int count() { return ++val; } void ejbRemove () {} void ejbActivate() {} void ejbPassivate() {} void setSessionContext(SessionContext ctx) {}
37