Contrôle de l’Accès Simultané Chapitre 17 The slides for this text are organized into chapters. This lecture covers Chapter 19. The slides present the material suitable at the level of a graduate course; concurrency control in B+ Trees, optimistic concurrency control, and multiversion concurrency control are explained in detail. For an introductory undergraduate course, we usually cover only the material in slides 1 to 20. Chapter 1: Introduction to Database Systems Chapter 2: The Entity-Relationship Model Chapter 3: The Relational Model Chapter 4 (Part A): Relational Algebra Chapter 4 (Part B): Relational Calculus Chapter 5: SQL: Queries, Programming, Triggers Chapter 6: Query-by-Example (QBE) Chapter 7: Storing Data: Disks and Files Chapter 8: File Organizations and Indexing Chapter 9: Tree-Structured Indexing Chapter 10: Hash-Based Indexing Chapter 11: External Sorting Chapter 12 (Part A): Evaluation of Relational Operators Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques Chapter 13: Introduction to Query Optimization Chapter 14: A Typical Relational Optimizer Chapter 15: Schema Refinement and Normal Forms Chapter 16 (Part A): Physical Database Design Chapter 16 (Part B): Database Tuning Chapter 17: Security Chapter 18: Transaction Management Overview Chapter 19: Concurrency Control Chapter 20: Crash Recovery Chapter 21: Parallel and Distributed Databases Chapter 22: Internet Databases Chapter 23: Decision Support Chapter 24: Data Mining Chapter 25: Object-Database Systems Chapter 26: Spatial Data Management Chapter 27: Deductive Databases Chapter 28: Additional Topics

Plans Sérialisables par Rapport aux Conflits Deux actions sont en conflit si elles opèrent sur le même élément de la BD, elles appartiennent à différentes transactions, une d’elles au moins est une action d’écriture. Deux plans sont équivalents par rapport aux conflits si: Ils contiennent les mêmes actions des mêmes transactions. Chaque pair d’actions conflictuelles est ordonnée de la même manière dans les deux plans. Un plan S est sérialisable par rapport aux conflits ssi S est équivalent par rapport aux conflits à un (quelconque) plan séquentiel (sériel). Rappel: plan sérialisable plan recouvrable plan évitant les abandons en cascade

Exemple Le plan suivant n’est pas sérialisable p.r. conflits: Le cycle dans ce graphe révèle le problème. Le résultat de T1 dépend de T2 et vice-versa. T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B) A T1 T2 Graphe de dépendance B

Graphe de Dépendance Graphe de dépendance (précédence): contient un nœud par Xact; une arête de Ti à Tj si une action de Ti précède et entre en conflit avec une action de Tj. Théorème: Un plan est sérialisable p.r. conflits si et seulement si son graphe de dépendance est acyclique.

2PL Strict: Rappel Protocole ‘’Strict Two-phase Locking’’ (‘’Strict 2PL’’): Chaque Xact doit obtenir un verrou (partagé) du genre S sur un objet avant de le lire, et un verrou (exclusif) du genre X sur un objet avant de le lire. Tous les verrous sont retenus par une Xact jusqu’à sa fin complète. Si une Xact retient un verrou X sur objet, aucune autre Xact ne peut obtenir un verrou sur cet objet. 2PL strict ne permet que des plans dont le graphe de dépendance est acyclique.

2PL Protocole ‘’Two-phase Locking’’ (‘’2PL’’): Chaque Xact doit obtenir un verrou (partagé) du genre S sur un objet avant de le lire, et un verrou (exclusif) du genre X sur un objet avant de le lire. Aucune Xact ne peut obtenir de verrous supplémentaires après qu’elle ait relâché un verrou. Si une Xact retient un verrou X sur objet, aucune autre Xact ne peut obtenir un verrou sur cet objet. 2PL permet des plans non recouvrables.

Gestion des Verrous Les requêtes pour verrouiller/déverrouiller sont traitées par le ‘’lock manager’’. Le lock manager maintient une table des verrous, i.e. une table de hachage avec l’identité de l’objet de la base de données comme clé. Une entrée dans la table des verrous contient au moins: # de Xacts présentement verrouillant un objet Type de verrous (S ou X) Pointeur vers la queue des requêtes des verrous Verrouiller et déverrouiller doivent être des opérations atomiques. Promouvoir un verrou: transformer un verrou S en un verrou X. Rétrograder un verrou: transformer un verrou X en un verrou S. Cette approche est la plus répandue dans les systèmes commerciaux.

Interblockages (‘’Deadlocks’’) Interblockage: Cycle des transactions attendant que d’autres transactions leur passent des verrous sur un objet donnée. Deux voies de solutions classiques pour traiter les interblockages sont: prévention détection

