6 KiB
| title | date | tags | categories | mathjax | |||
|---|---|---|---|---|---|---|---|
| Base de données avancées : Mise en œuvre des transactions | 2022-03-29 |
|
|
true |
Une transaction est une unité d'un programme qui accède à des données d'un SGBR en lecture, écriture ou les deux. Une transaction accède à un état cohérent de la base. Puis lors de son exécution l'état de la base peut ne plus être cohérent. Lors de sa validation (on parle de commit), l'état de la base doit redevenir cohérent.
Deux problèmes types peuvent se poser alors :
- problème systèmes: récupérabilité
- exécution concurente de plusieurs transactions: sériabilité.
Le système doit garantir les propriété ACID afin de preserver la cohérence des données :
- Atomicité: soit toutes les opérations sont validées soit aucune.
- Cohérence: l'exécution d'une transaction jusqu'à sa validation doit laisser la base dans un état cohérent.
- Isoliation: les transactions qui s'exécutent en concurence sont isolées les unes des autres. Les modification effectuée par l'une ne doivent pas être prise en comptes par une autre.
- Durabilité: si une transaction est validée, les modification qu'elle a apportée à la base sont persitantes, même après le redémarrage du service, une coupure de courant ou un crash
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 à serialiser les transaction.
É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 de la base. 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éponses: 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, ici l'ordonnancement défini la manière d'exécuter les transaction de manière concurrente.
Ordonnancement en série
Soit \(T_1\) et \(T_2\) deux transactions ordonancé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 transaction \(T_1, T_2, ... T_n\) est sérialisable si toutes les permutations possibles ne changent pas le résultat. Il faut don 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^'\) par une série de remplacement d'instructions non conflictuelle alors \(O_n\) et \(O_n^'\) sont dit c-équivalent. \(O_n\) est c-sérialisable s'il est c-équivalent à un ordonnancement en série.