Chapitre 1 Systèmes transactionnels SysRép Transactions-A A. Schiper Eté 2007 1
1. Introduction 2. Comment assurer l'isolation 3. Comment assurer l'atomicité et la durabilité 4. Réplication de bases de données (plus tard) SysRép Transactions-A A. Schiper Eté 2007 2
1. Introduction Notion de transaction: assurer l exécution «correcte» d un ensemble d opérations: Transaction T1: begin-transaction read(account1, v1) -- opération 1 read(account2, v2) -- opération 2 v1 v1 1 v2 v2 + 1 write(account1, v1) -- opération 3 write(account2, v2) -- opération 4 end-transaction SysRép Transactions-A A. Schiper Eté 2007 3
Deux résultats sont possibles pour une transaction: Commit (valider), si la transaction s'exécute avec succès Abort (avorter), sinon Une transaction est formellement définie par les propriétés ACID: A = Atomicité C= Cohérence I = Isolation D = Durabilité SysRép Transactions-A A. Schiper Eté 2007 4
Propriétés ACID Atomicité: soit toutes les opérations de la transaction sont exécutées, soit aucune. Cohérence: la transaction transforme un état cohérent de la base de données en un nouvel état cohérent. Propriété du programme qui constitue la transaction, pas du système transactionnel. Pas discuté par la suite. Isolation: assure que si plusieurs transactions s'exécutent simultanément, le résultat est le même que celui obtenu par une exécution séquentielle des transactions. Aussi appelé sérialisabilité. Durabilité: assure qu'après le commit, les modifications de la transaction ne sont pas perdues. Réalisé en stockant les données en mémoire permanente. SysRép Transactions-A A. Schiper Eté 2007 5
Transactions centralisées Transaction centralisée: toutes les données accédées par la transaction se trouvent sur la même machine. On va illustrer la violation des propriétés ACID. SysRép Transactions-A A. Schiper Eté 2007 6
Violation de l'atomicité Transaction T1: 1: begin-transaction 2: read(account1, v1) 3: read(account2, v2) 4: v1 v1 1 5: v2 v2 + 1 6: write(account1, v1) 7: write(account2, v2) 8: end-transaction Exemple: Défaillance après ligne 6 et avant ligne 7. Pour éviter l'incohérence, l'effet de la ligne 6 doit être défait (undo) avant que account1 soit visible à d'autres transactions. SysRép Transactions-A A. Schiper Eté 2007 7
Violation de l'isolation Considérons T1 et T2 identiquent à T1 Initialement: account1= 0 account2= 0 Exécution correcte devrait fournir le résultat account1= -2 account2=2 T1: read(account1, v1) {T1.v1=0} T2: read(account1, v1) {T2.v1=0} T1: read(account2, v2) {T1.v2=0} T2: read(account2, v2) {T2.v2=0} T1: v1 v1 1 {T1.v1= -1} T2: v1 v1 1 {T2.v1= -1} T1: v2 v2 + 1 {T1.v2=1} T2: v2 v2 + 1 {T2.v2=1} T1: write(account1, v1) {account1= -1} T2: write(account1, v1) {account1= -1} T1: write(account2, v2) {account2= 1} T2: write(account2, v2) {account2= 1} SysRép Transactions-A A. Schiper Eté 2007 8
Violation de la durabilité Transaction T1 ci-dessus Initialement: account1 = account2 = 0 Après exécution de T1: account1= -1 et account2=1 Si account1 et account2 sont en mémoire volatile, un crash conduit à perdre le nouvel état de account1 et account2. L'effet de T1 est perdu. SysRép Transactions-A A. Schiper Eté 2007 9
Transactions réparties Si les données account1 et account2 se trouvent sur des machines différentes, la transaction T1 devient une transaction répartie. Les exemples précédents de violation des propriétés AID sont les mêmes. Assurer les propriétés AID pour des transactions distribuées est plus difficile que pour des transactions centralisées. SysRép Transactions-A A. Schiper Eté 2007 10
Architecture d'un système transactionnel disque begin-trans end-trans TM cache BM Site 2 Site 1 cache BM Site 3 SysRép Transactions-A A. Schiper Eté 2007 11
Composants d'un système transactionnel Transaction Manager (TM) : responsable de l'exécution des opérations de la transaction pour le compte de l'application. Le TM se trouve sur un site, le site de l'application. Le TM s'occupe d'accéder aux données distantes (sur d'autres machines). Le TM s'occupe de la terminaison de la transaction (protocole de commit/abort) Buffer manager (BM) ou Data Manager (DM): un BM sur chaque site. Le BM est responsable des lectures/écritures sur disque. Il gère un cache du disque pour rendre les lectures/écritures plus efficaces. SysRép Transactions-A A. Schiper Eté 2007 12
Composants d'un système transactionnel (2) Scheduler: un scheduler sur chaque. Il est reponsable d'assurer l'isolation des transactions (contrôle de concurrence). Le scheduler d un site s interagit avec le TM sur s, et les TM sur les autres sites. Local Recovery Manager (LRM): un LRM sur chaque. Le LRM est responsable d'assurer un état cohérent des données (de la base de données) après une défaillance. Il intervient lors de la fin d'une transaction (commit/abort), et lors d une reprise après défaillance. SysRép Transactions-A A. Schiper Eté 2007 13
Raisons d avorter une transaction Sémantique (semantic abort): avortement généré par la transaction. Exemple: la transaction veut retirer un montant x d'un compte bancaire, et le compte contient un montant inférieur à x. Bug dans l'application: l'exécution de l'application lève une exception (exemple: division par 0). Cela fait avorter la transaction. "Abort" généré par le système transactionnel: Le système peut décider d'avorter une transaction par exemple pour sortir d'un interblocage (contrôle de concurrence pessimiste), ou pour assurer l'isolation (contrôle de concurrence optimiste). Crash d'un site: si une transaction T accède une donnée sur un site s, et que s crashe durant l'exécution de T, la transaction T est avortée. SysRép Transactions-A A. Schiper Eté 2007 14
Types de transactions On distingue deux types de transactions: Les transactions plates (flat transactions): transactions ordinaires, avec un begin-transaction et un end-transaction. Les transactions emboîtées (nested transactions). Modèle permettant d'inclure des transactions dans une transaction. NB Les bases de données commerciales ne fournissent pas le modèle des transactions emboîtées. SysRép Transactions-A A. Schiper Eté 2007 15
Transactions emboîtées Exemple: T1 T1 = réservations pour un voyage T11 = réservation du vol T12 = réservation de l'hôtel T13 = location de voiture T11 T12 T13 op op op op SysRép Transactions-A A. Schiper Eté 2007 16
Deux types de transactions emboîtées: Transactions emboîtées fermées Transactions emboîtées ouvertes SysRép Transactions-A A. Schiper Eté 2007 17
Transactions emboîtées fermées Une sous-transaction (par ex. T11) démarre après la transaction-mère (T1) L'avortement d'une transaction conduit à avorter toutes les soustransactions (mais pas nécessairement les transactions parentes). L'effet du commit d'une transaction (ex. T11) ne prend effet qu'au moment du commit de sa transaction-mère (T1). SysRép Transactions-A A. Schiper Eté 2007 18
Transactions emboîtées fermées Inconvénient: Conduit à garder les verrous longtemps Transactions emboîtées ouvertes permettent d éviter ce problème: une sous-transaction peut committer avant sa transaction parente SysRép Transactions-A A. Schiper Eté 2007 19
Transactions emboîtées ouvertes T11 peut committer avant T1 Que faire si T1 avorte plus tard? Transactions de compensations T1 T11 T12 T13 op op op op SysRép Transactions-A A. Schiper Eté 2007 20
Transactions de compensation Exemple: T11 = réservation d un vol; C11 = annulation du vol T12 = réservation d un hôtel; C12 = annulation de l hôtel T13 = location d une voiture; C13 = annulation de la location Si la transaction racine avorte, alors pour chaque transaction T1i qui a committé, la transaction C1i est exécutée SysRép Transactions-A A. Schiper Eté 2007 21
2 Contrôle de concurrence (isolation) Le contrôle de concurrence assure l'isolation. Solution triviale: exécuter séquentiellement les transactions (T2 ne démarre que lorsque T1 est terminé). Inconvénient: très inefficace (ne permet pas d'exploiter le parallélisme potentiel entre CPU et e/s). Les transactions doivent pouvoir être exécutées de façon concurrente. Définition formelle de la propriété d'isolation: grâce à la notion de sérialisation. SysRép Transactions-A A. Schiper Eté 2007 22
Sérialisation de transactions Informellement: schedule= séquence des lectures et écritures de toutes les transactions schedule sériel = schedule dans lequel les opérations des transactions sont groupées, c-à-d que les transactions sont exécutées séquentiellement. un schedule S est dit sérialisable si les lectures et les écritures des transactions peuvent être ordonnées en un schedule sériel S', de tel manière que le l'effet du schedule sériel S' est le même que l'effet du schedule original S. SysRép Transactions-A A. Schiper Eté 2007 23
Exemple Schedule S Schedule sériel S T1: read(account1, v1) {T1.v1=0} T2: read(account1, v1) {T2.v1=0} T1: read(account2, v2) {T1.v2=0} T2: read(account2, v2) {T2.v2=0} T1: v1 v1 1 {T1.v1= -1} T2: v1 v1 1 {T2.v1= -1} T1: v2 v2 + 1 {T1.v2=1} T2: v2 v2 + 1 {T2.v2=1} T1: write(account1, v1) {account1=-1} T2: write(account1, v1) {account1=-1} T1: write(account2, v2) {account2= 1} T2: write(account2, v2) {account2= 1} T1: read(account1, v1) {T1.v1=0} T1: read(account2, v2) {T1.v2=0} T1: v1 v1 1 {T1.v1= -1} T1: v2 v2 + 1 {T1.v2=1} T1: write(account1, v1) {account1=-1} T1: write(account2, v2) {account2= 1} T2: read(account1, v1) {T2.v1=-1} T2: read(account2, v2) {T2.v2=1} T2: v1 v1 1 {T2.v1= -2} T2: v2 v2 + 1 {T2.v2=2} T2: write(account1, v1) {account1=-2} T2: write(account2, v2) {account2= 2} SysRép Transactions-A A. Schiper Eté 2007 24
Le schedule S ne peut être réordonné en un schedule sériel équivalent qui a le même effet Le schedule S n'est pas sérialisable SysRép Transactions-A A. Schiper Eté 2007 25
Contrôle de concurrence Algorithmes pessimistes: contrôle durant l'exécution de la transaction pour empêcher un schedule non sérialisable. Technique basée sur l'utilisation de verrous. Algorithmes optimistes: aucun contrôle durant l'exécution de la transaction. Le contrôle est effectué à la fin de la transaction: le contrôle est appelé certification. Le contrôle de concurrence est assuré par le scheduler. Si le contrôle de concurrence est basé sur l'utilisation de verrous, le scheduler est aussi appelé lock manager. SysRép Transactions-A A. Schiper Eté 2007 26
Contrôle de concurrence pessimiste Deux modes de verrouillage: verrous de lecture (rl i (x) = read lock sur la donnée x détenu par p i ) verrous d'écriture (wl i (x) = write lock sur la donnée x détenu par p i ) Règles de compatibilité: rl i (x) compatible avec rl k (x) rl i (x) non compatible avec wl k (x) wl i (x) non compatible avec wl k (x) SysRép Transactions-A A. Schiper Eté 2007 27
Contrôle de concurrence pessimiste (2) Détection de l'interblocage: souvent réalisé de manière très simpliste. Si un verrou ne peut être obtenu dans un délai donné, la transaction est avortée (conduit à avorter même si aucun interblocage n'existe) Une transaction T ne peut effectuer une opération (lire/écrire) sur x avant d'avoir obtenu le verrou correspondant. Question: quand le verrou peut-il être relâché? Un verrou est relâché trop tôt peut conduire à une violation de la sérialisation. SysRép Transactions-A A. Schiper Eté 2007 28
T1 et T2 1: begin-transaction 2: request wl(account1) 3: read(account1, v1) 4: v1 v1 1 5: write(account1, v1) 6: release wl(account1) 7: request wl(account2) 8: read(account2, v2) 9: v2 v1 10: write(account2, v2) 11: release wl(account2) 12: end-transaction Exemple L'exécution suivante est possible: La transaction T1 exécute les lignes 1-6 La transaction T2 s'exécute entièrement La transaction T1 exécute les lignes 7-12 Une telle exécution n'est pas sérialisable Cette exécution peut être évitée: Par l'algorithme de verrouillage 2PL (Two-Phase Locking) par l'algorithme 2PL strict SysRép Transactions-A A. Schiper Eté 2007 29
Algorithme 2PL Les deux phases de l'algorithm 2PL sont: Phase I: phase de demande de verrous (aucun verrou ne peut être relâché) Phase II: phase de libération des verrous (aucun verrou ne peut être demandé) Dans l'exemple ci-dessus, wl(account1) est relâché, puis wl(account2) est demandé. Les règles de l'algorithme 2PL ne sont pas satisfaites. L'algorithme 2PL assure une exécution sérialisable. SysRép Transactions-A A. Schiper Eté 2007 30
Avortement en cascade L'algorithme de verrouillage 2PL assure une exécution sérialisable, mais ne prévient pas le problème suivant: Une transaction T demande tous les verrous nécessaires, puis les relâche au fur et à mesure que les données ne sont plus accédées Après que T ait relâché un verrou, par ex. wl(x), une autre transaction T' peut obtenir par ex. le verrou rl(x) et lire x (T' lit la valeur écrite par T) Si T avorte, l'écriture de x est défaite (undo), et donc T' a lu une valeur incorrecte. Cela oblige a avorter T'. On appelle ce phénomène avortement en cascade. SysRép Transactions-A A. Schiper Eté 2007 31
Algorithme 2PL strict L'algorithme 2PL strict évite l'avortement en cascade. Règle supplémentaire par rapport à l'algorithme 2PL Les verrous ne sont relâchés que lorsque la transaction se termine, c-à-d dans le contexte du protocole qui décide commit/abort. SysRép Transactions-A A. Schiper Eté 2007 32
Transactions réparties Les algorithmes «2PL» et «2PL strict» ont été proposés initialement dans le contexte des transactions centralisées. Ils peuvent être facilement être adaptés au contexte des transactions réparties. Une solution consiste à déléguer le verrouillage de toutes les données à un seul gestionnaire de verrou (lock manager). Cette solution est appelée 2PL centralisé. Inconvénient: goulot d'étranglement, vulnérabilité à une seule défaillance. Dans l'algorithme 2PL réparti, chaque site gère les verrous sur ses propres données. SysRép Transactions-A A. Schiper Eté 2007 33
Degrés d'isolation La sérialisation (isolation) est parfois considérée comme trop coûteuse. Cela à conduit à relâcher certaines contraintes: Read uncommitted: Les verrous de lecture ne sont pas demandés Read committed: Les verrous de lecture sont demandés, mais sont relâchés immédiatement après la lecture Repeatable read: Les verrous de lecture sont demandés et gardés jusqu à la fin de la transaction. Toutefois les verrous sur les index sont relâchés immédiatement après la lecture de l index. SysRép Transactions-A A. Schiper Eté 2007 34
Degrés d'isolation (2) Les degrés d isolation plus faibles peuvent conduire aux phénomènes suivants: Read uncommitted dirty read: Une donnée sale (dirty) est une donnée modifiée par une transaction qui n'a pas encore terminée (commit). Une lecture sale (dirty read) est la lecture d'une donnée sale. Read committed non-repeatable read: Une lecture est non reproductible si deux lectures (non sales) de la même donnée par une transaction T, retournent deux valeurs différentes. Exemple: T lit x, puis T' écrit x et fait un commit, puis T relit x Repeatable read phantom: Les phantômes sont de nouveaux tuples dans une table. Exemple: Une transaction T1 recherche dans une table les tuples qui satisfont une certaine condition. Soit une transaction T2 qui insère un tuple dans la table durant l'exécution de T1. Deux exécutions par T1 de la même recherche peuvent retourner deux résultats différents. SysRép Transactions-A A. Schiper Eté 2007 35
Degrés d'isolation (3) Technique utilisée par Oracle: snapshot isolation Tout se passe comme si la transaction faisait une copie de la base de donnée au début, et Les données sont lues depuis la copie Les écritures sont répercutées sur la copie et sur la base de données Les verrous d écriture sont demandés. Toutefois, si un verrou ne peut être obtenu, la transaction est avortée. Implémentation d un read: Grâce au log utilisé pour le recovery (qu on verra plus tard): le log est parcouru jusqu à trouver le «write» le plus récent validé avant le début de la transaction SysRép Transactions-A A. Schiper Eté 2007 36
Degrés d'isolation (4) Intérêt de la technique snapshot isolation: Une lecture n est jamais bloquée Pas de «dirty read» Pas de «lectures non reproductibles» Mais la sérialisation n est pas assurée (même si Oracle l utilise pour le degré d isolation «sérialisable»!). Exemple: T1 lit a; T1 écrit a+1 dans b T2 lit b; T2 écrit b+1 dans a NB Scénario prétendu rare en pratique SysRép Transactions-A A. Schiper Eté 2007 37