Transactions et contrôles de concurrence : SGBD-tutoriel mysql-php.cn

Transactions and Concurrency Controls: DBMS

Transactions dans le système de gestion de base de données (SGBD)

Définition :

Une transaction dans un système de gestion de base de données (SGBD) est une séquence d'opérations effectuées comme une seule unité logique de travail. Une transaction peut impliquer la lecture, l'insertion, la mise à jour ou la suppression de données dans la base de données. La caractéristique clé d'une transaction est qu'elle est atomique, ce qui signifie que toutes les opérations au sein d'une transaction sont terminées avec succès, ou qu'aucune d'entre elles n'est appliquée du tout à la base de données.

Propriétés clés des transactions : propriétés ACID

Les transactions doivent respecter les propriétés ACID pour garantir la cohérence et la fiabilité de la base de données. Ces propriétés sont :

Atomicité :
- Atomicité garantit qu'une transaction est traitée comme une unité de travail unique et indivisible. Soit toutes les opérations de la transaction sont exécutées, soit aucune ne l'est. Si une partie de la transaction échoue, la totalité de la transaction est annulée, garantissant ainsi que la base de données reste dans un état cohérent.
- Exemple : Si une transaction implique le transfert d'argent du compte A vers le compte B, l'atomicité garantit que soit l'intégralité du transfert est terminée (l'argent est déduit de A et ajouté à B), soit rien n'est fait (aucun argent n'est transféré s'il y a un échec).
Cohérence :
- La cohérence garantit qu'une transaction déplace la base de données d'un état valide à un autre. Aucune transaction ne doit violer les contraintes d'intégrité de la base de données (telles que les clés primaires, les clés étrangères, etc.). Une fois la transaction validée, la base de données doit toujours être dans un état cohérent.
- Exemple : Après avoir transféré de l'argent entre deux comptes bancaires, la somme des soldes des deux comptes doit rester constante. Si la règle de cohérence de la base de données n'est pas respectée, la transaction sera annulée.
Isolement :
- L'isolement garantit que les opérations d'une transaction sont cachées des autres transactions pendant son exécution. Même si plusieurs transactions se déroulent simultanément, chaque transaction ne doit pas connaître les opérations des autres. Cela évite les lectures sales, les lectures non répétables et les lectures fantômes.
- Exemple : Si deux utilisateurs transfèrent simultanément de l'argent depuis le même compte bancaire, l'isolement garantit qu'une transaction n'interfère pas avec l'autre, évitant ainsi des erreurs telles que le double retrait.
Durabilité :
- La durabilité garantit qu'une fois qu'une transaction a été validée, ses modifications sont permanentes, même en cas de crash du système. Après une validation réussie, les modifications apportées par la transaction sont enregistrées dans la base de données et elles ne sont pas perdues.
- Exemple : Si un utilisateur a passé une commande avec succès, les modifications dans la base de données (telles que la mise à jour des stocks et le placement de la commande) devraient persister, même en cas de panne de courant soudaine juste après la validation.

Types de transactions

Transactions simples :
- Il s'agit d'une seule opération comme la lecture ou l'écriture de données. Par exemple, une simple requête de lecture ou une requête de mise à jour pourrait faire partie d'une transaction.
Transactions complexes :
- Celles-ci impliquent plusieurs opérations, notamment des lectures, des mises à jour, des insertions et des suppressions. Une transaction complexe peut être une séquence d'opérations conçues pour compléter un processus commercial, tel que le transfert d'argent d'un compte à un autre, ce qui implique de vérifier les soldes des comptes, de déduire de l'un et d'ajouter à l'autre.

Cycle de vie des transactions

Une transaction typique suit ces étapes :

