Définition: Transaction

Transcription

1 Concurrence des accès Atomicité à la concurrence Concurrency atomicity Concepts 2PL Définition: Transaction Une transaction est une unité de travail Un ensemble d actions qui prend la base de données dans un état cohérent et elle la rend dans un autre état cohérent Elle donne l illusion à l utilisateur d être seul à utiliser la base de données Exemple Retrait 50 Fr du compte x; valeur initiale, x= 100Fr; CI: x>=0 Programme: k lire(x) if k >= 50 then k = k-50 écrire(x,k) else print(«pas assez d argent sur le compte») endif Transaction T1:Retrait(x,50) lire(x, 100) écrire(x,50) Transaction est caractérisée par la séquence d actions «lire» et «écrire» qu elle réalise. 1

2 Terminaison d une transaction L exécution d une transaction se termine par commit ou abort (rollback). Commit: la transaction est réussie, ses mises à jour sont incorporées dans la BD. Abort: la transaction a échoué, elle n a aucun effet sur la base de données. Exécution correcte Par définition, une transaction est un programme correct qui préserve * les contraintes d intégrité (la cohérence) de la base de données L exécution isolée d un transaction est correcte. L exécution en série de deux transactions est correcte. * pendant son exécution une transaction peut momentanément violer les CI mais lorsqu elle termine (commit), les CI sont validées. Exécution sérialisable Une exécution concurrente (imbriquée) de deux transactions qui a le même effet (chaque transaction lit les mêmes valeur et les valeurs finales sur la base sont les mêmes) sur la base de données qu une exécution en série de ces deux transactions est dite sérialisable. Une exécution sérialisable est correcte. La sérialisabilité est un critère de correction pour les exécutions concurrentes. 2

3 Exécution non sérialisable CI : balance= c + s = 400 t1:programme user1 Virement(100F, s, c) temp1 lire(s) temp2 lire(c) écrire(s, temp1-100) écrire(c,temp2+100) t2:programme user2 Balance() temp3 lire(s) temp4 lire(c) imprimer(temp3+temp4) Ordonnancement de t1 et t2 lire1(s,200) lire1(c,200) écrire1(s,100) lire2(s,100) lire2(c,200) écrire1(c,300) On imprime une balance incohérente (= 300)!!! Exécution sérialisable t1:programme user1 Virement(100F, s, c) temp1 lire(s) écrire(s, temp1-100) temp2 lire(c) écrire(c,temp2+100) t2:programme user2 Balance() temp3 lire(s) temp4 lire(c) imprimer(temp3+temp4) Ordonnancement de t1 et t2 lire1(s,200) écrire1(s,100) lire2(s,100) lire1(c,200) écrire1(c,300) lire2(c,200) Exécution correcte : pour les utilisateurs, c est équivalent à l exécution de transfert suivie par Balance.. Exécution concurrente (Problèmes) 3 problèmes caractéristiques : perte de mise à jour lectures impropres lecture non reproductibles 3

4 Perte de mise à jour Etat initial de s: s=300 ; CI: s>= 0 t1: programme user1 Retrait(200F, s) temp1 lire(s) temp1 temp1-200 écrire(s,temp1) t2: programme user2 Retrait(300F, s) temp2 lire(s) temp2 temp2-300 écrire(s,temp2) Ordonnancement de t1 et t2 lire1(s,300) lire2(s,300) écrire2(s,0) écrire1(s,100) t1 toute seule est correcte; t2 toute seule est correcte Après l exécution concurrente : s= 100!!! La mise à jour de Retrait(300F, s) est perdue!! Lectures impropres CI:balance= c + s = 400 t1:programme user1 Virement(100F, s, c) temp1 lire(s) temp2 lire(c) écrire(s, temp1-100) écrire(c,temp2+100) t2:programme user2 Balance() temp3 lire(s) temp4 lire(c) imprimer(temp3+temp4) Après l exécution: balance= 300!!! Balance() a fait de lectures impropres Ordonnancement de t1 et t2 lire1(s,200) lire1(c,200) écrire1(s,100) lire2(s,100) lire2(c,200) écrire1(c,300) Lectures non reproductibles t1:programme user1 lire(s, 100) imprimer(x) lire(s, 300) imprimer(x) t2:programme user2 lire(s, 100) écrire(s, 300) Les 2 valeurs affichées ne sont pas identiques!! 4

5 Conclusion sur les exécutions concurrentes Imposer que chaque transaction soit individuellement correcte (respecte les CI) ne garantit pas que l exécution concurrente de ces transactions soit correcte i.e. Une exécution concurrente de deux transactions bien écrites peut laisser la base dans un état incohérent. Comment imposer que les exécutions concurrentes soient correctes : critère de correction (sérialisabilité ) protocole pour mettre en œuvre ce critère. Est-il possible d implanter le critère de sérialisabilité? Prouver si une exécution est sérialisable est un problème NP-complet on connaît des protocoles qui n acceptent que des exécutions sérialisables, mais pas toutes les exécutions sérialisables le protocole de verrouillage à deux phases est le plus implanté dans les systèmes existants. Verrouillage exclusif Toute transaction qui veut modifier un objet pose un verrou exclusif (noté X) sur cet objet. Une transaction qui veut poser un verrou exclusif sur un objet qui en possède déjà un doit attendre que ce verrou soit libéré par la transaction qui le possède. 5

