Propriétés BASE : Accès concurrent: les problèmes (1)

un compromis entre disponibilité et cohérence

Remarque : les transactions concurrentes s’exécutent
Basically Available dans des threads/processus différents
Le système est toujours disponible (i.e., toutes les operations de
lecture/écriture aboutissent) Perte d'opération
Soft state T1 T2
L’état du système peut changer au cours du temps (i.e., même en
l’absence de mises à jour de l’observateur) LIRE (X, A1)
Eventual consistency LIRE (X, A2)
A2 <- A2 + 1
En l’absence de nouvelles mises à jour, les copies d’un même objet sur ECRIRE (X, A2)
l’ensemble des sites finissent par converger vers une même valeur
A1 <- A1 + 1
ECRIRE (X, A1)
Se substituent aux propriétés ACID dans les systèmes
NoSQL
Nous y reviendrons ultérieurement
P. Pucheral Modèles de transactions avancés - 5
Gestion de transactions Page 6
Accès concurrent: les problèmes (2) Accès concurrent: les problèmes (3)
Introduction d'incohérences
Observation d'incohérences
Contrainte d'Intégrité : X = Y
Contrainte d'Intégrité : X = Y
T1 T2
T1 T2 LIRE (X, A1)
A1 <- A1 + 1
ECRIRE (X, A1)
LIRE (X, A1)
LIRE (X, A2)
A1 <- A1 - 500
A2 <- A2 * 2
ECRIRE (X, A1)
ECRIRE (X, A2)
LIRE (X, A)
LIRE (Y, B2)
EDITER (A)
B2 <- B2 * 2
LIRE (Y, B)
ECRIRE (Y,B2)
EDITER (B)
LIRE (Y, B1)
LIRE (Y, A1)
B1 <- B1 + 1
A1 <- A1 - 500
ECRIRE (Y, B1)
ECRIRE (Y, A1)
Gestion de transactions Page 7 Gestion de transactions Page 8
Cohérence et tolérance aux pannes Architecture en couches d’un SGBD
• Principes transactionnels de base Interface
– Propriétés ACID vs. BASE d'une transaction
Analyseur sémantique
– Protocoles de contrôle de concurrence
– Protocoles de tolérance aux pannes Optimiseur
– Protocoles répartis
Evaluateur de plan d’exécution
• Implémentation dans les SGBDR (Oracle) Opérateurs relationnels
• Implémentation dans les systèmes NoSQL (Cassandra) Méthodes d’accès aux données
Gestion de Gestion de Gestion des
Mémoire la synchronisation Journaux
Système d’exploitation
Gestion de transactions Page 1 Gestion de transactions Page 2
Propriétés ACID d'une transaction
(Rappel)
Atomicité
Une transaction doit s’exécuter en tout ou rien
Cohérence
Une transaction doit respecter l’ensemble des contraintes d’intégrité
Isolation
Une transaction ne ‘voit’ pas les effets des transactions concurrentes
Durabilité
Les effets d’une transaction validée ne sont jamais perdus, quel que
soit le type de panne
On parle de contrat transactionnel
entre l’utilisateur/programme et le SGBD
Gestion de transactions Page 3 Gestion de transactions Page 4
 Ordonnancement par estampillage Ordonnancement par certification
• Estampille (TimeStamp) associée à chaque transaction • Approche optimiste
– date de lancement ou compteur
– Introduit une relation d'ordre total entre les transactions – Basée sur l’hypothèse que les conflits sont peu fréquents
• Conservation des estampilles dans les granules • Une transaction est décomposée en trois phases:
– Granule = objet de la BD considéré comme unité de contrôle
– Writer = dernier écrivain
– Reader = plus jeune lecteur
- 1 phase de calcul pendant laquelle la transaction effectue
• Contrôle d'ordonnancement ses mises à jour dans une mémoire privée et maintient :
– en écriture: estampille écrivain >= Writer et >= Reader - Read-set = ensemble des objets lus par la transaction
– en lecture: estampille lecteur >= Writer
– Toute transaction arrivant ‘en retard’ est abandonnée - Write-set = ensemble des objets modifiés par la transaction
– Les arcs du graphe de précédence sont donc dans l’ordre des estampilles
 pas de circuit possible
