LE CONCEPT DE TRANSACTION
E
Une transaction est unité de programme qui accède aux données de la base en lecture et/ou écriture. Une transaction accède à un état cohérent de la base. Durant l'exécution d'une transaction, l'état de la base peut ne pas être cohérent. Quand une transaction est validée (commit), l'état de la base doit être cohérent.
Deux types de problèmes :
problèmes systèmes (récupérabilité)
exécutions concurrentes de plusieurs transactions (séralisabilité)
En fait , la seule condition est qu’à la fin de la transaction, la base soit cohérente. C’est la récupérabilité (crash system, erreurs = état incohérent : comment revenir à un état cohérent ?).
Propriétés
Pour préserver l'intégrité des données, le système doit garantir :
Atomicité : Soit toutes les opérations de la transaction sont validées, ou bien aucune opération ne l'est.
Cohérence : L'exécution d'une transaction préserve la cohérence de la base (c’est à l’utilisateur de vérifier).
Isolation : Même si plusieurs transactions peuvent être exécutées en concurrence, aucune n'est censée prendre en compte les autres transactions i.e pour chaque paire de transactions Ti, Tj, pour Ti tout se passe comme si Tj s'est terminée avant le début de Ti ou bien qu'elle a commencé après la fin de Ti (les résultats intermédiaires de Tj ne lui sont pas apparents).
Durabilité : Si une transaction est validée, alors tous les changements qu'elle a faits sont persistants (même s'il y a un crash).
Ce sont les propriétés ACID (Atomicité, Cohérence,…)
Exemple
Une transaction qui transfère 1000 Frs du compte A vers le compte B
Il faut essayer d’exécuter le maximum de transactions en même temps, tout en conservant la propriété d’isolation.
1. Lire(A)
2. A:=A-1000
3. Ecrire(A)
Lire(B)
B:=B+1000
Ecrire(B)
La base est cohérente si la somme A + B ne change pas suite a l'exécution de la transaction (cohérence). Si la transaction "échoue" après l'étape 3, alors le système doit s'assurer que les modifications de A ne soient pas persistantes (atomicité). Une fois que l'utilisateur est informé que la transaction est validée, il n'a plus à s'inquiéter du sort de son transfert (durabilité).
Si entre les étapes 3 et 6, une autre transaction est autorisée a accéder a la base, alors elle "verra" un état incohérent (A + B est inférieur à ce qu'elle doit être). L'isolation n'est pas assurée. La solution triviale consiste a exécuter les transactions en séquence.
XVII.LES ETATS D'UNE TRANSACTION
Active : la transaction reste dans cet état durant son exécution.
Partiellement validée : juste après l'exécution de la dernière opération.
Echec : après avoir découvert qu'une exécution "normale" ne peut pas avoir lieu.
Avortée : Après que toutes les modifications faites par la transaction soient annulées (Poli back). Deux options :
- Ré-exécuter la transaction
- Tuer la transaction
Validée : après l'exécution avec succès de la dernière opération
Implémentation de l'atomicité
Approche naïve : c'est le mécanisme de reprise sur panne.
La notion de copie (shadow database) :
- On suppose qu'une seule transaction peut s'exécute en même temps.
- Un pointeur pointeur_bd pointe vers la version cohérente courante de la base.
- Toutes les mises a jour sont exécutées sur une copie. Pointeur_db ne pointera sur la copie que si la transaction est validée.
- Si la transaction échoue, alors la copie est supprimée. Si la transaction est validée, on garde la nouvelle sinon le pointeur repasse sur l’ancienne version.
Inefficace si la base est volumineuse !
|
