Atomicit

1
Atomicité

• Transactions Atomiques
• Recouvrement à Base de Journal
• Checkpoints
• Transactions Concurrentes
• Serialisabilité
• Protocoles à Verrous

2
Transactions Atomiques

• Assure que les opérations sexécutent en 1 seul
  bloc logique, totalement, ou pas du tout
• Liées au domaine des bases de données
• Le challenge est dassurer latomicité en dépit
  des pannes de système
• Transaction - collection dinstructions ou
  dopérations qui exécute une fonction logique
  unique
• On est concerné par des changements persistents
  sur disque
• Une transaction est une série dopérations read
  et write
• Terminés par un commit (transaction réussie) ou
  abort (transaction non réussie)
• Les transactions non réussies doivent faire un
  rollback pour défaire tous les changements faits

3
Types de Média de Stockage

• Stockage Volatile information stockée ne survit
  pas après un crash système
• Exemple mémoire centrale, cache
• Stockage Non Volatile Information normallement
  survit après un crash système
• Exemple disque et cassette
• Stockage Stable Information jamais perdue
• Pas facilement atteignable, alors approximation
  via la réplication ou RAID sur des périphériques
  distincts

• Le but est dassurer latomicité dune
  transaction où les pannes provoquent des pertes
  dinformation sur du stockage volatile

4
Recouvrement à Base de Journal

• Enregistrer sur un média stable les informations
  de modifications effectuées par une transaction
• Plus commun write-ahead logging
• Ecrire sur un média stable, chaque entrée
  décrivant une seule opération décriture liée à
  une transaction
• Nom de la transaction
• Nom de litem de donnée
• Ancienne valeur
• Nouvelle valeur
• ltTi startsgt écrit dans le journal au début de la
  transaction
• ltTi commitsgt écrit quand la transaction réussit
  et ainsi se termine
• Une entrée du journal doit être écrite sur le
  média stable avant loccurrence des opérations
  sur les données

5
Algorithme de Recouvrement Basé sur un Journal

• Utilisant le journal, le système peut traîter
  toutes les erreurs en mémoire volatile
• Undo(Ti) restore la valeur de toutes les données
  modifiées par Ti
• Redo(Ti) affecte les nouvelles valeurs à toutes
  les données dans la transaction Ti
• Undo(Ti) and redo(Ti) doivent être idempotents
• Plusieurs exécutions doivent avoir le même
  résultat quune seule exécution
• Si le système tombe en panne, on restore les
  états de toutes les données modifiées via le
  journal
• Si le journal contient ltTi startsgt sans ltTi
  commitsgt, on fait undo(Ti)
• Si le journal contient ltTi startsgt et ltTi
  commitsgt, on fait redo(Ti)

6
Checkpoints

• Le journal peut devenir très long, et le
  recouvrement peut alors prendre beaucoup de temps
• Les checkpoints raccourcissent le journal et le
  temps de recouvrement.
• Schéma de Checkpoint
• Ecrire toutes les entrées de journal actuellement
  en mémoire volatile sur un média stable
• Ecrire toutes les données modifiées de la mémoire
  volatile sur le média stable
• Ecrire une entrée ltcheckpointgt dans le journal
• Maintenant, un recouvrement inclut uniquement les
  Ti, tel que Ti a commencé lexécution avant le
  dernier checkpoint , et toutes les transactions
  après Ti

7
Transactions Concurrentes

• Doivent être équivalentes à une exécution de
  transactions en série serialissabilité
• On pourrait exécuter toutes les transactions dans
  une section critique
• Pas efficace, très restrictive
• Algorithmes de contrôle de concurrence assurent
  la sérialisabilité

8
Serialisabilité

• Considérez deux données A et B
• Considérez les transactions T0 et T1
• Exécuter T0, T1 atomiquement
• Une séquence dexécution est appelée schedule
• Un ordre dexécutions atomiques de transactions
  est appelé schedule en série
