1 TransactionsTransactions Witold Litwin. 2 IntroductionIntroduction n Beaucoup d'opérations sur une BD doivent être atomiques: n Transfert d'argent entre.

Présentation au sujet: "1 TransactionsTransactions Witold Litwin. 2 IntroductionIntroduction n Beaucoup d'opérations sur une BD doivent être atomiques: n Transfert d'argent entre."— Transcription de la présentation:

1 1 TransactionsTransactions Witold Litwin

2 2 IntroductionIntroduction n Beaucoup d'opérations sur une BD doivent être atomiques: n Transfert d'argent entre les comptes: UPDATE Compte1 Val = Val -100 UPDATE Compte2 Val = Val + 100 n Si seulement une de ces requêtes est exécutée, la BD perd sa consistance

3 3 TransactionsTransactions n Opérations atomiques inexprimables avec une requête relationnelle. – entièrement ou pas du tout n Préservant la consistance de la BD n comme si l'usager était isolé sur la BD n A effet durable sur la BD, une fois terminées comme prévu Modèle ACID de transactions

4 4 Primitives de gestion de transactions n BEGIN, COMMIT, ROLLBACK BEGIN TRANSACTION UPDATE Compte1 Val = Val -100 IF SQLCODE <> 0 ROLLBACK ; EXIT ; UPDATE Compte2 Val = Val + 100 IF SQLCODE <> 0 ROLLBACK ; EXIT; COMMIT

5 5 Implémentation de transactions n TID : Identificateur de transaction n Inscription dans la BD seulement après le COMMIT n Journalisation: –Toute opération d'une transaction est notée avant et après l'exécution dans un fichier journal présumé à l'abris de pannes –Les opérations de commitement sont notées avant d'être exécutées sur la BD (write- ahead log protocol) n Points de reprise (checkpoints) –sauvegardes de l'état de la BD et notamment de TIDs de transactions en cours à intervalles réguliers

6 6 Et si la casse arrive... n On ferme l'accès à la base n On reprend le dernier checkpoint n On retrouve sur le journal toutes les transactions commises après –commencées avant ou après le checkpoint n On reexécute chronologiquement ces transactions –et seulement ces transactions n On rouvre la base aux usagers

7 7 Transactions non-ACID n Transactions imbriquées n Transactions longues n Transactions distribuées –exigent un commitement à 2 phases (2 PC)

8 8 ConcurrenceConcurrence n Les BDs étant partagées, les transactions pourraient être exécutées: –l'une après l'autre –simultanément »meilleures performances »possibilités d'inconsistances dans la base n Théorie de concurrence analyse les problèmes d'accès simultané

9 9 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 W 1 (A)A = 200 A := A +200 La base

10 10 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 W 1 (A)A = 200 A := A +200 W 2 (A)A = 300 La base

11 11 Gestion de la concurrence n Verrouillage exclusif –toute opération d'une transaction T sur une donnée D ne peut fait que si T obtient un verrou sur D –si D est déjà verrouillé par T' quand T le demande, alors T est mis en attente n Ce type de verrou est dit exclusif n On vient de définir un protocole de gestion de concurrence –Protocole 1

12 12 ExempleExemple A = 100 R 1 (A) A := A +100 W 1 (A)A = 200 La base L (A) U (A)

13 13 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 W 1 (A)A = 200 A := A +200 La base L (A) U (A) A = 400

14 14 Verrouillage partagé n les lectures ont les verrous partagés –T et T' peuvent lire D simultanément n les écritures doivent obtenir les verrous exclusifs –si D est déjà verrouillé par T', alors T est mis en attente n Avantage: –meilleures performances, mais... n C'est la méthode la plus usité –Protocole 2

15 15 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 A := A +200 La base L r (A) L w (A)

16 16 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 A := A +200 La base L r (A) L w (A)

17 17 Verrou mortel n Les transactions s'attendent mutuellement (deadlock) n Solution typique: –avorter une de transactions (la victime) –le choix est fait par le gestionnaire des verrous (lock manager)