- 1 phase de certification afin de détecter les conflits
• Ordonnancement multi-versions (optimisation) - 1 phase de validation pendant laquelle les données
– Toute lecture est servie avec une version
– Seules les écriture dans le passé sont refusées
modifiées sont reportées de la mémoire privée dans la base
de données
• Pros et Cons
– Maximum de parallélisme (sérialisabilité plus faible qu’isolation)
– Risque d'effet domino (abandon en cascade)
Gestion de transactions Page 13 Gestion de transactions Page 14
Ordonnancement par certification VERROUILLAGE 2 PHASES
deb(Ti) et fin(Ti) = date de début et fin de phase de calcul  APPROCHE PESSIMISTE
 OBJECTIF : LAISSER S'EXECUTER SIMULTANEMENT SEULEMENT LES
date_valid(Tj) = date de validation de Tj OPERATIONS COMMUTABLES
Lecture Ecriture
Certifier(Ti)
Tj / deb(Ti) < date_valid(Tj) < fin(Ti)
si Write-set(Tj)  Read-set(Ti) = Ø Lecture 1 0
alors /* Ti peut être validée */
date_valid(Ti) = date; Ecriture 0 0
sinon abort(Ti)
 MOYEN
— LES TRANSACTIONS VERROUILLENT LES OBJETS AUXQUELLES ELLES
Que se passe-t-il si l’hypothèse de départ n’est pas satisfaite ACCEDENT
(i.e., conflits nombreux) ? — LES TRANSACTIONS CONFLICTUELLES SONT MISES EN ATTENTE (PLUTOT
QUE D’ETRE ABANDONNEES)
Gestion de transactions Page 15 Gestion de transactions Page 16
Accès concurrent: les problèmes (4) Exécution sérialisable
• Exécution sérialisable : une exécution en parallèle des transactions T1, ..., Tn
est dite sérialisable si son résultat est équivalent à une exécution en série
Lectures non reproductibles quelconque de ces mêmes transactions.
• Les actions A et B sont commutables/permutables si toute exécution de A
suivie par B donne le même résultat que l'exécution de B suivie par A.
T1 T2 • Si une exécution de transactions est transformable par commutations
successives en une exécution en série, alors elle est sérialisable.
LIRE (X, A2)
EDITER (A2)
LIRE (X, A1)
A1 <- A1 + 1
ECRIRE (X, A1) T1 LECT(O1) T3 ECR(02)
LIRE (X, A2)
EDITER (A2) T2 LECT(O1) LECT(O1)
Exemple T1
T3 ECR(O2) LECT(O2)
d'exécution sérialisable T1 LECT(O2)
T2 T2 LECT(O1)
ECR(O1)
ECR(O1)
TEMPS
Gestion de transactions Page 9 Gestion de transactions Page 10
Exemple d'exécution non sérialisable Relation de précédence
• Ti précède Tj dans l’ordre de sérialisation s' il existe
deux actions non permutables ai et aj tel que ai
soit exécutée par Ti avant que aj soit exécutée par Tj
T3
T1 LECT(O1) T1 T1
T2 LECT(O2) T2
T3 ECR(O2) ETC ...
T2 T3 T1 LECT(O1)
T1 LECT(O2) T1 Exemple :
T2 ECR(O1) T3 T2 T2 LECT(O2) T2
T3 ECR(O2) T1
T3
T1 LECT(O2)
TEMPS T2 ECR(O1)
• Si le graphe de précédence d'une exécution est
sans circuit, l'exécution est sérialisable.
Gestion de transactions Page 11 Gestion de transactions Page 12
 Exercice Degrés d'isolation SQL
 Une table T contenant 100.000 tuples répartis dans 1000 pages
• Objectif: accroître le parallélisme en autorisant certaines
 3 transactions transactions à violer la règle d'isolation
 T1: Select * From T Where [Link] > 100
• Degrés standardisés SQL2 (Set Transaction Isolation Level)
 T2: Update T Set a1 = 1000 Where att_key = 2048
– Degré 0 (Read Uncommitted)
 T3: Update T Set a1 = 1000 Where att_key = 2050 » Lecture de données sales – Interdiction d’écrire.
 Les tuples de clé 2048 et 2050 sont dans la même page disque » Ex. lecture sans verrouillage
 Combien de verrous S, X, IS, IX, SIX sont posés par T1, T2 et T3 – Degré 1 (Read Committed)