• Pour N transactions, il y a N! schedules en
  séries valides

9
Schedule 1 T0 puis T1
10
Schedule Non Série

• Schedule Non Série permet des exécutions
  entrelacées
• Lexécution résultante pas nécessairement
  incorrecte
• Considérez le schedule S, opérations Oi, Oj
• Conflit sil y a accès aux mêmes données, avec au
  moins une écriture
• Si Oi, Oj sont consécutifs et les opérations de
  différentes transactions Oi and Oj ne sont pas
  en conflit
• Alors S avec un ordre Oj Oi équivalent à S
• Si S devient S en échangeant les ordres des
  opérations non conflictuelles
• S est conflict serializable

11
Schedule 2 Concurrent Serializable
12
Protocole à Verrous

• Assurer la sérialisabilité en associant un verrou
  à chaque donnée
• Suivre un protocole à verrous pour le contrôle
  daccès
• Verrou
• Partagé Ti a un verrou en mode partagé (S) sur
  litem Q, Ti peut lire Q mais pas écrire Q
• Exclusif Ti a un verrou en mode exclusif (X)
  sur Q, Ti peut lire et écrire Q
• Exige que chaque transaction sur un item Q
  acquière un verrou approprié
• Si le verrou est déjà pris, une nouvelle requête
  doit attendre
• Similaire aux algorithmes de lecteurs-écrivains

13
Protocole à Verrous à Deux Phases

• Générallement assure le conflit de
  serialisabilité
• Chaque transaction fait des requêtes de lock et
  unlock en deux phases
• Grandissant acquérir les verrous
• Rétrécissant relâcher les verrous
• Possibilité de deadlocks

14
Protocoles à Base dEstampilles

• Selectionne lordre parmi les transactions en
  avance Ordonnancement à base destampilles
• Transaction Ti associée avec lestampille TS(Ti)
  avant que Ti commence
• TS(Ti) lt TS(Tj) si Ti entre dans le système avant
  Tj
• TS peut être généré à partir de lhorloge système
  ou un compteur logique incrémenté à chaque
  transaction
• Les estampilles déterminent lordre de la
  sérialisabilité
• Si TS(Ti) lt TS(Tj), un système doit assurer que
  lordre produit est équivalent a lordre série où
  Ti apparaît avant Tj

15
Implémentation des Protocoles à base dEstampilles

• Une donnée Q reçoit deux estampilles
• W-timestamp(Q) plus grande estampille de la
  transaction qui a exécuté write(Q) avec succès
• R-timestamp(Q) plus grande estampille dun
  read(Q)
• Mise à jour dès quun read(Q) ou write(Q) sont
  exécutés
• Protocole dordonnancement à base destampilles
  assure que tous les read et write sont exécutés
  dans lordre de leurs timestamps
• Supposez que Ti exécute read(Q)
• Si TS(Ti) lt W-timestamp(Q), Ti a besoin de lire
  la valeur de Q qui a été réécrite
• operation read rejetée et Ti défaite (rolled
  back)
• Si TS(Ti) W-timestamp(Q)
• read exécuté, R-timestamp(Q) mis à
  max(R-timestamp(Q), TS(Ti))

16
Protocole dOrdonnancement à Base dEstampilles

• Supposez Ti exécute write(Q)
• Si TS(Ti) lt R-timestamp(Q), La valeur de Q
  produite par Ti était requise avant et Ti a
  assumé quelle ne pourra pas être produite
• Opération Write rejetée, Ti défaite (rolled back)
• Si TS(Ti) lt W-timestamp(Q), Ti essaye décrire
  une valeur obsolète de Q
• Opération Write rejetée et Ti défaite (rolled
  back)
• Sinon, write exécuté
• Toute transaction Ti défaite est assignée une
  nouvelle estampille et relancée
• Lalgorithm assure la conflict serialisabilité et
  supprime les deadlocks

17
Schedule Possible sous Protocole à Estampille