Commencer la transaction :
- Cela marque le début d’une transaction. Cela indique qu'une nouvelle transaction est sur le point d'être effectuée.
Effectuer des opérations :
- La transaction effectue une série d'opérations de base de données, telles que la sélection, l'insertion, la mise à jour ou la suppression d'enregistrements. Ces opérations sont exécutées de manière séquentielle dans le cadre de la transaction.
Commettre la transaction :
- Une fois toutes les opérations terminées, la transaction est validée. Cela signifie que toutes les modifications apportées par la transaction sont enregistrées de manière permanente dans la base de données. Une fois validée, la transaction ne peut pas être annulée.
Transaction d'annulation :
- S'il y a une erreur ou un échec lors de l'exécution de la transaction (comme une violation d'une contrainte), la transaction est annulée. Cela signifie que toutes les modifications apportées par la transaction sont annulées et que la base de données revient à son état d'origine.
Fin de la transaction :
- Après une validation ou une annulation, la transaction se termine. Cela signifie que le cycle de vie de la transaction est terminé.

États des transactions

Une transaction doit être dans l'un des états suivants au cours de son cycle de vie :

Actif :
- L'état initial d'une transaction. La transaction reste dans cet état pendant l'exécution et l'exécution des opérations.
Partiellement engagé :
- Cet état se produit après l'exécution du relevé final de la transaction. À ce stade, la transaction a terminé toutes les opérations mais n'a pas encore été validée dans la base de données.
Échec :
- Une transaction entre dans l'état échec lorsqu'il est découvert que l'exécution normale ne peut plus se dérouler, généralement en raison d'un problème tel qu'une violation de contrainte ou une défaillance du système.
Avorté :
- Une fois la transaction annulée et la base de données restaurée à son état avant le début de la transaction, elle entre dans l'état abandonné.
Engagé :
- Une transaction entre dans l'état commit une fois que toutes les opérations sont terminées avec succès et que ses modifications ont été appliquées de manière permanente à la base de données.
Résilié :
- Une transaction est considérée comme terminée si elle a été validée ou annulée. Une fois qu'une transaction a atteint l'état validé ou interrompu, elle ne peut pas être redémarrée.

Planifications dans le SGBD

Un échéancier est une séquence d'opérations à partir de plusieurs transactions exécutées dans un ordre spécifique. Une planification détermine l'ordre d'exécution des opérations de lecture et d'écriture pour plusieurs transactions. L'objectif principal est de déterminer comment les transactions simultanées interagissent et de garantir que la base de données reste dans un état cohérent.

Un planning peut être série ou non-série.

Types d'horaires

Calendrier des séries :
- Un planning en série est celui où les transactions sont exécutées les unes après les autres sans aucun entrelacement. Cela signifie que les opérations d'une transaction sont entièrement terminées avant le début de la transaction suivante.
- Dans un planning en série, il n'y a pas de concurrence et le planning équivaut à exécuter les transactions de manière séquentielle.

Exemple de planning en série :

Transaction 1 : T1 : Lecture(A); Écrire(A); Commettre
Transaction 2 : T2 : Lecture(B); Écrire(B); Commettre
Les transactions sont exécutées les unes après les autres, et il n'y a pas de chevauchement dans les opérations.

Programmation hors série :
- Un planning non série permet aux opérations de plusieurs transactions de s'entrelacer. Dans ce type de planning, les transactions sont exécutées simultanément, ce qui signifie que leurs opérations sont mélangées.
- Un planning non série peut conduire à des résultats différents selon l'ordre dans lequel les opérations sont exécutées, et cela nécessite une gestion minutieuse pour maintenir les propriétés ACID.

Exemple de planning hors série :

T1 : Lire(A); Écrire(A);
T2 : Lire(B); Écrire(B);
T1 : Valider ;
T2 : Valider ;
Les opérations des transactions T1 et T2 sont entrelacées.

Sérialisabilité

Sérialisabilité est le concept consistant à garantir que le résultat de l'exécution simultanée de plusieurs transactions est le même que si les transactions étaient exécutées en série (l'une après l'autre). Un planning est dit sérialisable s'il est équivalent à un planning série en termes de son effet sur la base de données.

Importance :

L'objectif de la sérialisabilité est de garantir que les transactions simultanées ne provoquent pas de conflits ou d'anomalies (telles que des lectures incorrectes, des mises à jour perdues, etc.) et que la base de données reste dans un état cohérent.

Il existe deux principaux types de sérialisabilité :

Sérialisabilité des conflits :
- Une planification est sérialisable en cas de conflit si elle peut être transformée en planification série en échangeant des opérations non conflictuelles. Deux opérations sont considérées comme en conflit si elles proviennent de transactions différentes, accèdent au même élément de données et qu'au moins l'une d'entre elles est une opération d'écriture.
- Opérations de conflit :
  - Un conflit lecture-écriture se produit lorsqu'une transaction lit un élément de données qu'une autre transaction écrit.
  - Un conflit d'écriture-écriture se produit lorsque deux transactions écrivent toutes deux dans le même élément de données.

Exemple de sérialisabilité des conflits :

Horaire :
- T1 : Écrire(A);
- T2 : Écrire(B);
- T1 : Lire(B);
- T2 : Lire(A);
Cette planification peut être réorganisée en une planification en série et est sérialisable en cas de conflit.

Afficher la sérialisabilité :
- Une planification est sérialisable en vue si elle est équivalente à une planification en série en termes de résultat final, c'est-à-dire que les mêmes lectures et écritures se produisent et que les transactions sont sérialisées correctement. Cependant, en vue de la sérialisabilité, les opérations ne doivent pas nécessairement être échangées comme dans le cas d'un conflit de sérialisabilité.

Conflit équivalent, conflit sérialisable

Équivalent conflit :
- Deux plannings sont dits équivalents en conflit s'ils contiennent les mêmes opérations, les opérations sont dans le même ordre, et l'ordre des opérations en conflit est conservé. Cela signifie que l'entrelacement des transactions dans les deux calendriers produit le même résultat, garantissant qu'elles sont équivalentes en conflit.
Conflit sérialisable :
- Un planning est sérialisable en conflit si ses transactions peuvent être réorganisées pour former un planning en série, en maintenant l'ordre des conflits. En termes simples, une planification est sérialisable en cas de conflit si les transactions peuvent être sérialisées sans violer la cohérence des données, c'est-à-dire en maintenant l'ordre des opérations en conflit.

Exemple de sérialisabilité des conflits et de planifications équivalentes aux conflits

Considérons les transactions suivantes et leurs opérations :

Transaction T1 : Lire(A); Écrire(A); Commettre
Transaction T2 : Lire(A); Écrire(A); Commettre

Annexe 1 :

T1: Read(A);
T2: Read(A);
T1: Write(A);
T2: Write(A);
T1: Commit;
T2: Commit;

Copier après la connexion

Annexe 2 :

T2: Read(A);
T1: Read(A);
T2: Write(A);
T1: Write(A);
T1: Commit;
T2: Commit;

Copier après la connexion

Vérification de la sérialisabilité des conflits :

Schedule 1 et Schedule 2 sont équivalents en conflit car l'ordre des opérations en conflit (Lecture/Ecriture sur A) est conservé. Les deux plannings peuvent être transformés en planning série :
- T1 : Lire(A); Écrire(A); S'engager ;
- T2 : Lire(A); Écrire(A); S'engager ;
Par conséquent, les deux horaires sont sérialisables en conflit.

Isolement des transactions et atomicité

En plus des propriétés fondamentales des transactions, telles que les propriétés ACID, la gestion des échecs de transactions est un aspect important du maintien de la cohérence et de la fiabilité d'une base de données. Lorsque les transactions sont exécutées simultanément, la base de données doit garantir que tout échec au cours d'une transaction ne corrompt pas l'état de la base de données et que l'atomicité et la cohérence de la base de données sont préservées. Cette section explique comment la gestion des échecs affecte l'isolation des transactions et l'atomicité dans le SGBD.

Atomicité et gestion des échecs

Atomicité est la propriété d'une transaction qui garantit qu'elle est traitée comme une unité de travail unique et indivisible. Cela signifie qu'une transaction est soit entièrement terminée, soit pas exécutée du tout. Si une partie de la transaction échoue, la totalité de la transaction doit être annulée pour garantir qu'aucune modification partielle n'est appliquée à la base de données.

Lorsqu'une transaction échoue, tous les effets qu'elle a pu avoir sur la base de données doivent être annulés, afin que la base de données puisse revenir à son état avant le début de la transaction. Dans les systèmes qui permettent l'exécution simultanée de transactions, si une transaction T1 échoue, toutes les transactions qui dépendent de T1 (c'est-à-dire toute transaction T2 qui a lu ou écrit des données affectées par T1) doivent également être abandonnées pour préserver l'atomicité de la base de données. Si une transaction dépend d'une autre transaction qui échoue, elle ne doit pas laisser de modifications partielles ou de données incohérentes.