18 18 ExempleExemple A = 100 R 1 (A) R 2 (A) A := A +100 A := A +200 A = 300 La base L r (A) L w (A) A W 2 (A)

19 19 A = 300 R 1 (A) A := A +100 A = 400 La base L r (A) L w (A) W 1 (A)

20 20 Les exécutions correctes n Sérialisabilité Les exécutions concurrentes sont correctes ssi leur résultat est équivalent à celui d'une exécution sérielle n Le critère naturel et le plus populaire –débattu néanmoins pour les systèmes multibases distribués »pourquoi ?

21 21 T1 T3 x := x+2 x := x*2 x := x/2 x := 10x := ? T2

22 22 T1 T2 T3 T1 T2 T3 T1 T2 T3 T1 T2 T3 T1 T2 Exécutions sérielles équivalentes x := x+2 x := x*2 x := x/2 x := 10x := ?

23 23 Les verrous / la sérialisabilité n Problème de "fantôme" –existe pour les deux protocoles: 1 et 2 10 20 30 40 50 60 T1 R L[R(1)], S := S + R(1), U[R(1)] L[R(2)], S := S + R(2), U[R(2)] L[R(3)], S := S + R(3), U[R(3)].... L[R(6)], S := S + R(6), U[R(6)] T2 L[R((3) R(3) := R(3) + 5, U[R(3)] L[R((6) R(6) := R(6) - 5, U[R(6)] Le résultat de T1 ? Temps

24 24 Verrouillage à 2 Phases

25 25 L(a) U(b) U(a,b) L(a) L(b) U(a) L(b) C C L(a) U(a,b) C L(b) Schedules 2PL

26 26 L(a) U(b) U(a,b) L(a) L(b) U(a) L(b) C C L(a) U(a,b) C L(b) U(b) L(a) L(b) C U(a)

27 27 Problème de "fantôme" n Est-ce que l'exécution discutée est conforme à 2PL ? n Sinon comment la rendre conforme ? n Le résultat, serait-il alors correct ?

28 28 n Dans les exemples on a verrouillé des tuples n Une table peut contenir des millions de tuples n 2-PL peut alors conduire à la gestion de millions de verrous n Est-ce la solution la plus performante ? n Pas toujours Granularité de verrous

29 29 Granularité de verrous n attribut n tuple Z page n table définie par un predicat Y table de base Y base de données –impossible d'inserer/supprimer MAJ un tuple d'une page ou table ou base vérouillée

30 30 Granularité de verrous n Granularité fine offre + de concurrence n Mais aussi plus délicats à gérer –tables de verrous + grandes –+ de possibilités de verrou mortel n En pratique en général on verrouille –tuples –pages n Elargissement d'un verrou (lock escalation) : –un verrou fin est remplacé par un verrou moins fin –tuple -> table

31 31 Niveaux d'isolation n Sérialisabilité totale coûte cher n N'est pas nécessaires pour toutes transactions n Les SGBD et SQL-3 offrent dès lors différents niveaux d'isolation de transactions –à utiliser avec des précautions

32 32 Niveaux d'isolation Les locks courts (short-term locks), latches, sont lâchés tout-de-suite Les locks longs sont maintenus jusqu'à la fin de la transaction dégrée de concurrence

33 33 Read Uncommitted exec sql set transaction read uncommitted n En SQL-3, une telle transaction est par défaut Read Only –pour prévenir les MAJs perdues »les Write ne sont possibles que par une transaction de niveau R-Committed au moins »une telle transaction est par défaut Read Write –sauf une déclaration Read Only dans l'ordre Set Transaction n fausses valeurs de fonctions agrégat. sont possibles n valeurs erronées dérivées de celles non-commises peuvent se propager entre les transactions

34 34 Read Committed exec sql set transaction read committed n Seules les valeurs commises sont lues –en utilisent R-latches de tuples n Les écritures utilisent W-locks de tuples n Les lectures successives d'une donnée positionnée par le curseur lisent toujours une même valeur –d'où le nom cursor stability n Un retour du curseur sur une donnée dans une même transaction peut par contre lire une valeur différente n Il n'y a pas de MAJ perdues –sauf si on le veut profondément n Le calcul d'une fonction agrégat peut être erronée

35 35 Pas de MAJ perdue n branch est la clé n Le tuple '123' est verrouillé jusqu'à commit exec sql declare cursor d for select bal from acc where branch = '123' for update of bal ; select bal from acc where branch = '123' for update of bal ; exec sql set transaction read committed ; exec sql open d ; exec sql fetch d into :bal ; bal = bal +5 ;/* lang. source exec sql set bal = :bal where current of d ; exec sql close d ; exec sql commit work ;

36 36 MAJ perdue exec sql set transaction read committed ; exec sql select bal into :bal from acc where branch = '123' ; bal = bal +5 ;/* lang. source exec sql update acc set bal = :bal where branch = '123' ; exec sql commit work ; n Pourquoi ?

37 37 Read Repeatable exec sql set transaction read repeatable n On utilise R-locks et W-locks de tuples n Les lectures d'une donnée peuvent être répétées dans une transaction n Une fonction agrégat peut-être correctement évaluée n Pas de MAJ perdues

38 38 MAJ OK exec sql set transaction read repeatable ; exec sql select bal into :bal from acc where branch = '123' ; bal = bal +5 ;/* lang. source exec sql update acc set bal = :bal where branch = '123' ; exec sql commit work ; n Pourquoi ?

39 39 Read Repeatable (problème) n Une insertion durant l'évaluation d'une fonction agrégat F est possible –le tuple correspondant n'est pas verrouillé –une deuxième évaluation de F dans une même transaction peut donner un résultat différent n Ces exécutions seraient non-sérialisables –Pourquoi ? n Considère que chaque transaction doit lire un tuple avec bal_tot fait par une autre transaction et signaler si bal_total n'est pas le résultat de F –alors on pourrait avoir une fausse alerte –Pourquoi ?

40 40 SerializableSerializable exec sql set transaction serializable n on utilise des verrous prédicatifs »predicate lock –un tel verrou s'applique à tous les tuples concernés par une requête »même ceux non-existant encore n l'anomalie de bal_tot devient impossible –on violerait le verrous prédicatifs n on obtient la sérialisation dans tous les cas

41 41 Predicate locks / Tuple lock Le predicat tuples verrouillées

42 42 Predicate locks / Tuple lock Le predicat tuples verrouillées

43 43 Predicate locks / Tuple lock Le verrou predicatif

44 44 Predicate locks / Tuple lock Le verrou predicatif

45 45 SerializableSerializable n Les SGBD actuels n'offrent pas de verrous prédicatifs –SQL-3 est en avance n On peut néanmoins verrouiller toute la table n Le cas d'anomalie citée est fort rare en pratique

46 46 Concurrence sous MsAccess n Conçue pour les transactions longues (interactives) n Trois modes d'accès : positionnement, édit, MAJ –ces deux dernières sont symb. par le crayon n On utilise des loquets et des verrous (et estampilles) –partagés et exclusifs n Trois granularités –page (n * 2048 octets) –table –base n Notifications –d'une MAJ concurrente faite –d'un verrou en écriture en cours n Pas d'attentes, mais des relances n Rafraîchissements

47 47MsAccessMsAccess n Mode pessimiste (Edited Records) –Le positionnement sur un tuple (la lecture) crée un verrous L r de la page –La demande d'édition signifie une demande d'un verrou L w sur la page –obtenu, sauf si un autre L w est en cours »alors il y a une notification (err. 3260 sous Access B.) »et, si on veut, jusqu'à 10 re-essais automatiques –"Retry Interval" est réglable entre 0 - 1000 msec –défaut = 250 msec (les options multiusager) –si la page a été modifiée depuis L r »il y a une notification (err. 3197 sous Access B.) »on peut écraser la MAJ de l'autre, si on veut !

48 48 MsAccess : mode optimiste n Correspond au choix "No locks" dans les propriétés d'une forme ou les options n L'édition correspond à L r seulement –donc plusieurs usagers peuvent éditer la même page et tuple n la page est verrouillée en écriture seulement pour la MAJ (durant la "update method"), par un loquet n Si un conflit alors –la notification et les re-essais comme pour la méthode pessimiste (err. 3186 sous Access B.) n Si la page a été modifiée depuis L r par une autre transaction –alors la notification d'une MAJ concurrente

49 49 MsAccess : L w d'une table n Mode "All records" n A utiliser prudemment n L'accès est refusé si une autre transaction a un L w même sur une page de la table –cas fort probable car les insertions ne se font que dans la dernière page (Access 2)

50 50 Concurrence sous MsAcces Propriétés globales et particularités n Les requêtes ne tiennent pas compte de données non- commises (en édition) n Les requêtes en lecture ne tiiennent pas compte de L w (posés par d'autres transactions) –particularité de MsAccess / SQL standard n 2-PL doit être généré par l'usager –en Access Basic n n Fantômes peuvent se créer n Verrou mortel peut arriver –mais pas dans les applications simples »l'accès à un tuple à la fois par une forme typique

51 51 Concurrence sous MsAcces Propriétés globales et particularités n Il ya une possibilité de rafraîchissement d'une forme ouverte à la suite d'une MAJ concurrente (donc ouvrez l'oeil !) –toutes les 1 : 32 766 sec, défaut 60 sec »voir les options multiusager n Les paramètres de gestion de la concurrence sont ceux –par défaut ceux des options –sauf si on a déclare un choix différent »dans les propriétés d'une forme ou dans le programme Access Basic n L'approche MsAccess mélange au niveau physique les verrous et les estampilles –logiques ou peut-être physiques (voir plus loin) n Il y a une confusion regrettable de la terminologie de deux approches – les modes "optimiste" et "pessimiste"

52 52 MsAccess Concurrence monousager n Mode pessimiste –même si l'on choisit "No Locks'" »donc pas de mode optimiste –sans avertissement n Mode exclusif (All Records) possible –Aussi bien entre les formes qu'entre les tables et entre les formes et les tables n Les requêtes ne tiennent pas compte de données en édition

53 53 Autres paradigmes pour gérer la concurrence n Estampilles (timestamps) –toute transaction est estampillée avec son temps t de commencement »temps logique ou physique –en principe, plus petit t gagne s'il y a un conflit »l'autre transaction est avortée et relancée –peut-être indéfiniment (livelock) n Avantages/désavantages –pas d'interblocage (deadlock) –performances en général moins bonnes que pour le verrouillage

54 54 Autres paradigmes pour gérer la concurrence n Deux approches –optimiste (meilleure quand peu d'écritures) »vérif. de conflits a posteriori à la fin de la transaction –phase de certification »si l'exec. incorrecte, alors l'une ou les deux transactions sont avortées –pessimiste »les conflits sont vérifiés tout de suite »les avortements sont faits aussitôt

55 55 2 2(b) 1(a) 1 1(b) C 5 5(b) C... Sch. Pessimiste

56 56 2 2(b) 1(a) 1 1(b) C 5 5(b) C... 1(a) 1 1(b) 2 2(b)... AA 4(a) 4(b) C 4 7 7(b) C... Sch. Pessimiste Sch. Optimiste

57 57 Dates de valeur n Toute transaction T est estampillée avec son temps-fin V (date de valeur) prévu –en principe, le plus petit V gagne le conflit »l'autre transaction T' est avortée et relancée ou mise en attente –selon le temps de conflit / à V' n Pas de dead-lock (pourquoi ?) n Potentiellement + efficace que estampilles n Applications –temps-réel (transactions avec deadlines) –systèmes multibases »commit implicite

58 58 6 (a) V = 6 Dates de valeur

59 59 V = 8 8 (b) 6 (a) V = 6 6 (b) A Dates de valeur

60 60 V = 8 8 (b) 6 (a) V = 6 6 (b) C V = 16 16 (b) C... Relance A Dates de valeur

61 61 6 (a) V = 6 Dates de valeur

62 62 6 (a) V = 6 6 (b) V = 13 13 (b)... W Dates de valeur Attente

63 63 6 (a) V = 6 6 (b) V = 13 13 (b)... C W Dates de valeur C Attente

64 64 COMMIT ?