SysRp Transactions-B A. Schiper Et 20071Chapitre 1 Systmes transactionnels(suite)SysRp Transactions-B A. Schiper Et 200723.3 Atomicit et durabilit Atomicit et durabilit sont lies:1: begin-transaction2: read(account1, v1)3: read(account2, v2)4: v1 v1 15: v2 v2 + 16: write(account1, v1)7: write(account2, v2)8: end-transaction La transaction se termine par commit, mais: v1 crit en mmoire permanente, mais pas v2 (en raison d'un crash) atomicit viole, ou durabilit viole ? Consquence: il est difficile de sparer les mcanismes qui assurent latomicit et de ceux qui assurent la durabilitSysRp Transactions-B A. Schiper Et 20073Atomicit et durabilit (2)Ide gnrale: Sappuyer sur des protocoles locaux, qui chacun assure localementatomicit et durabilit Coordonner les protocoles locaux pour assurer que tous les sites accds par la transaction dcident commit ou tous les sites dcidentabortSysRp Transactions-B A. Schiper Et 20074Mmoire permanente vs. mmoire stable L'information sur disque est suppose permanente. Mais l'criture sur disque n'est pas forcment atomique (donc risque d'tat incohrent) Trois cas considrer pour l'criture d'un bloc sur disque:1. criture se termine correctement: le bloc contient la nouvelle valeur2. crash durant l'criture du bloc: le bloc est partiellement crit, et se trouve dans un tat incohrent3. crash avant l'criture (aucune donne crite): le bloc contient l'ancienne valeur Mmoire stable: abstraction introduite pour modliser une mmoire permanente toujours dans un tat cohrent (criture sur disque atomique) SysRp Transactions-B A. Schiper Et 20075Mmoire stable Mmoire stable implmente par rplication (un bloc logique de la mmoire stable implment par deux blocs physiques) Un checksum par bloc physique permet de savoir si le contenu dun bloc est cohrent (bloc compltement crit)SysRp Transactions-B A. Schiper Et 20076Ecriture d'un bloc (logique) en mmoire stable Ecriture du premier bloc (physique) Ecriture de la mme information sur le deuxime bloc (physique)L'criture est considre russie ds que l'criture du premier bloc se termine.SysRp Transactions-B A. Schiper Et 20077Lecture d'un bloc (logique) en mmoire stable Lecture des deux blocs physiques Si les deux blocs sont identiques (notamment checksums corrects), retourner le contenu de n'importe quel bloc Si un des blocs contient un checksum incorrect, alors mettre jour l'autre bloc, et retourner le contenu du bloc correct (si premier bloc incorrect, alors retourne l'ancienne valeur, si le deuxime blocincorrect, alors retourne la nouvelle valeur) Si les deux blocs contiennent un checksum correct, mais sont diffrents, alors mettre jour le deuxime bloc avec le contenu du premier, et retourner le contenu du premier bloc (masque le crash durant l'criture du deuxime bloc)NB Ce protocole coteux peut tre excut lors dun recovery. Cela permet par la suite de ne lire quun seul bloc.SysRp Transactions-B A. Schiper Et 20078Protocole de recouvrement local Excut par le LRM(Local Recovery Manager) Protocole LRM dpend de la technique utilise pour l'criture:(1) in-place updating: valeur prcdente crase (avant commit)(2) out-of-place updating: nouvelle valeur crite n'crase pas la prcdente (avant le commit)SysRp Transactions-B A. Schiper Et 20079In-place updating La plupart des bases de donnes implmentent la technique in-placeupdating (raison d'efficacit) Cette technique ncessite en gnral de garder lancienne valeur et la nouvelle valeur dans un journal (log file): pr-image (before image): ancienne valeur post-image (after image): nouvelle valeurSysRp Transactions-B A. Schiper Et 200710In-place updating (2)BMBuffers de logsBuffers de donnesLog stable (sur disque)Donnes stables (sur disque)Read/WriteSysRp Transactions-B A. Schiper Et 200711In-place updating (3)Crash l'instant t: Cas 1: une transaction T1 a committ, mais l'instant t, les critures de T1 n'ont pas t rpercutes en mmoire stable Cas 2: une transaction T2 n'a pas committ, mais des critures de T2 ont t rpercutes en mmoire stable (cas possible si l'criture du cache est sous le seul contrle du BM). Cas 1: lors du recovery, le LRM lit la post-image de T1 du journal (en mmoire stable), et rcrit la post-image (action redo) Cas 2: lors du recovery, le LRM lit la pr-image de T2 du journal (en mmoire stable), et rcrit la pr-image (action undo)SysRp Transactions-B A. Schiper Et 200712Gestion du cacheQuatre stratgies: fix: le BM n'crit aucune donne non committe (le cache est fix en mmoire principale) Dfinit une interdiction no fix: le BM peut propager en mmoire stable des donnes non committesPas dinterdiction flush: le BM est forc d'crire des donnes committes en mmoire stable au moment du commitDfinit une obligation no flush: le BM n'est pas forc d'crire des donnes committes en mmoire stablePas dobligationSysRp Transactions-B A. Schiper Et 200713Gestion du cache (2)Quatre algorithmes: no-fix / no-flush (correspond l'exemple des transactions T1, T2 ci-dessus)Technique utilise dans les bases de donnes commerciales. no-fix / flush fix / no-flush fix / flushSysRp Transactions-B A. Schiper Et 200714Gestion du cache (3)Dans ces quatre algorithmes: Dbut de transaction: le LRM crit un enregistrement begin-transaction dans le journal Read: la donne est lue depuis le cache (si disponible). Sinon la donne est lue depuis la mmoire stable dans le cache, et la donne est retourne la transaction Write, Commit, Abort, Recovery: dpend de l'algorithmeSysRp Transactions-B A. Schiper Et 200715No-fix / no-flush (redo / undo) Write: la donne est mise jour dans le cache (si prsente). Sinon la page contenant la donne est lue en mmoire stable, et la donne est mise jour. La pr-image et la post-image sont crites dans le journal. Commit: le LRM crit un enregistrement end-of-transaction dans le journal, et le journal est crit en mmoire stable. Le LRM informe ensuite le scheduler du commit (le scheduler peut relcher les verrous dtenus par la transaction) Abort: le journal est utilis pour excuter les actions undo. Le LRM lit les pages modifies dans le cache et utilise le journal pour crire la pr-image (undo).Le LRM informe ensuite le scheduler de l'avortement (le schedulerpeut relcher les verrous dtenus par la transaction).SysRp Transactions-B A. Schiper Et 200716Terminologie Un enregistrement du journal doit tre crit en mmoire stable avant l'criture de la donne correspondante. Ceci est appel write ahead log protocol.SysRp Transactions-B A. Schiper Et 200717No-fix / no-flush (redo / undo)(2) Recovery: le LRM lit le journal depuis la mmoire stable et distingue deux cas:(1) les transactions tels que begin-transaction et end-of-transaction sont dans le journal (la transaction a committ)(2) les transactions tels que begin-transaction uniquement est dans le journal (la transaction a avort) Cas 1: le LRM excute les actions redo, en utilisant la post-image du journal Cas 2: le LRM excute les actions undo, en utilisant la pr-image du journal(Hyp: protocole write-ahead log)SysRp Transactions-B A. Schiper Et 200718Exemple Initialement: a=10, b=10 T1 lit a et b, crit a-10 dans a et b-10 dans b;commit de T1 T2: identique T1, crash avant commit de T2 Recovery T3 identique T1, T3 avorteSysRp Transactions-B A. Schiper Et 200719Rduction de la taille du journalIl faut priodiquement vider le journal (sinon recovery prendrait beaucoup de temps).Deux techniques: Lopration de rduction est excute lorsquaucune transaction n'est excute.Ceci est appel rduction synchrone du journal Lopration de rduction est excute pendant lexcution de transactions.Ceci est appel rduction asynchrone du journalSysRp Transactions-B A. Schiper Et 200720Rduction synchrone du journalSolution: mettre le donnes en mmoire stable jour par rapport au contenu du journal (checkpointing): Ecrire begin-checkpoint dans le journal Excuter les actions permettant de mettre les donnes en mmoirestable jour par rapport au contenu du journal Ecrire end-checkpoint dans le journal Effacer tous les enregistrements du journalSi un crash survient avant l'criture de end-checkpoint, on recommence depuis le dbut (mise jour des donnesen mmoire stable avec le contenu du journal).SysRp Transactions-B A. Schiper Et 200721Protocoles rpartis Protocole local: excute une action lors de commit et lors de abort Il faut un protocole pour assurer que tous les sites dcident commit ou tous les sites dcident abort: protocole de validation atomique (atomic commitment ou AC) Problme: le LRM ne peut pas attendre de connatre la dcision commit avant dexcuter les actions locales lies au commit: Transaction qui accde un site S1 et un site S2 Les actions locales pour commit pas excutes linstant t1 La dcision est commit Le site S1 crashe linstant t1 Solution: le LRM doit crire le journal sur disque pour rendre commit possible (avant que le protocole de validation atomique ne dcide commit ou abort )SysRp Transactions-B A. Schiper Et 200722Spcification du problme AC Les processus doivent se mettre daccord sur une dcision commune La dcision est binaire: valider (commit) ou avorter La dcision est base sur une valeur initiale pour chaque processus La valeur initiale dun processus est oui (= valider) ounon (= avorter) La valeur initiale est appele le vote du processus.SysRp Transactions-B A. Schiper Et 200723Spcification du problme AC (2)Le problme AC est spcifi par les proprits suivantes: AC Agrment Uniforme: Deux processus (coordinateurs ou participants) ne peuvent dcider diffremment. AC Validit: Si un processus vote non, le dcision doit tre abort. Si tous les processus votent oui, et qu'il n'y a pas de dfaillance, la dcision doit tre commit. AC- Terminaison: Tous les processus doivent dcider.SysRp Transactions-B A. Schiper Et 200724Spcification du problme AC (3)Remarque: Un processus ne vote oui quaprs avoir crit dans le journal les informations rendant le commit local possible (puisque dans ce cas la dcision peut tre commit .SysRp Transactions-B A. Schiper Et 200725Validation atomiqueDeux protocoles: 2PC (2 Phase Commit) 3PC (3 Phase Commit) 2PC est un protocole bloquant: le crash dun processus p peut empcher le protocole de se terminer avant le recouvrement de p 3PC est un protocole non bloquant Pour linstant on ne discute que le protocole 2PC Le protocole (2PC ou 3PC) est initi par le TM (Transaction Manager), appel aussi coordinateur du protocole. Le TM demande le vote des autres processus (appels participants).SysRp Transactions-B A. Schiper Et 200726Algorithme 2PCDeux phases: phase de vote phase de dcisioncoordinateurparticipantparticipantvote-reqvote (yes/no)commit / abortackSysRp Transactions-B A. Schiper Et 2007272PC: protocole du coordinateurwrite begin-commit to the logsend vote-req to the participantsif all votes are received and all votes are yes thenwrite commit to the logsend commit to the participantselsewrite abort to the logsend abort to the participantswait for the ack from the participantswrite end-of-transaction to the logSysRp Transactions-B A. Schiper Et 2007282PC: protocole dun participantupon reception ofvote-req doif participant is ready to commit thenexecute LRM actions tomake later commit possiblewrite ready to the log send yes to the coordinatorelsewrite abort to the log send no to the coordinatorwait for the decision messageif the decision is commit thenwrite commit to the logsend ack to the coordinatorperform local commit processingelsewrite abort to the logsend ack to the coordinatorperform local abort processingSysRp Transactions-B A. Schiper Et 200729Dfaillances Un crash peut empcher le protocole de se terminer On distingue Protocole de terminaison: protocole excut par un processus en attente dun message Exemple: un participant attend la dcision du coordinateur. Si time-out expire, protocole de terminaison excut Protocole de recovery: protocole excut par un processus p lors du recouvrement de p aprs un crash.SysRp Transactions-B A. Schiper Et 200730Exemple de protocole de terminaisonupon reception ofvote-req doif participant is ready to commit thenexecute LRM actions tomake later commit possiblewrite ready to the log; send yes to the coordinatorelsewrite abort to the log; send no to the coordinatorwait for the decision messageAprs expiration du time-out: Contacter un autre participant Si un participant contact a vot no, alors la dcision est abort Si un partiticpant contact a dcidcommit, alors la dcision estcommitSysRp Transactions-B A. Schiper Et 200731Exemple de protocole de recoveryProcessus pirecouvre aprs un crash: Aucun enregistrement ready dans son log: Pas de vote envoy pipeut dcider abort ready mais pas commit / abort dans le log Identique au cas dune attente de la dcision du coordinateur pipeut utiliser le protocole de terminaisonSysRp Transactions-B A. Schiper Et 200732Variantes du 2PC Optimisations permettant de rduire le nombre de messages et le nombre d'enregistrements crits dans le journal. Les deux variantes sont lies au message ack.SysRp Transactions-B A. Schiper Et 200733Presumed Abort 2PC. Principe: lorsqu'un participant recouvre, et contacte le coordinateur, si celui-ci ne trouve aucune information propos de la dcision, le coordinateur rpond abort. Modification par rapport au 2PC: Si la dcision est abort, le coordinateur n'attend pas les messages ack, et n'crit pas abort dans son journal. Si la dcision est abort, un participant n'envoie dans de ack au coordinateurSysRp Transactions-B A. Schiper Et 200734Presumed Commit 2PC. Le protocole presumed abort optimise le cas du abort. Il est plus logique d'optimiser le cas du commit (qui est en principe plus frquent). C'est ce que fait le protocole presumed commit 2PC. Le protocole presumed commit est lgrement plus compliqu que le protocole presumed abort.