Pour éviter les incohérences lors de l'exécution des transactions, il est crucial de gérer les planifications qui dictent l'ordre des opérations de transaction, notamment en cas d'échec des transactions. Certains types d'horaires doivent être restreints pour garantir une bonne gestion des pannes.

Planifications récupérables

Un planification récupérable est celle dans laquelle une transaction T2 n'est validée qu'après la validation de la transaction T1 dont elle dépend. En termes plus simples, si la transaction T2 lit les données écrites par la transaction T1, T1 doit s'engager avant T2. Cela garantit que T2 ne valide pas les modifications basées sur une transaction non validée, évitant ainsi le scénario dans lequel la restauration de T1 nécessiterait également la restauration de T2.

Un planning qui enfreint cette règle est appelé un programmation non récupérable. Par exemple, si T2 valide après avoir lu les données écrites par T1, mais que T1 échoue et est annulé, la base de données ne peut pas être restaurée dans un état cohérent car la validation de T2 dépend des modifications non validées de T1. Dans cette situation, annuler T2 devient impossible, entraînant une incohérence des données.

Exemple de planning irrécupérable :
Dans un planning irrécupérable, disons :

La transaction T6 écrit des données dans l'élément A.
La transaction T7 lit la valeur de A écrite par T6 et s'engage immédiatement.

