cours/content/bdd_avancees/7-transactions/index.md at d4d633a1bc5d030d045213daa7e2b50605474b85

ephase/cours

Fork 0

Yorick Barbanneau 8b18e6f085 Transaction course part 2

2022-05-11 01:32:22 +02:00

11 KiB

Raw Blame History

title

date

L'exemple de la banque

Prenons un exemple de virement de 1000 euros d'un compte A vers un compte B:

Lire(A)
A = A - 1000
Ecrire(A)
Lire B
B - B + 1000
Ecrire(B)

Une fois la transaction terminée et validée, elle est réputée durable. Si elle échoue à partir de l'etape 3, il faut s'assurer que les modifications ne soient pas persistantes.

Les données sont alors cohérente : la somme de A est B est toujours la même.

Si une autre transaction accède à la base entre les étapes 3 et 6, elle trouvera la base dans un état incohérent (A + B est inférieur et 1000 euros se balladent...). L'isolation n'est pas assurée, la solution la plus simple consisterai alors à sérialiser les transactions.

État d'une transaction

Une transaction peut avoir 5 états:

Active: c'est une transaction en cours d'exécution
Partiellement validée: entre la dernière action et la validation
Échec: lorque l'exécution normale de la transaction ne peut avoir lieu
Avortée: après que toutes les modifications faite par la transaction soient annulées (rollback). Il est alors possible de réexécuter la transaction ou de la supprimer.
Validée: après l'exécution réussie de la dernière opération.

Implémentation de l'atomicité

Approche naïve

Nous pouvons commencer par une approche naïve : copie intégrale de la base lors d'une opération avec gestion d'un pointeur qui mème vers la dernière version cohérente. Le pointeur est modifié seulement si la transaction réussie.

