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