» Lecture de données propres – Ecritures autorisées
 Avec un verrouillage tuple classique ?
» Ex. Verrous court en lecture, long en écriture
 Avec un verrouillage par intention ?
– Degré 2 (Repeatable Read)
» Pas de lecture non reproductible
» Ex. Verrous longs en lecture et en écriture
– Degré 3 (Serializable)
» Pas de requête non reproductible (fantôme)
Gestion de transactions Page 21 Gestion de transactions Page 22
Degrés d'isolation SQL : exemples Concurrence dans Oracle (1)
T1(°0, Read uncommitted) T2(°3,serializable) T1(°1, Read committed) T2(°3,serializable) • Exercice : 2 fenêtres, 1 attribut solde de valeur initiale 1000
Begin Begin Begin Begin Transaction 1 Réponse attendue Transaction 2
Lit CC ( 100) Lit CC ( 100) ???
Lit CC ( 100) Lit CC ( 100)
Ecrire CC, CC+10 Ecrire CC, CC+10 Select solde
Lit CC ( 110) Lit CC ( bloque) from compte
Ecrire CC, CC+20 Ecrire CC, CC+20 where N_compte = Update compte set
Lit CC ( 130) Commit 232123 solde=2000 where
Commit ( 130) N_compte = 232123
Select solde
from compte
T1(°2, Repeatable read) T2(°3,serializable) T1(°2, Repeatable read) T2(°3,serializable) where N_compte =
Begin 232123
Begin Begin Select count(*) from Voit
Lit CC ( 100) where couleur="rouge" Commit
Lit CC ( 100) Begin
Ecrire CC, CC+10 Insert into Voit
Lit CC ( 100) values (R4, "rouge")
 bloque
Commit Select solde
Lit CC ( 100) Select count(*) from Voit from compte
Commit where couleur="rouge" where N_compte =
Ecrire CC, CC+20 Commit 232123
Gestion de transactions Page 23 24
Condition de Bon Fonctionnement Problème du verrou mortel
n TOUTE TRANSACTION DOIT ETRE COMPOSEE DE DEUX PHASES :
==> 2PL (Two Phase Locking)
T1 T2
Nombre Phase de Phase de
d'objets verrouillage libération
T3 T4
Temps
• Détection …
 LE DEVERROUILLAGE S'EFFECTUE EN FIN DE TRANSACTION AFIN On construit le graphe des attentes au fur à mesure des conflits. Si un
D'EVITER QU'UNE TRANSACTION PUISSE VOIR DES MISES A JOUR NON cycle est détecté, on abandonne une des transactions du cycle
VALIDEES (DIRTY READS)
Gestion de transactions Page 17 Gestion de transactions Page 18
Equation du Verrouillage Verrouillage par intention (ou hiérarchique)
• Objectif: faire varier le granule de verrouillage afin d'éviter un trop grand nombre de
 LE COUT DEPEND DE LA TAILLE DES GRANULES :
verrous lorsque beaucoup d'objets sont accédés
• Exemple:
— DES PETITS GRANULES (Tuple) CONDUISENT A UN COUT IMPORTANT Parcours séquentiel d'une relation verrouille des granules page ==> lock pages en S
MAIS MAXIMISENT LE PARALLELISME Modification de tuples verrouille des granules objet ==> lock pages accédées en IX et
les tuples modifiés en X
— DE LARGES GRANULES (Page, Table) CONDUISENT A UN TEMPS
D'ATTENTE IMPORTANT MAIS MINIMISENT LE PARALLELISME
 UNE TAILLE VARIABLE EST SOUHAITABLE
• S'applique à tout verrouillage hiérarchique
BD – Tables – Pages –Tuples
SOLUTIONS : Document – Chapitres – Sections - Paragraphes
VERROUILLAGE PAR INTENTION noeuds non feuilles verrouillés en intention (IS, IX ou SIX) et noeuds feuilles
verrouillés en S ou X
• Intégré dans des commandes SQL ad-hoc (e.g., Lock Table) ou dans les fichiers de
config du SGBD (e.g., lock escalation threshold)
Gestion de transactions Page 19 Gestion de transactions Page 20
 Tolérance aux pannes Atomicité
