SGBD - Contrôle de la concurrence
Dans un environnement de multiprogrammation où plusieurs transactions peuvent être exécutées simultanément, il est très important de contrôler la concurrence des transactions. Nous avons des protocoles de contrôle d'accès concurrentiel pour assurer l'atomicité, l'isolation et la sérialisation des transactions simultanées. Les protocoles de contrôle d'accès concurrentiel peuvent être globalement divisés en deux catégories -
- Verrouiller les protocoles basés
- Protocoles basés sur l'horodatage
Protocoles basés sur les verrous
Les systèmes de base de données équipés de protocoles basés sur le verrouillage utilisent un mécanisme par lequel toute transaction ne peut pas lire ou écrire des données jusqu'à ce qu'elle acquière un verrou approprié. Les serrures sont de deux types -
Binary Locks- Un verrou sur une donnée peut être dans deux états; il est verrouillé ou déverrouillé.
Shared/exclusive- Ce type de mécanisme de verrouillage différencie les serrures en fonction de leurs utilisations. Si un verrou est acquis sur un élément de données pour effectuer une opération d'écriture, il s'agit d'un verrou exclusif. Permettre à plus d'une transaction d'écrire sur le même élément de données conduirait la base de données dans un état incohérent. Les verrous de lecture sont partagés car aucune valeur de données n'est modifiée.
Il existe quatre types de protocoles de verrouillage disponibles -
Protocole de verrouillage simpliste
Les protocoles simplistes basés sur le verrouillage permettent aux transactions d'obtenir un verrou sur chaque objet avant qu'une opération «d'écriture» ne soit effectuée. Les transactions peuvent déverrouiller l'élément de données après avoir terminé l'opération «d'écriture».
Pré-réclamer le protocole de verrouillage
Les protocoles de pré-réclamation évaluent leurs opérations et créent une liste d'éléments de données sur lesquels ils ont besoin de verrous. Avant de lancer une exécution, la transaction demande au système tous les verrous dont il a besoin au préalable. Si tous les verrous sont accordés, la transaction s'exécute et libère tous les verrous lorsque toutes ses opérations sont terminées. Si tous les verrous ne sont pas accordés, la transaction est annulée et attend que tous les verrous soient accordés.
Verrouillage biphasé 2PL
Ce protocole de verrouillage divise la phase d'exécution d'une transaction en trois parties. Dans la première partie, lorsque la transaction commence à s'exécuter, elle demande l'autorisation pour les verrous dont elle a besoin. La deuxième partie est l'endroit où la transaction acquiert tous les verrous. Dès que la transaction libère son premier verrou, la troisième phase démarre. Dans cette phase, la transaction ne peut pas exiger de nouveaux verrous; il ne libère que les verrous acquis.
Le verrouillage biphasé comporte deux phases, l'une est growing, où tous les verrous sont acquis par la transaction; et la deuxième phase se rétrécit, où les verrous détenus par la transaction sont libérés.
Pour réclamer un verrou exclusif (en écriture), une transaction doit d'abord acquérir un verrou partagé (lecture), puis le mettre à niveau vers un verrou exclusif.
Verrouillage biphasé strict
La première phase de Strict-2PL est identique à 2PL. Après avoir acquis tous les verrous dans la première phase, la transaction continue de s'exécuter normalement. Mais contrairement à 2PL, Strict-2PL ne libère pas de verrou après son utilisation. Strict-2PL détient tous les verrous jusqu'au point de validation et libère tous les verrous à la fois.
Strict-2PL n'a pas d'abandon en cascade comme le fait 2PL.
Protocoles basés sur l'horodatage
Le protocole d'accès concurrentiel le plus couramment utilisé est le protocole basé sur l'horodatage. Ce protocole utilise l'heure système ou un compteur logique comme horodatage.
Les protocoles basés sur le verrouillage gèrent l'ordre entre les paires en conflit entre les transactions au moment de l'exécution, tandis que les protocoles basés sur l'horodatage commencent à fonctionner dès qu'une transaction est créée.
Chaque transaction est associée à un horodatage et la commande est déterminée par l'âge de la transaction. Une transaction créée à 0002 heure d'horloge serait plus ancienne que toutes les autres transactions qui la suivent. Par exemple, toute transaction «y» entrant dans le système à 0004 est de deux secondes plus jeune et la priorité serait donnée à la plus ancienne.
De plus, chaque élément de données reçoit le dernier horodatage de lecture et d'écriture. Cela permet au système de savoir quand la dernière opération de «lecture et d'écriture» a été effectuée sur l'élément de données.
Protocole de commande d'horodatage
Le protocole de classement par horodatage garantit la sérialisabilité des transactions dans leurs opérations de lecture et d'écriture conflictuelles. Il est de la responsabilité du système de protocole que la paire de tâches en conflit soit exécutée conformément aux valeurs d'horodatage des transactions.
- L'horodatage de la transaction T i est noté TS (T i ).
- L'horodatage de lecture de l'élément de données X est désigné par l'horodatage R (X).
- L'horodatage d'écriture de l'élément de données X est désigné par W-timestamp (X).
Le protocole de commande d'horodatage fonctionne comme suit -
If a transaction Ti issues a read(X) operation −
- Si TS (Ti) <W-horodatage (X)
- Opération rejetée.
- Si TS (Ti)> = W-horodatage (X)
- Opération exécutée.
- Tous les horodatages des éléments de données ont été mis à jour.
If a transaction Ti issues a write(X) operation −
- Si TS (Ti) <R-horodatage (X)
- Opération rejetée.
- Si TS (Ti) <W-horodatage (X)
- Opération rejetée et Ti annulé.
- Sinon, opération exécutée.
Règle d'écriture de Thomas
Cette règle indique si TS (Ti) <W-horodatage (X), alors l'opération est rejetée et T i est annulée.
Les règles de commande d'horodatage peuvent être modifiées pour rendre la vue de planification sérialisable.
Au lieu de faire revenir T i , l'opération «d'écriture» elle-même est ignorée.