6 Exemple Etat initial de s: s=600 ; CI: s>= 0 t1: programme user1 Retrait(200F, s) temp1 Xlire(s) temp1 temp1-200 écrire(s,temp1) t2: programme user2 Retrait(300F, s) temp2 Xlire(s) attendre attendre attendre temp2 temp2-300 écrire(s,temp2) Quand libérer les verrous? A cause des problèmes lié à la visibilité de résultats intermédiaires, une transaction qui possède un verrou exclusif ne le libère pas tant qu elle n a pas terminé son exécution. Visibilité d un résultat avant «rollback» Etat initial de s: s=600 ; CI: s>= 0 t1: programme user1 Retrait(200F, s) temp1 Xlire(s) temp1 temp1-200 écrire(s,temp1) rollback t2: programme user2 lire(s) temp2 lire(s)... La valeur lue par user2 n existe plus après le rollback. 6

7 Interblocage t1 Xlire(x,1) t1 avant t2 Xlire(y, 1) t2 Xlire(y,1) Xlire(x,1) t1 t1 avant t2 t2 x y Résolution des interblocages En général, détection en contexte centralisé, prévention en contexte distribué Correction par avortement forcé (rollback) Rollback : «défaire» les mises à jour libérer les verrous Lectures impropres et verrous exclusifs (1) CI:balance= c + s = 400 t2:programme user2 Balance() temp3 lire(s) t1:programme user1 Virement(100F, s, c) temp1 Xlire(s) temp2 Xlire(c) écrire(s, temp1-100) temp4 lire(c) imprimer(temp3+temp4) écrire(c,temp2+100) 7

8 Les verrous partagés Une transaction qui veut lire un objet sans le modifier doit poser un verrou partagé (noté P) sur cet objet Compatibilité (cf. slide suivant) L introduction de verrous partagés augmente les risques d interblocage. Table de compatibilité P X Rien P OK NO OK X NO NO OK Deux opérations sont en conflits si elles opèrent sur le même objet et une parmi elles est une opération d écriture Lectures impropres et verrous exclusifs (2) CI:balance= c + s = 400 t2:programme user2 Balance() temp3 Plire(s) temp4 Plire(c) imprimer(temp3+temp4) libérer(c,s) t1:programme user1 Virement(100F, s, c) temp1 Xlire(s) attente attente temp2 Xlire(c) écrire(s, temp1-100) écrire(c,temp2+100) 8

9 Quand libérer les verrous P? temp3 Plire(f) libérer (f) temp4 Xlire(h) temp 4 temp3 +1 écrire(h, temp4) commit temp1 Plire(h) libérer(h) temp2 Xlire(f) temp2 temp1 + 1 écrire(f,temp2) commit Si initialement, F et H valent 0, à la fin de l exécution, F et H valent 1, ce qui est non sérialisable Protocole de verrouillage à deux phases Avant d utiliser un objet, une transaction doit poser un verrou sur cet objet, toute transaction qui a libéré un verrou ne peut en acquérir d autres Propriétés ACID des transactions Atomicité: tout ou rien. Soit toutes les opérations de la transaction sont exécutées, soit aucune.. Cohérence: une transaction prise individuellement doit faire passer la base d un état cohérent dans un autre état cohérent. Isolation: une transaction ne doit observer que des états cohérents de la base (pas de résultats intermédiaire d une autre transaction) Durabilité: lorsqu une transaction termine, ses résultats deviennent permanents et ne peuvent plus être remis en cause, ni par une panne du système, ni par une autre transaction 9

10 Sûreté de fonctionnement Failure atomicity La journalisation des transactions. 2PC La journalisation des transactions Défaire les transactions faites par des transactions annulées Gérer les pannes rien T1 refaire à partir du PS T2 défaire toute la transaction T3 refaire T4 rien T5 Point de sauvegarde Panne Le journal Contient les événements principaux qui affectent la base de données (transaction, mise à jour) Pour chaque transaction : Date de début Date de fin Annulation ou non 10

11 Le journal Par mise à jour Identification de la transaction, Identification du n-uplet modifié Ancienne valeur, Nouvelle valeur Dates de sauvegarde Mécanisme de reprise Ancien état Faire Nouvel état Journal Nouvel état Journal Défaire Ancien état Ancien état Journal Refaire Nouvel état Re-démarrage du SGBD 1. Déterminer les transactions gagnantes 2. Déterminer les transactions perdantes 3. Défaire les transactions perdantes 4. Refaire les transactions gagnantes 5. Enregistrer le nouvel état comme PS (Verrouillage exclusif de la BD pendant le redémarrage) 11

12 Terminaison d une transaction distribuée Transaction distribuée : composée de plusieurs transactions qui s exécutent sur plusieurs sites Une transaction coordinatrice qui coordonne des (sous-) transactions Problème de terminaison d une transaction distribuée S Crédit (100) Journalisation Validation S Débit (100) Abandon S Atomicité d une transaction distribuée Propriétés d atomicité : Unanimité : toutes les transactions prennent la même décision Validité : la transaction n est validée que si toutes les transactions votent oui Terminaison : si toutes les défaillances sont réparées et aucune défaillance ne survient, tous les participants doivent décider Non-trivialité : les participants doivent décider de valider si tous les votes sont oui et si aucun site n est défaillant ou n est suspecté d être défaillant 12

13 Protocole de terminaison à deux phases (Two phases commit). «Préparer» est journalisé S S préparer La décision est journalisée La transaction est terminée vote décision acquittement S