En plus de ne permettre l'exécution d'une seule transaction (pas de gestion de l'exécution concurrente), cette approche est lourde et coûteuse surtout si la base est volumineuse.

L'exécution concurrente

Dans ce cas de figure, plusieurs transaction peuvent s'exécuter en même temps. Cette approche apporte une meilleure utilisation des ressources ( voir les [cours de système]({{< ref "/systemes_exploitation/1-introduction/index.md" >}}), ainsi on réduit le temps de réponse: une longue transaction ne bloque plus les autres.

Le contrôle de la concurence est le mécanisme permettant l'interaction entre les transaction tout en garantissant l'intégrité de la base.

Ordonnancement

Ici encore on peut se référer au cours de système d'exploitation. L'ordonnancement défini la manière d'exécuter les transactions concurrentes.

Ordonnancement en série

Soit $T_1$ et $T_2$ deux transactions ordonnancées par $O_1$, en série $T_2$ sera exécutée lorsque $T_1$ sera terminée.

Ordonnancement entrelacé

Ici les actions réalisées par deux transaction s'exécutent de manières entrelacées. Soit deux transactions (T_2) et (T_3), voici le plan d'ordonnancement $O_2$:

$ \begin{array}{l|l} T_1 & T_2 \\ lire(A) & \\ A := A + 1000 &\\ ecrire(A) &\\ & lire(A) \\ & tmp := A * 0.2 \\ & A := A - tmp \\ & ecrire(A) \\ lire(B) & \\ B := B + 1000 & \\ ecrire(B $ \\ & lire(B) \\ & B = B + tmp \\ & ecrire(B) \\ \end{array} $

Dans l'exemple ci-dessus, l'entrelassement ne préserve pas les valeurs de A et B. Les valeurs finales de notre version entrelacée ne correxpondent plus aux valeurs de la version en série. Nous sommes donc face à un problème

Notion de sériabilité

Dans le cas d'opération de lecture / écriture, nous partons du principe que chaque transaction prise à part conserve la coherence de la base. Ainsi l'ordonnancement en série préserve la cohérence.

Un ordonnancement entrelace est dit sérialisable si son résultat est exactement le même que s'il est exécuté en série.

L'ordonnancement $O_f$ composé de n transactions $T_1, T_2, ... T_n$ est sérialisable si toutes les permutations possibles ne changent pas le résultat. Il faut donc tester $n!$ possibilités de permutations.

Pour tester et trouver le bon ordonnancement, nous avons à notre disposition la c-sériabilité.

c-seriabilité

Les instructions notées $t_x$ et $t_y$ des transactions $T_x$ et $T_y$ ordonnancées par $O_n$ accèdent au même objet $Q$:

ne sont pas en conflit si elles accèdent toutes des deux à $Q$ en lecture
sont en conflit si l'une des deux (ou les deux) accède à $Q$en écriture

Si notre ordonnancement $O_n$ peut-être transformé en $O_n^\text{'}$ par une série de remplacement d'instructions non conflictuelle alors $O_n$ et $O_n^\text{'}$ sont dit c-équivalent. $O_n$ est c-sérialisable s'il est c-équivalent à un ordonnancement en série.

Reprise sur panne, récupérabilité

un Ordonnancement $O$ est récupérable si à la suite de l'annulation d'une de ses transactions, nous pouvons revenir à un état cohérent sans pour autant annuler les transaction validées.

Lors d'un ordonnancement récupérable, si $T_j$ lit un objet précédement écrit par $T_i$, la validation de $T_i$ a lieu avant celle de de $T_j$. Dans le cadre d'un ordonnancement en série le problème se se pose pas, mais comme nous l'avons vu c'est une méthode inefficace, surtout sans le cas d'achitecture multi-cœurs / multi-proceseurs.

C'est au SGBD de s'assurer de la récupérabilité des ordonnancements, mais cette tâche parfois difficile, prenons l'exemple simple suivant:

$ \begin{array}{l|l} t_1 & t_2 \\ lire(a) & \\ a := a + 1000 &\\ ecrire(a) &\\ & lire(a) \\ ecrire(b) & \\ ... & ... \\ \end{array} $

Si $T_1$ doit être annulée, alors la valeur de $A$ pourrait-être dans un état incohérent lorsque $T_1$ y accède. Le SGBDR doit alors positionner le curseur entre ordonnancement (réactivité, utilisation des ressources) et récupérabilité.

Pour deux transactions $T_i$, $T_j$,si $T_j$ accède une donnée écrite précédement par $T_i$ alors cette dernière doit être validée en premier.

L'échec d'une transaction peut entrainer des annulations en cascade, dans l'exemple suivant $T_2$ et $T_3$ doivent être annulé:

$ \begin{array}{l|l} t_1 & t_2 & t_3\\ lire(a) & & \\ a := a + 1000 & &\\ ecrire(a) & &\\ & lire(a) & \\ & & lire(a) \\ ecrire(b) & & \\ ... & ... & ... \\ \end{array} $

Un ordonnancement sans cascade est récupérable, il est donc préférable de limiter les ordonnancement entrelacé à ceux sans cascade.

tester la c-sériabilité

Considérons un ordonnancement $O$ avec les transactions $T_1, T_2, ... T_n$ :

$n$ est l'ensemble des transactions
il y a un arc $(T_i, T_j)$ s'il y a conflit entre ces deux transactions sur un object $Q$, $T_i$ accède à $Q$ avant $T_j$.

Alors $O$ est c-serialisable si son graphe de précédence est acyclique.

$ \begin{array}{l|l|l|l|l} t_1 & t_2 & t_3 & t_4 & t_5\\ & lire(x) & & & \\ lire(y) & & & & \\ lire(z) & & & & \\ & & & & lire(v) \\ & & & & lire(w) \\ & & & & ecrire(w) \\ & lire(y) & & & \\ & ecrire(y) & & & \\ & & ecrire(z) & & \\ lire(u) & & & & \\ & & & lire(y) & \\ & & & ecrire(y) & \\ & & & lire(z) & \\ & & & ecrire(z) & \\ lire(u) & & & & \\ ecrire(u) & & & \\ \end{array} $

Tester si l'ordonnancement est sérialisable après son exécution ou sur son graphe de précédence est inefficace. Le but ici est donc de développer des statégies de contrôle de la concurence qui puissent garantir la c-sériabilité. Il ne sera pas question de faire des tests sur le grahe de précédence mais plutôt les mécanisme de verrouillage que nous verrons un peu plus bas.

contrôle de la concurrence

notion de verrouillage

Lorsque une transaction accède à une donnée, elle pose un verrou dessus, il existe deux type de verrous:

exclusif: la transaction qui pose se verrou peux lire et écrire la donnée. Le verrou X est alors attribué à l'exécution via la commande Lock_X(data)
partagé: la transaction ne peut que lire la donnée. Le verrou P est attribué via la commande Lock_P(data)

C'est le rôle du gestionnaire de concurrence de gérer l'attribution des verrous à la demande des transaction. Il défini le protocole de verrouillage : commend demander et libérer les verrous. Cette dernière ne peut avancer tant que le verrou demandé ne lui a pas été attribué.

Une transaction ne peut poser un verrou sur une donnée qui si celui-ci est compatible avec le verrou déjà en place (s'il y en a un bien entendu).

Une transaction peut libérer certain verrou avec la commande Unlock().

Gestion de l'interblocage (deadlock)

Comme nous l'avons vu pour les [Mecanisme de synchronisation]({{< ref "/systemes_exploitation/3-synchronisation/index.md" >}}), dès qu'il y a verrou il y a risque d'interblocage. Les transaction n'échappent pas à la règle.

Protocole de verrou à deux phases

Ce protocole permet de garantir la c-sériabilité

phase 1: pose de verrous, il est interdit d'en libérer.
phase 2: libération des verrou, il est interdit d'en poser.

protocole avec estampille

C'est un protocole avec la gestion d'une file d'attente en fonction de l'heure d'arrivée: l'ordre chronologique des transactions.

granularité des verrouillage

Le verroullage peut se faire à plusieurs niveau organisés hiérachiquement:

la base
une table
une page
un tuple

Une transaction verrouiller n'importe quel niveau en fonction de ses besoins.

gestion des blocages

Le SGBDR peut intervenië sur deux niveaux : prévenir et guérir

prévenir

Il est question ici d'éviter les situations de blocage. L'estampille joue un rôle crutial : la gestion des transaction se fait en fonction de son horodatage (privilegier les plus anciennes)

guérir

Pour guérir mous pouvons

détecter les blocages à l'aide de graphe précédence
choisir d'ue transaction à annuler, en général celle la plus loin de son état final.

11 KiB Raw Blame History