Post on 04-Apr-2015
GESTION DE TRANSACTIONS
1
Pourquoi une transaction
Lier ensemble des opérations qui, logiquement sont indissociables et dont les effets ne peuvent être envisagées séparément.
Considérons un exemple d’application bancaire
2
Exemple
Lire compte courant de Mr X
Retrancher 1000 DT
Écrire résultat dans compte courant
Lire compte professionnel de Mr X
Ajouter 1000 DT
Écrire résultat dans compte professionnel
3
Exemple suite
Lire compte courant de Mr X
Retrancher 1000 DT
Écrire résultat dans compte courant
Lire compte professionnel de Mr X
Ajouter 1000 DT
Écrire résultat dans compte professionnel
4
Panne
Exemple suite
Debut-transaction Lire compte courant de Mr X
Retrancher 1000 DT
Écrire résultat dans compte courant
Lire compte professionnel de Mr X
Ajouter 1000 DT
Écrire résultat dans compte professionnel Fin-Transaction
5
Panne
Reprise du système jusqu’au début de la transaction
C’est quoi une transaction
Une Transaction, une séquence atomique d’actions sur une BD (lectures/écritures) séparant un commit ou un rollback du commit ou du rollback suivant.
Chaque transaction doit laisser la BD dans un état cohérent après l’avoir prise dans un état cohérent. Les utilisateurs peuvent spécifier des contraintes d’intégrité
simples sur les données et le SGBD se charge de les garder inviolables.
En dehors de ça, le SGBD n’a pas conscience de la sémantique des données (ex., il ne comprend pas comment les intérêts d’un compte bancaire sont calculés).
Le fait qu’une transaction préserve la cohérence de la BD est au bout du compte de la responsabilité de l’utilisateur!
6
Les menaces
Problèmes de concurrence pertes d ’opérations introduction d ’incohérences verrous mortels (deadlock)
Panne de transaction erreur en cours d'exécution du programme applicatif nécessité de défaire les mises à jour effectuées
Panne système reprise avec perte de la mémoire centrale toutes les transactions en cours doivent être défaites
Panne disque perte de données de la base
7
Propriétés des transactions
Atomicité Unité de cohérence : toutes les mises à jour doivent être
effectuées ou aucune. Cohérence
La transaction doit faire passer la base de donnée d'un état cohérent à un autre.
Isolation Les résultats d'une transaction ne sont visibles aux autres
transactions qu'une fois la transaction validée. Durabilité
Les modifications d ’une transaction validée ne seront jamais perdue
8
Commit et Abort
INTRODUCTION D’ACTIONS ATOMIQUES Commit (fin avec succès) et Abort (fin avec échec) Ces actions s'effectuent en fin de transaction
COMMIT Validation de la transaction Rend effectives toutes les mises à jour de la transaction
ABORT (Rollback) Annulation de la transaction Défait toutes les mises à jour de la transaction
9
Schéma de transaction simple
Fin avec succès ou échec
Begin_Transaction update update ..... Commit ou Abort
10
- Provoque l'intégration réelle des mises à jour dans la base- Relâche les verrous
- Provoque l'annulation des mises à jour
- Relâche les verrous
- Reprend la transaction
Effet logique
11
Mémoire de la transaction
Update
Update
CommitAbort
Bases de données Poubelle
Journaux et Sauvegarde
Journal des images avant Journal contenant les débuts de transactions, les valeurs
d'enregistrement avant mises à jour, les fins de transactions (commit ou abort)
Il permet de défaire les mises à jour effectuées par une transaction
Journal des images après Journal contenant les débuts de transactions, les valeurs
d'enregistrement après mises à jour, les fins de transactions (commit ou abort)
Il permet de refaire les mises à jour effectuées par une transaction
12
Journal des images avant
Utilisé pour défaire les mises à jour : Undo
13
Page lue
Base de données
Page modifiée
1.Read
3.Update
4.Write
2.Log
Journal des images après
Utilisé pour refaire les mises à jour : Redo
14
Page lue
Base de données
Page modifiée
1.Read
2.Update
4.Write
3.Log
Gestion du journal
Journal avant et après sont unifiés Écrits dans un tampon en mémoire et vider sur disque en début de
commit Structure d'un enregistrement :
N° transaction (Trid) Type enregistrement :
{début, update, insert, commit, abort} TupleId (Attribut modifié, Ancienne valeur, Nouvelle valeur) ...
Problème de taille on tourne sur N fichiers de taille fixe possibilité d'utiliser un fichier haché sur Trid/Tid
15
16
3. Scénarios de Reprise
Les mises à jour peuvent être effectuées directement dans la base (en place) la base est mise à jour immédiatement, ou au
moins dès que possible pendant que la transaction est active
Les mises à jour peuvent être effectuées en mémoire et installées dans la base à la validation (commit) le journal est écrit avant d'écrire les mises à jour
17
Stratégie do-undo
Mises à jour en place l'objet est modifié dans la base
Utilisation des images avant copie de l'objet avant mise à jour utilisée pour défaire en cas de panne
18
Mémoire cache
Base
Journal avant
Update
1. LirePage
2. LogPage
3. WritePage
Undo
Stratégie do-redo Mises à jour en différentiel
l'objet est modifié en page différentielle (non en place=ombre)
Utilisation des images après copie de l'objet en journal après mise à jour (do) utilisée pour refaire en cas de panne (redo)
19
Ombre
Mémoire cache
Base
Update
1. LirePage
3. LogPage
2. WritePage
Redo
Journal après
Commit
La gestion des buffers
Bufferisation des journaux on écrit le journal lorsqu'un buffer est plein ou lorsqu'une transaction commet
Bufferisation des bases on modifie la page en mémoire le vidage sur disque s'effectue en différé (processus
E/S) Synchronisation journaux / base
le journal doit toujours être écrit avant modification de la base !
20
Reprise à froid
En cas de perte d'une partie de la base, on repart de la dernière sauvegarde
Le système retrouve le checkpoint associé Il ré-applique toutes les transactions
commises depuis ce point (for each committed Ti : redo (Ti))
21
Problèmes de concurrence
Objectifs de la concurrence: Permettre l’exécution simultanée d’un grand
nombre de transactions Régler les conflits lecture / écriture Garder de très bonnes performances Éviter les blocages
22
Problème de concurrence
Nécessité d'exécuter les programmes et requêtes de façon concurrente
Garantir que l’exécution simultanée de plusieurs programmes se fait correctement
Cohérence de la base de données
Exécution correcte des programmes
Exemples de contextes hautement concurrentiels: annuaires téléphoniques (accès en lecture) systèmes de réservation de billets (lecture et mise à jour)
23
Inférences entre écrivains –Perte d’opération (lost update)
24
Ecriture inconsistante (dirty write)
25
Inférences entre lecteurs et écrivains –lecture inconsistante ( dirty read)
26
… -lecture non reproductible ( non-repeatable read)
27
… -lecture fantôme ( phantom read)
28
Contrôle de concurrence
Phénomènes indésirables : Lecture sale : Une transaction lit des données écrites par
une transaction Lecture non reproductible : Une transaction lit de
nouveau des données qu’il a lues précédemment et trouve que les données ont été modifiées par une autre transaction (qui a validé depuis la lecture initiale)
Lecture fantôme : Une transaction ré-exécute une requête renvoyant un ensemble de lignes satisfaisant une condition de recherche et trouve que l’ensemble des lignes satisfaisant la condition a changé à cause d’une transaction récemment validée.
29
Terminologie et Notation
Ti: une transaction de numéro i. Ri: une opération de lecture (read) de Ti. Wi: une opération d’écriture (write) de Ti. Ri(x): une opération de lecture sur l’objet x, x étant un
objet manipulé par Ti (p.e.: ligne, colonne, …).
Wi(x): une opération d’écriture sur l’objet x.
Exple: Transaction 1 Transaction 2R1(x) R2(x)x = x +5 R2(y) W1(x) R2(z)R1(y) x = x + y + z
z = x + y W2(x)W1(z) 30
… Terminologie
Ordonnancement ( schedule)T1 = R1(x), W1(x), R1(y), W1(Z)
T2 = R2(x), R2(y), R2(z), W2(x) S={R1(x), W1(x), R1(y), W1(Z), R2(x), R2(y), R2(z), W2(x)}S est un ordonnancement en série (sériel, serial); toutes les
opérations de T1 précèdent celles de T2(+) Aucun conflit entre les transactions. (-) problème de performance
Les mécanismes de contrôle de concurrence tentent d’interfolier ( interleave) les opérations de lecture et d’écriture de plusieurs transactions; de manière à toujours assurer un résultat identique à un ordonnancement en série.
31
Propriétés d’exécution
Recouvrabilité : Possibilité d’annuler l’effet d’une transaction qui
abandonne (abort). Solution : Ordre des Commit effectués par les transactions
suit l’ordre de dépendances Lecture(X)/Ecriture(X). Exemple
Conséquence sur l’exemple : le nombre de places disponibles a été diminué par T1 et repris par T2 , avant que T1 n’ annule ses réservations. Le nombre de sièges réservé sera plus grand que le nombre effectif de clients ayant validé leur réservation
32
Propriétés d’exécution
Sans Abandons en Cascade (Cascadeless) : la lecture d’une valeur écrite par une transaction T ne peut se faire
qu’une fois T a réalisé son Commit. Cascadeless ----> Recouvrable exemple
Ici, le rollback de T1 intervient sans que T2 n’ait validé. Il faut alors impérativement que le système effectue également un rollback de T2 pour assurer la cohérence de la base : on parle d’annulations en
cascade (noter qu’il peut y avoir plusieurs transactions à annuler). . Solution :la lecture d’une valeur écrite par une transaction
T ne peut se faire qu’une fois T a réalisé son Commit.33
Propriétés d’exécution
Strict : l’écriture d’une valeur déjà affectée par une autre transaction T ne peut se faire qu’une fois T a réalisé son Commit.
Exemple
Ici il n’y a pas de dearty read mais une dearty write. En effet T1 a validé après que T2 ait écrit dans s . Donc la validation de T1 enregistre la mise-à-jour de T2 alors que celle-ci s’apprête à annuler ses mises-à-jour par la suite. Au moment où T2 va annuler, le gestionnaire de transaction doit remettre la valeur du tuple connue au début de la transaction : ce qui revient à annuler la mise-à-jour de T1
Solution : Cascadeless + retarder les Write(X) jusqu’à ce que les écritures effectuées par d’autres transactions sur X soient validées (commit).
34
Propriétés
En résumé, on distingue trois niveaux de recouvrabilité selon le degré de contrainte imposé au système :
1. Recouvrabilité : on ne doit pas avoir à annuler une transaction déjà validée.
2. Annulation en cascade : un rollback sur une transaction ne doit pas entraîner l’annulation d’autres transactions.
3. Recouvrabilité stricte : deux transactions ne peuvent pas accéder simultanément en écriture à la même donnée, sous peine de ne pouvoir utiliser la technique de récupération de l’image avant
35
Notion d’équivalence Deux opérations sont conflictuelles ssi
Elles opèrent sur le même objet, Au moins une des 2 opérations est une écriture, Chacune des opérations à une transaction différente.
Exemple d’opérations conflictuelles:T1 = R1(x), W1(x), R1(y), W1(Z)T2 = R2(x), R2(y), R2(z), W2(x) (R1(x), W2(x)), (W1(x), R2(x)), (W1(x), W2(x)), (W1(z), R2(z)) Deux exécutions sont équivalentes si:
Les mêmes actions (lecture, écriture) se retrouvent dans les mêmes transactions
Chaque paire de d’actions conflictuelle (lecture/écriture, écriture/lecture ou écriture/écriture) sont ordonnées de la même façon dans les deux exécutions
36
Exécution sérialisable
Une exécution S est sérialisable si S est équivalente à une exécution en série des mêmes transactions
Exemple : Soit le programme réservation de spectacle, représenté par la séquence suivante :
r(s) r(c) w(c) w(s) r : Lecture (Read) w : Ecriture (Write) s : Séance c : Client
37
Soient deux transactions T1 et T2, chacun voulant réserver des places pour la même séance pour deux clients distincts c1 et c2. Soit la situation suivante : Il reste 50 places libres pour la séance s T1 veut réserver 5 places pour la séance s T2 veut réserver 2 places pour la séance s
Soit le déroulement imbriqué de ces deux réservations r1(s) r1(c1) r2(s) r2(c2) w2(s) w2(c2) w1(s) w1(c1)
T1 lit s et c1 : places libres 50 T2 lit s et c2 : places libres 50 T2 écrit s : 50-2 = 48 T2 écrit le nouveau compte de c2 T1 écrit s : 50-5 = 45 T1 écrit le nouveau compte de c1
38
Pbm!! Il reste 45 places libres alors que 7 places ont été réservées : T2 lit et modifie une information que T1 a déjà lue en vue de la modifier
Exécution sérialisable
Exécution sérialisable
Solution1 : Exécuter en série les transactions , on bloque une tant que la précédente n’a pas fini son exécution.
r1(s) r1(c1) w1(s) w1(c1) r2(s) r2(c2) w2(s) w2(c2)
Dans ce cas, pas de problèmes. T2 lit une donnée écrite par T1 qui a terminé son exécution et ne créera donc pas d’interférences.
Cette solution n’est pas acceptable, on ne peut pas se permettre de bloquer tous les utilisateurs sauf un, en attente d’une transaction qui peut durer très longtemps
39
Exécution sérialisable Solution2 : Exécution entremele de T1et T2
r1(s) r1(c1) w1(s) r2(s) r2(c2) w2(s) w1(c1) w2(c2)
T1 lit s et c1 : places libres 50 T1 écrit s = 50 – 5 = 45 T2 lit s : places libres 45 T2 lit c2 T2 écrit s = 45 – 2 = 43 T1 écrit le nouveau compte de c1 T2 écrit le nouveau compte de c2
Le résultat obtenu est le même obtenu par une exécution en série, on parle alors de sérialisabilité
40
Sérialisabilité
Hypothèses: Exécution d'une transaction individuelle est
correcte Exécution de transactions en série (les unes
derrière les autres) est correcte Idée: se ramener à une exécution de
transactions en série Concept de sérialisabilité
41
Exécutions de Transactions
42
Exécutions de Transactions
43
Sérialisabilité
Sérialisabilité: Critère permettant de dire que l'exécution d'un ensemble de transactions (schedule) est correcte
l'exécution de transactions entremêlées est correcte si elle est équivalente à une exécution des mêmes transactions en série (mêmes valeurs de départ et mêmes valeurs finales)
on dit que cet ensemble de transactions est sérialisable
44
Exemple
45
Graphe de dépendances
Il est possible de déterminer la sérialisabilité d'une exécution. On met en oeuvre des relations de précédence entre les transactions. Une fois toutes les relations de précédence établies, on peut générer un graphe dit de dépendance (précédence)
Théorème: Une exécution est sérialisable ssi son graphe de dépendance ne comporte pas de cycle
Graphe dépendances : Un noeud par transaction; liens de Ti à Tj si Tj effectue une lecture/écriture d’une granule précédemment écrit par Ti, ou si Tj effectue une écriture d’un granule précédemment lu par Ti.
46
Graphe de dépendances 1. Chaque transaction est un noeud du graphe; 2. Pour un objet O : Si une transaction T1 fait une
écriture de l'objet O avant qu'une transaction T2 ne fasse une opération sur cet objet alors, dans le graphe, T1 précède T2 : Cette relation de précédence est concrétisée par un arc orientée de T1 vers T2.
3. Pour un objet O : Si une transaction T1 fait une lecture sur l'objet O avant qu'une transaction T2 ne fasse une opération d'éciture sur cet objet, alors, dans le graphe, T1 précède T2:
4. L'exécution est sérialisable si et seulement si le graphe ne présente aucun cycle.
47
Graphe de dépendances
48
T1 T2 T3
Lire (Y)
Ecrire (Z)
Lire (Y)
Lire (X)
Ecrire (Y)
Ecrire (X)
Lire (Z)Lire (Y)Ecrire (Y)
Ecrire (X)
Lire (X)
Lire (Z)
Ecrire (Y)
- Définir pour chaque objet la liste des transactions qui accèdent a l'objet par ordre chronologique.
- dresser le graphe pour determiner si c’est serialisable ou non
Graphe de dépendances Pour L'objet X: Lecture de T1, Ecriture de T1, Lecture de T2, Ecriture de T2. Relation de précédence: T1 précède T2.
Pour l'objet Y: Lecture de T2, Ecriture de T2, Lecture de T3, Ecriture de T3, Lecture de T1, Ecriture de T1. Relation de précédence: T2 ecrit avant T3 donc T2 précède T3; T3 ecrit avant T1 donc T3 précède T1. Pour l'objet Z: Lecture de T2, Lecture de T3, Ecriture de T3. Relation de précédence: Le fait que T2 lise avant que T3 ne lise ne
provoque pas de conflit. Cependant, la précédence doit être exprimée ici, parce que T3 fait par la suite une opération d'écriture sur Z.
49
Graphe de dépendances Toutes les transactions sont représentées par des noeuds. On indique que T1 précède T2 en dessinant une flèche de T1 vers T2. Pour plus de clarté, on peut mettre sous chaque flèche, l'objet a partir duquel a été
déduite la relation représentée par la flèche. Le graphe de précédence ressemble alors a ce qui suit:
50
T1
T2
T3
X
Y,ZY
L’exécution donnée n’est pas serialisable
Graphe de dépendances Exemple2 :
51
T1 T2 T3
Lire (Y)
Ecrire (Z)
Lire (Y)
Lire (X)
Ecrire (Y)
Ecrire (X)
Lire (Z)
Lire (Y)Ecrire (Y)
Ecrire (X)Lire (X)
Lire (Z)
Ecrire (Y)
Graphe de dépendances
Pour L'objet X: Lecture de T1, Ecriture de T1, Lecture de T2, Ecriture de T2. Relations de précédence: On détermine sans difficulté que T1 précède
T2. Pour l'objet Y: Lecture de T3, Ecriture de T3, Lecture de T1, Ecriture de T1, Lecture
de T2, Ecriture de T2. Relations de précédence: T3 écrit avant T1 donc T3 précède T1; T3 écrit avant T2 donc T3 précède T2; T1 écrit avant T2 donc T1 précède T2. Pour l'objet Z: Lecture de T3, Ecriture de T3, Lecture de T2. Relations de précédence: T3 écrit avant T2 donc T3 précède T2.
52
Graphe de dépendances
53
T1
T2
T3
X,Y
ZY
Il n'y a pas de cycle dans ce graphe de sérialisabilite.
L’execution est serialisable .
Approche de la gestion de la concurrence
Objectif: forcer la sérialisabilité Deux méthodes:
Verrouillage Estampillage
Verrouillage: L’idée est simple : on bloque l’accès à une donnée dès qu’elle est lue ou écrite par une transaction (« pose de verrou») et on libère cet accès quand la transaction termine par commit ou rollback (« libération du verrou »)
Le verrou partagé (SLocks) est typiquement utilisé pour permettre à plusieurs transactions concurrentes de lire la même ressource.
Le verrou exclusif (XLocks) réserve la ressource en écriture à la transaction qui a posé le verrou.
54
Verrous exclusif : protocole PXO
Définition: un verrou est dit exclusif s'il interdit toute autre obtention d'un verrou, de quelque type que ce soit, sur l'élément verrouillé, par une autre transaction.
Verrous exclusifs avec libération explicite Toute demande d’accès contient implicitement une demande
de verrouillage (Lire XLire). Toute transaction qui a besoin d’une ressource qui est actuellement verrouillée est mise en attente (FIFO).
L'obtention du verrou autorise lectures et mises à jour Un verrou peut être relâché explicitement (XRelâcher) à
n’importe quel moment. Au plus tard, il est relâché implicitement à la fin de la transaction.
55
Verrouillage exclusif: exemple et problèmes
56
Solutions des Interblocages
Deux approches: Détection: laisser les transactions se mettre en interblocage, le détecter puis
le résoudre. Grâce au graphe de dépendances : un interblocage: un cycle dans le graphe
Quand faire la détection ? lors des demandes de verrouillage périodiquement après un certain temps d’attente pour une transaction
Action: tuer l’une des transactions celle qui a fait le moins de maj la plus jeune celle qui a le moins de ressources allouées …
Tuer: défaire (annuler ses maj, ses verrous) puis relancer automatiquement plus Tard Prévention: prévenir les interblocages.
En pratique, solution détection la plus souvent utilisée car prévention plus coûteuse.
57
Prévention des interblocages Prévention par estampillage:
Estampillage de chaque transaction avec l’heure de lancement
Si une transaction demande un verrou sur une ressource déjà verrouillée alors résolution dépend de l'estampille
58
Libération des verrous après écriture
Prévention et détection des interblocages défaire des transactions problèmes d’incohérence
B a lu une valeur de E qui logiquement n’a jamais existé (fantôme), Suite au "Rollback" de A, B doit être défaite, ainsi que toutes les transactions qui ont lu une valeur écrite par B (ROLLBACK en cascade)
Solution: ne relâcher un verrou exclusif qu’en fin de transaction (COMMIT ou ROLLBACK) Protocole PX (avec libération implicite)
59
Protocole PX
Verrous exclusifs avec libération implicite Toute demande d’accès contient implicitement une demande de verrouillage (Lire XLire). Toute transaction qui a besoin d’une ressource qui est actuellement
verrouillée est mise en attente (FIFO). L'obtention du verrou autorise lectures et mises à jour Le verrou n’est relâché qu’en fin de transaction (plus de XRelâcher)
60
Verrous Partagés (S Lock)
Les verrous exclusifs réduisent la simultanéité d’exécution Des transactions effectuant uniquement des lectures pourraient
s’exécuter simultanément Il faut s’assurer que pendant les lectures les éléments lus ne sont pas modifiés besoin d'un verrou partagé Plusieurs transactions peuvent obtenir un verrou partagé sur
un même élément Aucune transaction ne peut obtenir un verrou exclusif sur un
élément tant que tous les verrous partagés sur cet élément ne sont pas libérés
61
Verrous partagés:
SLire E: si le verrou partagé ne peut être obtenu mise en attente sinon un verrou partagé est mis sur E et la lecture est effectuée
SRelâcher E: libérer le verrou partagé détenu par la transaction sur E plus de nécessité de libérer le verrou à la fin de transaction car pas de
mise à jour
62
Verrous partagés: Protocole
Protocole PSX: pour mettre à jour un élément E de la base
demande verrou partagé sur E (SLire E)
Si E est déjà verrouillé en X mise en attente
mise à jour XEcrire E: demande de changement du verrou S sur E en verrou X sur E
comme en PX, le verrou exclusif n’est libéré qu’en fin de transaction
Inconvénient de PSX : augmentation des interblocages
deux transactions voulant mettre à jour le même élément vont obtenir deux verrous partagés qu’ensuite elles ne pourront transformer en verrous exclusifs (Les verrous de mise à jour remédient à ce problème, voir PUX)
63
Verrous de mise à jour (U) Protocole PUX: Toute
transaction qui veut mettre à jour un élément E de la base doit:
demander un verrou de mise à jour sur E ULire E
Si E est déjà verrouillé en X ou U mise en attente
pour la mise à jour sur E XEcrire E (demande de changement du verrou U en X)
le verrou exclusif n’est libéré qu’en fin de transaction
64
Verrous simples (X, S, U)
Le protocole PUX et les verrous de mise à jour réduisent les cas d’interblocage réduisent aussi la concurrence
Conclusion: les SGBD choisissent l’un des protocoles PX, PX0, PSX ou PUX, en fonction du degré de concurrence voulu et du pourcentage d’interblocages toléré
65
Libération des verrous après lecture(verouillage à deux phases)
66
Verrouillage à deux phases
Une transaction est à verrouillage à deux phases si : avant toute opération sur un élément, la transaction demande un
verrou sur cet élément pour cette opération, et après avoir rendu un verrou, la transaction n’en demande plus aucun
Durant une première phase la transaction acquiert des verrous et durant une seconde phase elle les libère
La deuxième phase peut être réduite à un instant si tous les verrous sont relâchés à la fin de la transaction
67
Verrouillage à deux phases…
Théorème (important): si toutes les transactions sont à verrouillage à deux phases, alors toutes les exécutions entremêlées de ces transactions sont sérialisables
68
Contrôle par verrouillage à deux phases
Exemple : T1 : r1 (x) w1 (y) C1 T2 : r2 (y) w2 (y) C2 Ordre de réception : r1 (x) r2 (y) w1 (y) C1 w2 (y) C2
r1 (x) exécutée r2 (y) exécutée w1 (y) retardée à cause de r2 (y) et tout le reste de T1 va être bloqué C1 bloqué w2 (y) exécutée C2 relâche les verrous sur y w1 (y) exécutée C1 exécutée
Exécution correcte : r1 (x) r2 (y) w2 (y) C2 w1 (y) C1 Conflits : r2 (y) - w1 (y) ; w2 (y) - w1 (y) Pas de cycle, donc H sérialisable
69
Unité de verrouillage multiple
Unités de verrouillage possibles: la base de données, un ensemble de relations, une relation, un tuple, une valeur (Plus unité fine, plus concurrence forte, plus overhead est grand)
Unité élémentaire: unité la plus fine proposée par le système (c'est souvent le tuple)
Unité composée: tout autre unité proposée par le système (c'est souvent la relation et la base de donnée)
L'utilisateur la possibilité de choisir l'unité de verrouillage. Mais : comment le système peut il savoir quand il a une demande de verrou sur une table (par ex) qu'il n'y a pas de verrous sur un de ses tuples?
Pas désirable de parcourir tous les verrous de la table…
70
Deux types de verrous
Deux types de verrous: Verrous d’intention (sur unité composée): intention de poser
plus tard des verrous effectifs (S, X) sur les unités composantes
Verrous effectifs (S, X vus précédemment). S et X peuvent être posés sur toute unité composée ou élémentaire
Pour placer un verrou sur un élément, on doit partir de l'élément le plus haut (table/tuple/valeur).
Si cet élément est celui que l'on souhaite verrouiller, on pose un verrou S ou X sur cet élément.
Si l'élément que l'on souhaite verrouiller est plus bas alors poser un verrou d'intention sur l'élément qui le contient puis un verrou S ou X sur l'élément à verrouiller.
71
Verrous d’intention
Verrous d’intention partagée (IS) : posé sur une unité composée C la transaction va demander des verrous partagés (S) sur certains éléments composants de C
Verrou d’intention exclusive (IX) : la transaction va demander un ou des verrous exclusifs (X) sur certains éléments composants de C, pour les mettre à jour
verrou partagé avec intention exclusive (SIX): un verrou SIX est un verrou S posé sur une unité composée C et un verrou IX posé sur C. Il signifie que la transaction permet que d'autres lisent les éléments de C, mais qu'elle n'autorise aucune mise à jour, et de plus qu'elle annonce son intention de demander des verrous exclusifs sur des éléments de C pour les mettre à jour.
72
Protocole: PI
Protocole d’emploi obtention d’un verrou X sur une unité:
obtention implicite d’un verrou X sur tous les composants de l’unité obtention d’un verrou S sur une unité
obtention implicite d’un verrou S sur tous les composants de l’unité pour demander un verrou S ou IS sur l’unité E
il faut avoir acquis un verrou IS (au moins) sur l’unité contenant E pour demander un verrou X, IX sur l’unité E
il faut avoir acquis un verrou IX (au moins) sur l’unité composée contenant E
avant de libérer un verrou sur une unité E avoir auparavant libéré tous les verrous sur des composants de E
Si plus de deux unités de verrouillage, les règles s’appliquent récursivement
73
Matrice de compatibilité
74
Justification
Soit un objet o contenu dans un objet O.
Si une transaction veut lire o alors elle doit empêcher toute modification de O dans sa totalité.
Pour lire o, elle le verrouille en mode S, ce qui implique de verrouiller O en mode IS, ce qui interdira à une autre transaction de verrouiller O en mode X et donc de modifier O dans sa totalité.
Si une transaction veut modifier o alors elle doit empêcher toute lecture ou modification de O dans sa totalité.
Pour modifier o, elle le verrouille en mode X, ce qui implique de verrouiller O en mode IX, ce qui interdira à une autre transaction de verrouiller O en mode S ou X et donc de lire ou de modifier Odans sa totalité.
75
Justification
Le verrouillage en mode IX (resp. IS) de O par une transaction T2 est accepté même s’il a déjà été verrouillé en mode IS (resp. IX) par une transaction T1car il se peut que le sous-ensemble des objets de O lus (resp. modifiés) par T1soit disjoint du sous-ensemble des objets de O modifiés (resp. lus) par T2. Dans le cas contraire, le verrouillage des objets communs en mode S ou X empêcherait le conflit.
76
Verrouillage en mode SIX
Soit la relation: livre(isbn, titre, catégorie, prix)
et la transaction T: UPDATE livre SET prix:= 1.25 * prix WHERE catégorie = 'roman';
Pour réaliser cette mise à jour, la transaction T doit demander un accès exclusif à la table livrepour empêcher toute modification de cette table durant l’opération de mise à jour.
Si T verrouille la table livre en mode exclusif alors elle ne pourra pas lire les n-uplets de livre pour sélectionner ceux qui doivent être mis à jour.
Par contre, si T verrouille la table livre en mode SIX (accès partagé exclusif), alors elle et elle seule pourra verrouiller les lignes de cette table en mode S pour les lire afin de sélectionner ceux qui sont des romans, qui eux seront verrouillés en mode X afin d’être modifiés.
77
Objets Fantômes: Problème
78
Objets Fantômes: Une solution
79
Techniques d’estampillage
SGBD centralisé concurrence avec verrous Verrous: explicitement demandés ou acquis automatiquement
lors des instructions de L/E Bases de données réparties peu compatibles avec un
gestionnaire de verrous centralisé technique d’estampillage
Transactions estampillées avec l’heure de lancement Verrous: assurent que l’exécution simultanée est
équivalente à une exécution séquentielle quelconque Estampillage: assure que l’exécution simultanée est
équivalente à l’exécution séquentielle correspondant à l’ordre chronologique des estampilles des transactions
80
Estampillage: Règles
Toutes les transactions s’exécutent simultanément Conflits: Une transaction demande à lire un élément déjà mis à jour par une transaction plus récente, Une transaction demande à mettre à jour un élément déjà lu ou mis à jour par une transaction plus récente
Ces demandes doivent être rejetées: la transaction trop vieille est tuée et relancée
avec une nouvelle estampille
81
Estampillage: résolution de conflits
A chaque élément de la base sont associées deux valeurs: LMAX: estampille de la transaction la plus jeune qui a lu cet
élément (sans avoir été tuée lors de cette lecture) EMAX: estampille de la transaction la plus jeune qui a écrit avec
succès l’élément (sans avoir été tuée lors du COMMIT) Si la transaction T demande à lire E (Lire E)
si estampille(T) ≥ EMAX(E) /* estampille (T) plus jeune que EMAX(E)
alors /*OK*/ LMAX(E):=Max(LMAX(E), estampille(T)) sinon /*conflit*/ Tuer T et relancer T avec une nouvelle estampille
Si la transaction T demande à mettre à jour E (Ecrire E) si estampille(T) ≥ LMAX(E) et estampille(T) ≥ EMAX(E) alors /*OK*/ EMAX(E):=estampille(T) sinon /*conflit*/ Tuer T et relancer T avec une nouvelle estampille
82
Gestion des accès concurrentset SQL
Il est possible en SQL de choisir explicitement le niveau de protection que l'on souhaite obtenir contre les incohérences résultant de la concurrence d'accès.
Options possibles :1) On spécifie qu'une transaction ne fera que des
lectures SET TRANSACTION READ ONLY;
2) Une transaction peut lire et écrire (Option par défaut) SET TRANSACTION READ WRITE;
83
SQL2 et les propriétés des exécutions concurrentes
• La norme SQL2 spécifie que ces exécutions doivent être sérialisables (mode par défaut). Un verrouillage strict doit alors être assuré par le SGBD.
SQL2 propose des options moins fortes : SET TRANSACTION ISOLATION LEVEL option
Liste des options :1. READ UNCOMMITTED : on autorise les lectures de tuples écrits par d'autres transactions mais non encore validées2. READ COMMITED : on ne peut lire que les tuples validés (pas de verrou sur une donnée lue). C'est le mode par défaut d'ORACLE.
84