Si T6 échoue avant d'être validé, T7 dépend des modifications non validées apportées par T6. Puisque T7 a déjà été validé, nous ne pouvons pas annuler T7, ce qui conduit à une situation dans laquelle il est impossible de se remettre de l'échec de T6. Il en résulte un programme non récupérable.

Pour que la planification soit récupérable, T7 aurait dû retarder sa validation jusqu'après la validation de T6, garantissant que T7 ne dépend pas des données non validées de T6.

Horaires sans cascade

Même si une planification est récupérable, elle peut toujours entraîner des problèmes lors de la récupération après échec de transaction, en particulier lorsque des restaurations en cascade se produisent. Rollback en cascade fait référence à une situation dans laquelle l'échec d'une transaction entraîne une réaction en chaîne de rollbacks pour d'autres transactions dépendantes. Cette situation se produit lorsque des transactions lisent des données qui ont été écrites par une autre transaction non validée.

Par exemple, considérons le scénario où :

La transaction T8 écrit une valeur dans la donnée A, qui est lue par la transaction T9.
La transaction T9 écrit une valeur dans A, qui est ensuite lue par la transaction T10.
Si T8 échoue, T9, qui dépend de T8, doit également être annulé. T10, qui dépend de T9, doit également être annulé. Cela crée un effet de restauration en cascade, annulant inutilement le travail de plusieurs transactions.

Les restaurations en cascade ne sont pas souhaitables car elles conduisent à l'annulation d'une quantité importante de travail, même si une seule transaction échoue. Pour éviter les restaurations en cascade, nous pouvons utiliser des planifications sans cascade. Un planning sans cascade est celui dans lequel les transactions ne lisent pas les données écrites par une transaction qui n'a pas encore été validée.