• Objectif: Garantir les propriétés d'Atomicité et de Durabilité quel que soit le type • Toutes les mises à jour d'une transaction doivent être prises en compte
de pannes. ou bien aucune ne doit l'être
• Types de pannes:
• Règle du Write Ahead Logging (WAL)
- Toute mise à jour est précédée d'une écriture dans un journal
d'images avant permettant d'invalider cette mise à jour
– Transaction failure (ex: deadlock, violation de CI)
• Journal d’images avant
– System failure (ex: panne mémoire) – Journalisation physique
{ <Trid, n° page, image avant de la page, action > }
– Journalisation physique différentielle
– Media failure (panne disque) { <Trid, n° page, offset1, offset2, image avant offset1-offset2, action
– Journalisation logique (compensation)
– Communication failure (panne réseau) { <Trid, opération inverse avec paramètres d'appels> }
ex: insert_tuple(t) ------> delete_tuple(t)
Gestion de transactions Page 29 Gestion de transactions Page 30
Durabilité Principe du checkpoint
• Objectif : réduire le temps de latence pendant les validations et abandon de
• Objectif: ne jamais perdre de mises à jour validées quel que soit le transactions afin de supporter un grand nombre de transactions par seconde (Tps)
type de pannes • Moyen :
- mises à jour du disque par une tâche asynchrone (STEAL/NO-FORCE)
- seul le journal d'images après est écrit sur disque à la validation d'une transaction
• Journal d’images après : mémoriser toutes les mises à jour validées - complique toutefois les procédures de reprise
pour pouvoir les rejouer en cas de perte. Ce journal a un format
similaire au journal d'images avant
T1 Abort
• Règle du Force Log at Commit: T2 Abort
Le journal d'images après d'une transaction doit être écrit sur disque T3 Commit
lors de la validation
T4 Commit
Abort PANNE
T5
• Règle du bon sens:
Le journal d'images après doit être stocké sur un disque différent de la
base de données
Checkpoint Checkpoint
Gestion de transactions Page 31 Gestion de transactions Page 32
Concurrence dans Oracle (2) Concurrence dans Oracle (3)
• Exercice : 2 fenêtres, 1 attribut solde de valeur initiale 1000 • Exercice : 2 fenêtres, 1 attribut solde de valeur initiale 1000
Transaction 1 Réponse attendue Transaction 2 Transaction 1 Réponse Réelle… Transaction 2
???
Select solde Select solde
from compte from compte 1000 euros
where N_compte = 1000 euros where N_compte = 2000 euros
Update compte set Update compte set
232123 En attente… solde=2000 where 232123 solde=2000 where
N_compte = 232123 N_compte = 232123
Select solde Select solde 1000 euros
from compte 1000 euros from compte
where N_compte = where N_compte =
232123 232123
Ok
Commit Commit
Select solde Select solde 2000 euros
from compte 1000 euros from compte
where N_compte = where N_compte =
232123 232123 Conclusion ???
25 26
Concurrence dans Oracle (5) Concurrence dans Oracle (6)
• Niveau Read Committed • Niveau Serialisable
– Offre un ‘cliché’ stable des données pendant la requête – Offre ‘cliché’ stable des données pendant la transaction
• Mécanisme de version par utilisation des Rollback Segments (images avant) • Mécanisme de version par utilisation du journal d’images avant
• Verrous en écriture, bloquant seulement d’autres écritures • Verrous seulement en écriture, bloquant d’autres écritures
– Problème de restitution des images avant pour les ‘vieilles’ requêtes – Problème de restitution des images avant pour les ‘vieilles’
A = 10 SCN=5
transactions
SCN = 6
Transaction B = 13 SCN=7 Transaction A = 10 SCN=5
C = 11 SCN=3
B = 13 SCN=7

Requête Requête
SCN = 6
D = 15 SCN=1

Requête
SCN = 7
Données SCN = 7 C = 11 SCN=3
D = 15 SCN=1
SCN = 8 Transaction
SCN = 9 Données
SCN = 8 Transaction

SCN = 8
Ecriture A=20

Requête
SCN = 9 Écriture A=20
SCN = 9
Lecture A=10 Commit Lecture A=10

Requête
Commit
SCN = 9
A = 20 SCN=10

Requête
SCN = 10
A = 10 SCN=5 A = 20 SCN=10 A = 10 SCN=5
SCN = 10
B = 13 SCN=7 B = 13 SCN=7
Lecture A=10
SCN = 11
C = 11 SCN=3 Lecture A=10
C = 11 SCN=3
SCN = 11
D = 15 SCN=1 D = 15 SCN=1
Lecture A=20

Requête
SCN = 11

Requête
Lecture A=10

Chronologie

Chronologie
Écriture A=30 Données Images avant la transaction ne peut
Écriture A=30 Données Images avant
pas être sérialisée…
Commit
27 28
 Cas Défavorable (1) Cas Défavorable (2)
COORDINATEUR
COORDINATEUR PARTICIPANT
PARTICIPANT
PARTICIPANT
PARTICIPANT
PREPARE PREPARE
PREPARE PREPARE READY READY
COMMIT COMMIT
ACK
READY KO
ABORT ABORT KO ou absence de ??
réponse après timeout COMMIT
ACK
sont traités uniformément ACK
ACK
P. Pucheral Modèles de transactions avancés - 37 P. Pucheral Modèles de transactions avancés - 38
Cas très défavorable (3)
COORDINATEUR
PARTICIPANT PARTICIPANT
Transactions dans les systèmes
PREPARE PREPARE
READY READY
NoSQL
?? ??
scalabilité au
détriment de la cohérence
En cas de panne du coordinateur pendant la phase d'incertitude
des participants (entre l'envoi du Ready et l'attente de la réponse),
les participants sont bloqués => protocole BLOQUANT
Standard OSI-TP : décision heuristique !
P. Pucheral Modèles de transactions avancés - 39 P. Pucheral Modèles de transactions avancés - 40
Atomicité globale
• Garantir qu'un ensemble de mises à jour sur plusieurs sites est
totalement exécuté ou pas du tout
• Nécessite un protocole de validation atomique (ACP)
• Exemple: transfert d'argent entre deux comptes gérés par
deux agences bancaires distinctes
Protocoles
Commit (Ti) site A
transactionnels distribués Serveur
DB
débit(C1,M) site B
Application crédit(C2,M)
DB
Serveur
Commit (Ti)
P. Pucheral Modèles de transactions avancés - 34
33
Validation à 2 Phases (2PC) Cas Favorable
Coordinateur :
COORDINATEUR
Le composant système du site qui centralise et pilote le protocole
PARTICIPANT PARTICIPANT
Participant :
Le composant système d'un site qui participe à l'exécution de la
transaction PREPARE PREPARE
... READY Sauvegarde des MAJ
READY de la transaction
Phase de vote : Le coordinateur demande à tous les participants s'ils dans un journal
COMMIT COMMIT
sont capables de valider la transaction
Phase de décision : Le coordinateur décide la validation si TOUS les ... ACK ACK
Validation des MAJ
participants votent OK. Il décide l'abandon sinon. de la transaction
dans la base de
données
Ce protocole doit être tolérant aux pannes
P. Pucheral Modèles de transactions avancés - 35 P. Pucheral Modèles de transactions avancés - 36
 Propriétés BASE :
un compromis entre disponibilité et cohérence
Basically Available
Le système est toujours disponible (i.e., toutes les operations de
lecture/écriture aboutissent)
Soft state
L’état du système peut changer au cours du temps (i.e., même en
l’absence de mises à jour de l’observateur)
Eventual consistency
En l’absence de nouvelles mises à jour, les copies d’un même objet sur
l’ensemble des sites finissent par converger vers une même valeur
Se substituent aux propriétés ACID classiques
PS : 1 transaction = 1 lecture/écriture ‘unique’ sur
un ‘document’ unique
P. Pucheral Modèles de transactions avancés - 45 P. Pucheral Modèles de transactions avancés - 46
Sérialisabilité et convergence Propagation synchrone (Eager)
dépendent du modèle de réplication
• Les mises à jour sur un objet sont reportées dans la même
transaction, sur l'ensemble de ses réplicas
• 2 modes de propagation des mises à jour
– Synchrone (Eager) Transaction T
– Asynchrone (Lazy) site S1 site S2 site S3
• 2 modes de contrôle des copies write A1
write A2
– Symétrique (Update Everywhere) write A3
write B1
– Asymétrique (maître-esclave) write B2
write B3
• Donc, 4 modèles de réplication commit
commit
– synchrone/symétrique (SS) commit
– synchrone/asymétrique (SA)
– asynchrone/symétrique (AS) • Garantit la sérialisabilité à une copie (cohérence parfaite) mais
– asynchrone/asymétrique (AA)
• coût d’une validation atomique
• impose une connexion permanente à tous les sites
P. Pucheral Modèles de transactions avancés - 47 P. Pucheral Modèles de transactions avancés - 48
Théorème CAP [Brewer’00,Lynch&Gilbert’02] Démonstration
• Scalabilité des systèmes NoSQL  nombre de sites
dynamique et grand, replication systématique
• Or un système distribué ne peut pas garantir en
même temps : 1
– Consistency
» Tous les sites voient le même état des données en même
temps
– Availability
» Toutes les requêtes de lecture et écriture aboutissent (avec
succès ou échec)
– Partition Tolerance
» Le système continue à fonctionner malgré des pertes de
message
P. Pucheral Modèles de transactions avancés - 41 P. Pucheral Modèles de transactions avancés - 42
Solutions possibles Réplication : no Single Point of Failure
(cf cours sur la cohérence)
Relational DBMSs
Dynamo
CouchDB
C: Consistency
A: Availability
P: Partition tolerance
P. Pucheral Modèles de transactions avancés - 43 P. Pucheral
BigTable HBASE Modèles de transactions avancés - 44
 Réplication dans Cassandra Réplication dans Cassandra
• Modèle Symétrique / (A)synchrone
– Fonctionnement Pair-à-Pair  pas de maître/esclave • Paramètres
– Mais on peut imposer un certain synchronisme entre replicas – RF: facteur de replication (du keyspace)
(i.e., plusieurs replicas doivent valider une /lecture/écriture
avant acquittement au client) – R: nb de replicas lus
– W: nb de replicas écrits
– Quorum Q = RF/2 + 1
• Différents choix possibles
– Exemple pour R (resp. W) = 1, on renvoit au client la 1ère
réponse reçue d’un replica
• W + R > RF garantit la cohérence
– R=1, W=RF (ROWA: Read Once Write All)
– R=RF, W=1
– R=Q, W=Q
P. Pucheral Modèles de transactions avancés - 53 P. Pucheral Modèles de transactions avancés - 54
Réplication dans Cassandra Réplication dans Cassandra
• Le niveau de cohérence souhaité peut être un
paramètre du keyspace ou de la requête de
mise à jour
Source : [Link]
P. Pucheral Modèles de transactions avancés - 55 P. Pucheral Modèles de transactions avancés - 56
Propagation asynchrone (Lazy) Contrôle symétrique vs. asymétrique
• Les mises à jour sur un objet sont reportées sur • Symétrique (update everywhere): tout site est
ses réplicas en mode différé, par le biais de autorisé à mettre à jour sa copie locale d'un objet
transactions indépendantes Update A Update A
T1 sur S1
write A1 A1 A2
write B1
commit T2 sur S2
Update A A3
write A2
write B2
commit • Asymétrique (primary copy): seule la copie maître peut
T3 sur S3
write A3
être mise à jour, les autres copies sont en lecture seule
write B3
Update A
commit Update A
Update A A1 A2
• La cohérence des copies dépend du mode de contrôle choisi
(symétrique ou asymétrique)
A3
P. Pucheral Modèles de transactions avancés - 49 P. Pucheral Modèles de transactions avancés - 50
Bilan (suite) Réplication dans MongoDB
• Modèle Asymétrique (maître-esclave) / Asynchrone
– S’applique à des Replica-Sets (ensembles de documents)
• 2 niveaux de cohérence possibles
– Cohérence forte : toutes les lectures sont dirigées vers le maître
– Cohérence à terme : lectures possibles sur les esclaves
• Envois de messages ‘heartbeat’ entre nœuds pour détecter les
pannes
– En cas de panne du maître, élection d’un nouveau maître
– Toute panne de nœud génère la création automatique d’un nouveau replica
Source Philippe Rigaux
P. Pucheral Modèles de transactions avancés - 51 P. Pucheral Modèles de transactions avancés - 52
 Exemple avec RF = 3 et R = 3
Quelle est la valeur de W dans l’exemple ?
Le même résultat serait-il retourné avec :
- R=2?
- R = 2 et W = 2 ?
P. Pucheral Modèles de transactions avancés - 57