Prévention des Interblockages Assigner des priorités basées sur des estampilles (‘’timestamps’’); l’estampille la plus petite a la plus grande priorité: i.e. les vieilles Xacts ont priorité sur les plus jeunes. Supposez que Ti veut un verrou retenu par Tj. Deux polices sont possibles à ce sujet: ‘’Wait-Die’’: Si Ti a une plus grande priorité, Ti attend que Tj finisse; sinon Ti est abandonnée et recommencée ‘’Wound-wait’’: Si Ti a une plus grande priorité, Tj est abandonnée et recommencée; sinon Ti attend Si une transaction recommence, elle doit reprendre son estampille initiale. La prévention est aussi possible en utilisant un 2PL conservateur: chaque Xact obtient à l’avance tous les verrous dont elle pourrait avoir besoin.

Détection des Interblockages Créer un graphe ‘’waits-for’’: Les nœuds sont des transactions Il y a une arête allant de Ti à Tj si Ti est entrain d’attendre que Tj relâche un verrou Ensuite vérifier périodiquement s’il n’y a pas de cycles dans le graphe ‘’waits-for’’.

Détection des Interblockages (Suite) Exemple: T1: S(A), R(A), S(B) T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) T1 T2 T1 T2 T4 T3 T3 T3

Contrôle d’Accès Simultané Optimiste Le verrouillage est une approche conservatrice et pessimiste dans laquelle on prévient les conflits. Desavantages: Coût de la gestion des verrous Détection/résolution des interblockages Congestion pour les objets très utilisés Si les conflits sont plutôt rares, on pourrait gagner en accès simultané en évitant de verrouiller les objets, mais plutôt en vérifiant la présence des conflits avant que les Xacts ne soient validées.

Le Modèle de Kung-Robinson Dans un protocole optimiste, les Xacts ont trois phases: LECTURE: Les Xacts lisent les données de la base de données, mais procèdent aux changements sur des copies privées des données lues. VALIDATION: Chercher les conflits. ECRITURE: Les copies locales modifiées par les Xacts validées sont rendues publiques. ROOT

Accès Simultané à Base d’Estampilles Idée: Donner à chaque objet une estampille de lecture (RTS), une estampille d’écriture (WTS), ainsi qu’une estampille de base (TS) au moment où elle commence: Si l’action ai d’une Xact Ti est en conflit avec une action aj d’une autre Xact Tj, et TS(Ti) < TS(Tj), alors ai doit être exécutée avant aj. Sinon, recommencer toute Xact qui violerait cet ordre.

Lorsque une Xact T veut Lire un Objet O Si TS(T) < WTS(O), cela viole l’ordre des estampilles par rapport à la Xact qui a écrit O. Ainsi if faut abandonner T et la recommencer avec une nouvelle et plus grande estampille TS. (Si T est recommencé avec la même TS, T échouera à nouveau!) Si TS(T) > WTS(O): Permettre à T de lire O. RTS(O) devient max(RTS(O), TS(T)) Les changements faits sur RTS(O) lors des lectures doivent être écrits sur disque! Cela entraîne des coûts (de même que les incessants recommencements des Xacts).

Lorsqu’une Xact T veut Écrire un Objet O Si TS(T) < RTS(O), cela viole l’ordre des estampilles par rapport à la Xact qui a écrit O. D’où T est abandonnée puis recommencée. Si TS(T) < WTS(O), cela viole l’ordre des estampilles par rapport à la Xact qui a écrit O. (Abandonner T ou appliquer la règle de Thomas) Règle d’écriture de Thomas: On peut ignorer de telles modifications périmées ; pas besoin de recommencer T! (la modification faite par T est effectivement suivie par une autre sans lectures intercalées.) Ceci permet quelques plans sérialisables mais pas sérialisables par rapport aux conflits: Sinon, permettre à T d’écrire O et WST(O) prend la même valeur que TS(T). T1 T2 R(A) W(A) Commit

Estampilles vs.Recouvrabilité Malheureusement, les estampilles permettent des plans nonrecouvrables: La méthode des estampilles peut être modifiée afin de permettre seulement des plans recouvrables; 2 stratégies sont possibles: Stocker toute écriture en tampon jusqu’à la validation de la Xact qui écrit (Mais mettre à jour la WTS(O) lorsque l’écriture est permise.) Bloquer toute Xact T qui lit (où TS(T) > WTS(O)) jusqu’à ce que la Xact qui écrit O soit validée. Similitude avec 2PL: les Xacts qui lisent ne relâchent les verrous qu’après validation.

Résumé Plusieurs méthodes de contrôle d’accès simultané basées sur le verrouillage existent (Strict 2PL, 2PL). Le graphe de dépendance permet de détecter les conflits entre Xacts. Le lock manager gère les verrous sur les objets. Les interblockages peuvent soit être prévenus ou détectés.

Résumé (Suite) Le contrôle d’accès simultané optimiste vise à minimaliser les coûts d’un tels accès dans un environnement dit optimiste dans lequel les lectures sont répandues et les écritures plutôt rares. Le contrôle optimiste engendre cependant d’autres coûts; beaucoup de systèmes commerciaux utilisent le verrouillage. Les estampilles sont une autre alternative à 2PL; elles permettent certains plans sérialisables que 2PL ne permettent pas. La recouvrabilité avec les estampilles est similaire au traitement des écritures dans 2PL.