Formellement, un programme sans cascade est celui dans lequel, pour deux transactions T1 et T2 quelconques, si T2 lit un élément de données écrit par T1, alors T1 doit avoir été validé avant que T2 ne lise l'élément de données. Cela garantit qu'aucune transaction ne peut dépendre de données non validées et qu'il n'y a pas de restaurations en cascade.

Chaque planning sans cascade est également un planning récupérable. Cela signifie que les planifications sans cascade empêchent non seulement les restaurations en cascade, mais garantissent également que la base de données peut récupérer correctement en cas d'échec de transaction.

Exemple de programmation sans cascade :
Considérez ce qui suit :

La transaction T8 écrit A et T9 lit A.
Dans un planning sans cascade, T9 ne peut lire A qu'après que T8 se soit engagé.

Cela garantit que T9 ne lit pas les données de T8 à moins que T8 ne se soit terminé avec succès, garantissant qu'aucune restauration de T9 n'est nécessaire en cas d'échec de T8.

Niveaux d'isolement des transactions

isolation des transactions garantit que les transactions simultanées n'interfèrent pas les unes avec les autres d'une manière qui viole la cohérence de la base de données. Le niveau d'isolement d'une transaction définit le degré auquel la transaction est isolée des autres transactions.

Il existe différents niveaux d'isolement, qui vont de faible à élevé :

Lire non engagé :
- Ce niveau d'isolement permet à une transaction de lire les données écrites par d'autres transactions non validées. Ce niveau peut entraîner des problèmes tels que des lectures sales, où une transaction lit des données qui pourraient ensuite être annulées, conduisant à des résultats incohérents.
Lecture validée :
- Une transaction à ce niveau ne peut lire que les données qui ont été validées par d'autres transactions. Bien que cela évite les lectures sales, cela peut toujours conduire à des lectures non répétables, où une transaction lit les mêmes données deux fois et obtient des résultats différents car une autre transaction a modifié les données entre-temps.
Lecture répétable :
- Ce niveau empêche à la fois les lectures sales et les lectures non répétables. Cependant, il autorise toujours les lectures fantômes, où une transaction peut rencontrer différents ensembles de lignes si d'autres transactions insèrent ou suppriment des enregistrements.
Sérialisable :
- C'est le niveau d'isolement le plus élevé. Il garantit que le résultat des transactions simultanées est le même que si les transactions étaient exécutées en série, les unes après les autres. Cela évite les lectures incorrectes, les lectures non répétables et les lectures fantômes, mais peut avoir un impact sur les performances en raison de sa nature stricte.

Le niveau d'isolement choisi pour une base de données ou une transaction affecte l'équilibre entre la cohérence des données et les performances, des niveaux d'isolement plus élevés entraînant généralement un ralentissement des performances en raison de restrictions plus importantes sur la concurrence.

Contrôle de concurrence dans le SGBD

Le contrôle de la concurrence est un aspect critique des systèmes de gestion de bases de données (SGBD) qui garantit l'exécution correcte des transactions tout en permettant l'exécution simultanée de plusieurs transactions. L’objectif du contrôle de concurrence est de maintenir la cohérence et l’intégrité de la base de données face aux scénarios d’entrelacement de transactions et d’échec. Cette section couvre les Protocoles basés sur le verrouillage, y compris divers modes de verrouillage, le Protocole de verrouillage en deux phases, les mécanismes de Gestion des blocages et les Protocoles basés sur l'horodatage .

Protocoles basés sur le verrouillage

Le verrouillage est un mécanisme fondamental utilisé dans les SGBD pour éviter les conflits entre des transactions exécutées simultanément. Des verrous sont appliqués aux éléments de données pour contrôler l’accès, garantissant ainsi que plusieurs transactions ne violent pas l’intégrité de la base de données. Dans le contrôle de concurrence basé sur les verrous, les transactions acquièrent des verrous sur les éléments de données avant d'effectuer des opérations sur ceux-ci, et libèrent les verrous une fois l'opération terminée.

Types de serrures

Il existe différents modes dans lesquels un élément de données peut être verrouillé. Dans cette section, nous limitons notre attention à deux modes de base :

Verrou(s) partagé(s) :
- Une transaction détient un verrou partagé sur un élément de données lorsqu'elle a uniquement besoin de lire l'élément.
- Plusieurs transactions peuvent détenir simultanément un verrou partagé sur le même élément de données. Cela permet des lectures simultanées de l'élément de données par différentes transactions.
- Le Verrouillage partagé ne permet pas à une transaction de modifier la donnée.

Exemple :

La transaction T1 détient un verrou partagé sur l'élément A et lit A.
La transaction T2 détient un verrou partagé sur l'élément A et lit A.
Les deux peuvent lire les données mais ne peuvent pas écrire sur A.

Verrou exclusif (X) :
- Une transaction détient un verrou exclusif sur un élément de données lorsqu'elle doit à la fois lire et écrire l'élément.
- Une seule transaction peut détenir un verrou exclusif sur un élément de données particulier à tout moment. Si une transaction dispose d'un verrou exclusif, aucune autre transaction ne peut acquérir un verrou partagé ou exclusif sur le même élément de données.

Exemple :

La transaction T1 détient un verrou exclusif sur l'élément A et y écrit.
Tandis que T1 détient le verrou exclusif sur A, aucune autre transaction ne peut lire ou écrire sur A.

Octroi de verrous

Les verrous sont accordés en fonction du protocole suivi par le système, et différents protocoles basés sur les verrous peuvent régir la manière dont les verrous sont demandés et accordés lors de l'exécution de la transaction. Ces protocoles permettent d'éviter les conflits tels que la perte de mises à jour, les incohérences temporaires et l'accès aux données non validées par d'autres transactions.

Protocole de verrouillage biphasé (2PL)

Le Protocole de verrouillage en deux phases est un protocole largement utilisé pour garantir la sérialisabilité — une propriété qui garantit que les transactions s'exécutent de telle manière que leurs résultats soient équivalents à leur exécution une après l'autre. un autre (en série). Le verrouillage en deux phases garantit la sérialisabilité en appliquant deux phases lors de l'exécution de la transaction :

Phase de croissance :
- Dans cette phase, une transaction peut acquérir des verrous mais ne peut en libérer aucun.
- La transaction peut demander n'importe quel nombre de verrous, mais une fois qu'elle libère un verrou, elle ne peut pas en acquérir de nouveaux. Cette phase se termine lorsque la première opération de déverrouillage est effectuée.
Phase de rétrécissement :
- Dans cette phase, une transaction peut libérer des verrous mais ne peut pas en acquérir de nouveaux.
- Une fois qu'une transaction commence à libérer les verrous, elle ne peut verrouiller aucun élément de données supplémentaire. Cette phase se termine lorsque la transaction est validée ou abandonnée.

Le protocole Two-Phase Locking garantit la sérialisabilité car il empêche les cycles dans le graphe de verrouillage, garantissant que l'ordre d'exécution suit une séquence stricte qui est sérialisable.

Exemple :

Les transactions T1 et T2 doivent mettre à jour les éléments de données A et B. En utilisant 2PL, les deux transactions acquerront les verrous nécessaires dans la phase de croissance et ne les libéreront qu'après avoir terminé leurs opérations (dans la phase de réduction).

Gestion des impasses

Une

Deadlock se produit lorsque deux transactions ou plus s'attendent l'une l'autre pour libérer les verrous, conduisant à une situation dans laquelle aucune d'entre elles ne peut se poursuivre. Cela crée un cycle de transactions en attente qui ne peut être résolu que si une ou plusieurs transactions sont annulées.

Prévention des blocages

Les techniques de prévention des blocages sont conçues pour éviter l'apparition d'un blocage en imposant des restrictions sur le comportement des transactions. Une stratégie courante pour éviter les impasses consiste à utiliser des horodatages pour hiérarchiser les transactions.

Schémas de prévention des blocages basés sur l'horodatage

Il existe deux systèmes de prévention des blocages importants qui utilisent des horodatages :

Le schéma d'attente et de mort :
- Il s'agit d'une technique non préventive de prévention des impasses.
- Si la transaction Ti demande un élément de données détenu par Tj, Ti n'est autorisé à attendre que si son horodatage est plus petit que celui de Tj (c'est-à-dire que Ti est plus ancien que Tj).
- Si l'horodatage de Ti est supérieur à celui de Tj, Ti est annulé (c'est-à-dire que Ti "meurt").

Exemple :

Si les transactions T14, T15 et T16 ont respectivement les horodatages 5, 10 et 15 :
- Si T14 demande une donnée détenue par T15, T14 attendra car T14 est plus ancien.
- Si T16 demande un élément de données détenu par T15, T16 sera annulé car T16 est plus jeune que T15.

Le schéma d'attente des blessures :
- Il s'agit d'une technique préemptive de prévention des impasses.
- Si la transaction Ti demande un élément de données détenu par Tj, Ti n'est autorisé à attendre que si son horodatage est plus grand que celui de Tj (c'est-à-dire que Ti est plus jeune que Tj).
- Si l'horodatage de Ti est plus petit que celui de Tj, Ti préempte Tj et Tj est annulé (c'est-à-dire que Tj est "blessé" par Ti).

Exemple :

Si les transactions T14, T15 et T16 ont respectivement les horodatages 5, 10 et 15 :
- Si T14 demande un élément de données détenu par T15, T14 préemptera T15, provoquant l'annulation de T15.
- Si T16 demande une donnée détenue par T15, T16 attendra car il est plus jeune que T15.

Protocoles basés sur l'horodatage

En plus des protocoles basés sur le verrouillage, les protocoles basés sur l'horodatage gèrent également la concurrence dans les bases de données. Ces protocoles utilisent des horodatages pour ordonner les transactions et résoudre les conflits, garantissant ainsi que le système se comporte comme si les transactions étaient exécutées en série.

Les horodatages et leur rôle

Les horodatages sont des valeurs numériques attribuées aux transactions lors de leur création. Le horodatage d'une transaction détermine sa priorité : une valeur d'horodatage inférieure indique une transaction plus ancienne et une valeur plus élevée indique une transaction plus récente.

W-timestamp(Q) :
- Cela indique l'horodatage le plus grand de toute transaction ayant exécuté avec succès une opération d'écriture sur l'élément de données Q.
- Cela permet d'identifier la dernière transaction qui a modifié la donnée.
R-horodatage(Q) :
- Cela indique l'horodatage le plus grand de toute transaction ayant exécuté avec succès une opération de lecture sur l'élément de données Q.
- Cela permet d'identifier la dernière transaction qui a lu l'élément de données.

Le protocole de commande d'horodatage

Le Protocole de commande d'horodatage garantit la sérialisabilité en appliquant un ordre total sur les transactions en fonction de leurs horodatages. Le protocole exige que :

Si une transaction Ti écrit un élément de données Q et qu'une autre transaction Tj lit ou écrit Q, Ti doit avoir un horodatage plus petit que Tj.
De même, si Ti lit un élément de données Q et que Tj écrit Q, Ti doit avoir un horodatage plus petit que Tj.

Ce protocole résout les conflits en fonction des horodatages des transactions plutôt que des verrous.

Exemple :

La transaction T1 avec l'horodatage 10 écrit la donnée A.
La transaction T2 avec l'horodatage 12 lit la donnée A.
Le protocole d'ordre d'horodatage garantit que l'opération d'écriture de T1 se produit avant l'opération de lecture de T2, préservant ainsi l'ordre correct des transactions.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!