Gestione delle transazioni

Transcript

1 Concetto di transazione Una transazione è vista come un'unità logica di elaborazione : per consentire transazioni concorrenti e per garantire la base di dati da malfunzionamenti sono necessari opportuni moduli di gestione. Un esempio : PARTI(PAR#,GIACENZA,...) ORDINI(ORD#,FOR#,PAR#,QUANT) vincolo di integrità : per una parte PAR# nella relazione PARTI, il valore GIACENZA deve essere pari alla somma delle quantità QUANT ordinate per quella parte nella relazione ORDINI. Si consideri la sequenza di operazioni per aggiungere un nuovo ordine : ('AZ007','F5','P6',1000) La transazione deve operare un aggiornamento sia della relazione ORDINI sia della relazione PARTI. pag.1

2 Il frammento di programma in ambiente DB2 per la transazione in esame è: EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL INSERT INTO ORDINI(ORD#,FOR#,PAR#,QUANT) VALUES ('AZ007','F5','P6',1000); EXEC SQL UPDATE PARTI SET GIACENZA=GIACENZA+1000 WHERE PAR#='P6'; EXEC SQL COMMIT; GOTO FINISH; UNDO : EXEC SQL ROLLBACK; FINISH : RETURN; Se uno dei due aggiornamenti non venisse eseguito il database si troverebbe in uno stato inconsistente. Il gestore delle transazioni (transaction manager) deve pertanto garantire che la transazione sia considerata atomica anche se in realtà è composta da più operazioni. pag.2

3 commit : segnala al transaction manager che la transazione è andata a buon fine e richiede che gli effetti prodotti sul database vengano resi permanenti. rollback (abort) : segnala che si è verificato qualche problema durante l'esecuzione e che il database può essere in uno stato inconsistente; si devono dunque attivare opportune procedure per annullare gli effetti prodotti e riportare il database in uno stato consistente (UNDO). Per gestire in modo corretto le conseguenze derivanti da una transazione che abortisce, il DBMS gestisce un log dove vengono memorizzati dettagli circa le operazioni di aggiornamento effettuate (in particolare vengono gestiti before values e after values). In generale si definisce before image lo stato del database prima di una modifica e after image lo stato raggiunto dopo aver effettuato la modifica. Nello stesso modo sono gestiti i comandi SQL che sono set_level: ogni comando interattivo SQL è visto come una transazione. pag.3

4 Stati di una transazione rea d/wr ite eseguita c omm it termina ta end tr ansac tion a ttiva begin tra nsac tion fa llita abort a bor tita a livello sintattico sintassi non standard ANSI standard BEGIN TRANSACTION statement; statement; statement; statement; END TRANSACTION COMMIT pag.4

5 Definizioni Azione: operazione di lettura (r[x]) o scrittura (w[x]) sulla base di dati. Stato consistente: stato che soddisfa tutti i vincoli di integrità. Stato corretto: stato consistente e coerente con una situazione ammissibile della realtà. Transazione: una sequenza di operazioni sulla base di dati e di operazioni in memoria temporanea con le seguenti proprietà: atomicità correttezza isolamento serializzabilità persistenza proprieta` ACID (Atomicity Consistency Isolation Durability) pag.5

6 atomicità: solo le committed transactions fanno transitare la base di dati in un nuovo stato corretto. Le aborted transactions sono trattate dal sistema come se non fossero mai state avviate. correttezza/consistenza: una transazione eseguita isolatamente porta la base di dati da uno stato corretto in un stato corretto. isolamento: le modifiche sulla base di dati fatte da una transazione T sono visibili da altre transazioni solo dopo la terminazione di T. serializzabilità: l'effetto sulla base di dati di esecuzioni concorrenti di più transazioni è equivalente a una esecuzione seriale delle transazioni, cioè ad un'esecuzione in cui le transazioni vengono eseguite una dopo l'altra in un qualche ordine. persistenza: gli effetti sulla base di dati prodotti da una transazione terminata con successo sono permanenti, ovvero non sono alterati da eventuali malfunzionamenti. pag.6

7 Modello di un DBMS Si considerano per una transazione Ti soltanto le seguenti operazioni : ri[x] : legge dalla base di dati un dato x e copia il valore in una variabile di programma che per semplicità ha lo stesso nome x. wi[x] : copia il contenuto di una variabile x di programma nella base di dati. ci : commit. ai : abort (rollback) Programma Sta to Area di la voro Eventi per una operazione di lettura (scrittura) DBMS Sistema Operativo Sc hema E sterno Sc hema Logico Sc hema F isic o Buffer Ba se di dati pag.7

8 Esecuzione di una istruzione di lettura r[x] 1. il programma chiede al sistema di leggere il dato x; 2. il DBMS consulta lo schema esterno, lo schema logico e quello fisico per reperire il dato; 3. il DBMS chiede al sistema operativo di trasferire la pagina che contiene il dato x; 4. il sistema operativo copia la pagina dati nel buffer, se non e gia presente; 5. il DBMS copia il dato x dal buffer nella variabile x secondo la struttura definita nello schema esterno; 6. Il DBMS comunica al programma l informazione sullo stato dell operazione. pag.8

9 Esecuzione di una istruzione di scrittura w[x] 1. il programma chiede al sistema di scrivere il dato x; 2. il DBMS consulta lo schema esterno, lo schema logico e quello fisico per individuare il dato; 3. il DBMS chiede al sistema operativo di trasferire la pagina che dovra contenere il dato x; 4. il sistema operativo copia la pagina dati nel buffer, se non e gia presente; 5. il DBMS copia il valore del dato x nella pagina del buffer secondo la struttura definita nello schema logico e poi chiede al sistema operativo di copiare nella memoria permanente la pagina modificata nel buffer. Questa operazione puo essere eseguita immediatamente o differita. 6. il DBMS comunica al programma l informazione sullo stato dell operazione. pag.9

10 Malfunzionamenti Si distinguono tre tipi di anomalie di funzionamento: transaction abort interruzione di una transazione che non comporta perdita di dati in memoria temporanea o permanente. Puo' essere causata da una situazione prevista dal programma (esempio : violazione vincoli di integrità, tentativo di accesso a dati protetti) o rilevata dal gestore (deadlock). system abort interruzione di transazioni attive derivante da un'anomalia hardware o software dell'unità centrale o di una periferica (un esempio tipico è l'interruzione dell'alimentazione elettrica). Si assume che il contenuto della memoria permanente sopravviva, mentre si considera perso il contenuto della memoria temporanea. pag.10

11 system crash anomalia che danneggia la memoria permanente (esempi : errori umani, rottura di dischi). Si assume che un malfunzionamento sia sempre rilevato da parte del DBMS e che comporti: l'interruzione istantanea di una o più transazioni o dell'intero sistema a seconda del tipo di anomalia riscontrata; l'attivazione di procedure di recovery atte a ripristinare la base di dati in uno stato corretto. Tipo di anomalia Frequenza Tempo di ripristino transaction alcuni millisecondi abort al minuto system abort alcuni al mese secondi system crash alcuni all'anno minuti pag.11

12 Quando un database è condiviso fra più utenti l'interferenza tra le transazioni concorrenti può provocare inconsistenze. In assenza di un gestore, dedicato al controllo della concorrenza e alla schedulazione corretta delle operazioni, possono insorgere problemi che rientrano essenzialmente nelle seguenti tre categorie: Lost Update Problem : perdita di modifiche da parte di una transazione a causa di un aggiornamento effettuato da un'altra; Uncommitted Dependency Problem : dipendenza di una transazione da un'altra non completata con successo; Inconsistency Analysis Problem : analisi inconsistente di dati da parte di una transazione causata da aggiornamenti prodotti da un'altra. pag.12

13 Lost Update Problem Transaction A Time Transaction B read R update R commit t1 t2 t3 t4 read R update R commit La transazione A perde al tempo t4 l'aggiornamento effettuato al tempo t3, visto che B modifica nuovamente il valore senza sapere che quello osservato al tempo t2 non è più valido al tempo t4. pag.13

14 Uncommitted Dependency Problem (dirty read) Accade quando viene concesso a una transazione di accedere a un dato (e peggio ancora modificarne il valore) che è stato aggiornato da un'altra transazione non ancora completata con successo. Transaction A Time Transaction B t0 read R t1 t2 t3 update R rollback La transazione A vede un valore di R al tempo t2, valore che non esiste di fatto in quanto verrà sostituito al tempo t3 con il valore che era valido al tempo t0. Si noti che il rollback da parte di B può essere dovuto ad una caduta del sistema : ciò implica che alla ripartenza, se A era stata completata con successo, il rollback interesserà solo B e non A. pag.14

15 Un altro esempio di questo tipo con conseguenze più gravi: Transaction A Time Transaction B t0 update R t1 t2 t3 update R rollback Non solo la transazione A dipende dall'insuccesso della transazione B ma perde anche le modifiche fatte al tempo t2 a causa del rollback che interesserà B al tempo t3. Si tratta dunque di un'altra versione del lost update problem. pag.15

16 Inconsistent Analysis Problem Si consideri il caso in cui due transazioni A e B operino su record relativi a conti bancari. A vuole sommare gli importi dei vari conti di un cliente, mentre B vuole trasferire un importo di 1000 $ dal conto ACC3 al conto ACC1. ACC1=4000 $ ACC2=5000 $ ACC3=3000 $ Transaction A Time Transaction B read ACC1 sum = 4000 read ACC2 sum = 9000 read ACC3 sum = t1 t2 t3 t4 t5 t6 t7 t8 read ACC3 update ACC >2000 read ACC1 update ACC >5000 commit pag.16

17 La transazione A opera un'analisi inconsistente dei dati e fornisce come risultato $ in luogo di $. Se questo dato fosse memorizzato in modo permanente nel database verrebbe violato il vincolo che la somma dei conti deve restare costante in caso di trasferimento di denaro da un conto all'altro dello stesso cliente. In questo caso non si tratta di una dipendenza di A da un insuccesso di B, in quanto quest'ultima ha eseguito commit con successo. Gli esempi visti suggeriscono : fondamentale per ogni processo di aggiornamento è il concetto di transazione come unità logica di elaborazione, che deve poter essere annullata se necessario per ripristinare il database in uno stato consistente; la gestione delle transazioni non può essere affidata direttamente dell'utente; le transazioni variano in termini di complessità, frequenza di esecuzione e criticità, tuttavia in ogni caso devono essere viste come atomiche. pag.17

18 Modello per la gestione delle transazioni T 1 T 2 T n Tr ansac tion Mana ger Resta rt Sc heduler Rec overy Ma nager Da ta Ma na ger Buffe r Ma na ge r Sta ble Storage Vola tile Storage DB DB c opy page DB Buffer Log Log Buffer pag.18

19 Transaction Manager Controlla l'esecuzione delle transazioni ricevendo le richieste di begin transaction, end transaction, le richieste di accesso ai dati, i comandi commit e abort. Le richieste vengono poi inoltrate allo scheduler. In un sistema distribuito il Transaction Manager è anche responsabile di decidere in quali siti si deve procedere all'esecuzione. Scheduler Garantisce che l'esecuzione concorrente delle transazioni sia equivalente a una esecuzione seriale delle stesse e sia ripristinabile (recoverability). Ciò implica restringere l'ordine in cui il Data Manager può eseguire read, write, commit e abort delle transazioni. Dopo aver ricevuto una richiesta lo Scheduler prende una delle seguenti decisioni: execute passa il controllo al Data Manager che esegue l'operazione e informa lo Scheduler dello stato raggiunto; in caso di read il valore viene passato allo Scheduler che a sua volta lo restituisce alla transazione; pag.19

20 reject la richesta viene rifiutata e comporta un abort per la transazione che verrà gestito dal Transaction Manager; delay la richesta viene accodata. Si consideri come esempio l'esecuzione concorrente di due transazioni di deposito di una somma su un medesimo conto corrente Acc: Transaction A Time Transaction B read Acc update Acc commit t1 t2 t3 t4 t5 t6 read Acc update Acc commit pag.20

21 Per evitare questa esecuzione non corretta lo scheduler può : a) impedire alla transazione A di eseguire l'operazione update, facendola dunque fallire; in questo caso l'utente potrà riprovare in un altro momento senza interferire con B. b) impedire alla transazione B di eseguire l'update, facendo abortire B. c) ritardare la richiesta read di B fino al completamento di A. d) ritardare sia l'update di A sia l'update di B causando un deadlock, e poi decidere alla rilevazione della situazione di stallo quale delle due transazioni far fallire. pag.21

22 Data Manager E' il modulo del sistema che esegue le operazioni trasmesse dallo scheduler e dal comando restart generato dal sistema operativo dopo un fallimento del sistema, garantendo che la base di dati contenga solo gli effetti delle transazioni terminate normalmente. Dopo ogni operazione eseguita dal Data Manager, e' previsto che invii allo scheduler un segnale di fine operazione (aknowledgment). Inoltre se l' operazione e' di read, restituisce il valore richiesto che viene poi traferito alla transazione. La memoria e' divisa in permanente e temporanea (buffer). Il dato trasferito fra il buffer e la memoria permanente e' di solito una pagina data, mentre il record manager scambia di solito con il resto del sistema un record. Infine il data manager prevede un modulo per il ripristino dei malfunzionamenti (recovery manager) che fa uso di algoritmi basati su UNDO e REDO. pag.22

23 Buffer Manager Si occupa della gestione di buffer di memoria volatile; opera in concomitanza con il Recovery Manager. Fa uso di opportune tecniche per gestire in modo efficiente la condivisione dei buffer da parte di più transazioni concorrenti. Tecniche di Recovery e Recovery Manager Def: Il recovery e' l'operazione che riporta la base di dati ad un precedente stato corretto dopo che un malfunzionamento ne ha reso incerto lo stato attuale. Il Recovery Manager garantisce che il database memorizzi in modo persistente solo gli effetti prodotti dalle transazioni che hanno eseguito con successo l'operazione commit. Deve dunque fornire supporto per le operazioni di start, commit, abort, read e write. Il Recovery Manager provvede al ripristino del database in caso di malfunzionamenti: in caso di caduta di sistema si occupa di annullare gli effetti prodotti da transazioni ancora attive al momento del guasto. Al fine di garantire un grado di resilienza accettabile in caso di guasti ai dispositivi di memoria di massa (media failures) il Recovery Manager mantiene copia aggiornata del database o di porzioni di esso. Il Recovery Manager usa i log file e copie di backup dei dati (database dump) per fornire la duplicazione dei dati necessaria all'attivita' di recovery. pag.23

24 Data Base Dump (periodico) 1. rifiuta attivazione nuove transazioni 2. attende completamento transazioni attive 3. forza la scrittura nelle basi di dati stabili e nel log file delle pagine ancora presenti nella memoria temporanea 4. scrive la marca DUMP sul log 5. fa una copia della base di dati pag.24

25 Uso del Log file Durante l'uso della base di dati, il sistema registra nel log la storia delle azioni effettuate dal momento in cui di essa e' stata fatta l'ultima copia (dump). Il log memorizza entita' logiche (tuple e attributi); entita' fisiche cioe' pagine dati; cambiamenti di stato : vecchi valori di dati, nuovi valori di dati o operazioni (transazioni e parametri). E' un file sequenziale di sistema che contiene la before image e la after image delle pagine modificate in ordine di tempo, marcate con gli identificatori delle transazioni che le hanno modificate e contenenti i record dei begin transaction, commit e abort. Before image = pagina dati prima di una operazione di update. After image = pagina dati dopo una operazione di update. Solitamente e' memorizzato in un'area separata di disco rispetto ai dati. Per maggiore sicurezza normalmente ce sono due o tre copie. pag.25

26 Problema : un sistema reale puo' generare 200 milioni di bytes di log data al giorno e quindi non puo' essere tenuto tutto in linea. Per questo solitamente si ha un active log ed il Log Manager fa il dump del log su nastro quando il log e' pieno. una pagina di log è trasferita dal buffer alla memoria secondaria solo quando è completamente piena, cio' comporta che gli algoritmi di gestione delle transazioni debbano forzare alcune volte la scrittura delle pagine di log sulla memoria secondaria. Una ulteriore informazione memorizzata nel log e' il cosiddetto checkpoint record (record di allineamento). Il checkchpoint e' un allineamento del log ad uno stato corretto della base di dati relativamente ad un punto di allineamento (synchpoint). Il synchpoint puo' essere attivato ad intervalli fissati di tempo o dopo che sono state scritte un certo numero di registrazioni sul log oppure dietro esplicita richiesta dell'operatore. Possibile compressione del Log: vengono eliminati i log record delle transazioni che hanno fatto rollback e di quelli che hanno fatto commit al (punto di allineamento). pag.26

27 Recovery = redundancy 1. una volta al giorno l'intero database viene dumped (tipicamente su nastro) 2. tutte le volte che viene fatta una modifica di un record nel database, sul file di log viene scritto un record con il vecchio valore ed il nuovo valore In caso di guasto: Se il guasto e' sul disco viene ripristinato il database dal DUMP e viene usati il file di log per rifare (REDO) tutte le modifiche fatte fino al momento del guasto; Se (caso piu' fortunato) e' una singola transazione che e' terminata in modo anomalo (senza raggiungere il COMMIT) il database e' riportato ad uno stato corretto precedente la transazione usando il log per disfare (UNDO) le modifiche eventualmente non completate dalla transazione. Spesso il database e' duplicato su disco (DUPLEXING) pag.27

28 System checkpoints Per ridurre la dimensione dei dati da ripristinare dopo un malfunzionamento, quando si raggiunge il synchpoint vengono effettuate alcune azioni per garantire il ripristino: viene memorizzato nel log il checkpoint record (CKP) contenente la lista di tutte le transazioni attive in quell'istante e viene effettuata la scrittura forzata dei buffer di log e del database, cioe' il trasferimento in memoria secondaria del contenuto dei buffer (anche se non sono pieni). La lista delle azioni per garantire il ripristino e' la seguente: Passo 1: forza la scrittura del log buffer; Passo 2: scrive sul log il checkpoint record; Passo 3: forza la scrittura dei buffer di Passo4: scrive l' indirizzo del checkpoint nel log file su restart file. database; record I passi 1 e 2 sono fatti in base al protocollo write-ahead log, cioe' prima di poter fare una modifica nel database va scritto il valore del vecchio dato sul log file, per potere effettuare l'undo se richiesto. Il passo 3 serve per non dover rifare il lavoro che e' gia' stato fatto prima del synchpoint. pag.28

29 Restart procedure: procedure di sistema eseguite al tempo di restart per ricostruire il piu' recente stato consistente di un database. Sono basate sul log, su backup di linea ed eventualmente su nastri. al tempo di restart il Recovery Manager ottiene dal file di restart l' indirizzo del piu' recente checkpoint record e poi scandisce il file di log per cercare le transazione che devono essere disfatte (undo) e quello che devono essere rifatte (redo): viene fatto UNDO delle transazioni che non hanno raggiunto il commit prima del fallimento; viene fatto REDO delle transazioni che hanno raggiunto il commit dopo il synchpoint perche' non e' garantito che gli update siano su memoria secondaria. pag.29

30 Ripresa da malfunzionamenti fallimenti di transazioni - si scrive sul log (T, abort) e si fa UNDO della transazione T fallimenti di sistema si attiva restart che: riporta la base di dati allo stato corretto esistente prima del malfunzionamento; segnala al gestore delle transazioni il fallimento di alcune transazioni; riprende il funzionamento del sistema fallimenti hardware si carica la dump più recente della base di dati; si ricostruisce la copia corretta più recente dei dati usando il log. pag.30

31 Esempio di ripristino dopo fallimento di sistema t1 t2 t4 t3 t5 S 0 S 0 S 1 S 2 S 3 S 1 S 2 S 3 Stato iniziale Stato al punto di allineamento Stato al tempo di malfunzionamento Stato in assenza di malfunzionamento Le transazioni t3 e t5 devono essere disfatte, perche' scandendo il log a partire dal checkpoint record (CKP, {t2,t3}) non si trovano le registrazioni (t3,commit) e (t5,commit). t2 e t4 devono essere rifatte qualora si adotti il commit anticipato (cio' si scrive commit prima di forzare la scruttura). La transazioni t1 va ignorata perche' le modifiche da essa apportate sono state rese presistenti al tempo S1. pag.31

32 Come DB2 risolve i 3 problemi di concorrenza DB2 utilizza la tecnica del locking granularità del locking tipica è un record del database (fisicamente il locking è sulla pagina) due tipi di lock: S (Shared) e X (exclusive) operazioni a livello di record una transazione in richiesta di lock aspetta. Se raggiunge un tempo di attesa massimo fallisce. X S X N N Y S N Y Y Y Y Y matrice (X, S) di compatibilità dei tipi di lock N indica conflitto Y indica compatibiltà pag.32

33 le richieste di lock sono sempre implicite: se una transazione fa un update acquisisce automaticamente un X lock tutti i lock sono mantenuti fino al prossimo synchpoint che è stabilito ad inizio programma, commit e rollback LOST UPDATE PROBLEM transaction A FETCH R (acquire S lock on R) UPDATE R (request X lock on R) time t1 t2 t3 t4 transaction B FETCH R (acquire S lock on R) UPDATE R (request X lock on R) non si perde nessuna modifica, ma si verifica DEADLOCK al tempo t4 UNCOMMITTED DEPENDENCY PROBLEM pag.33

34 transaction A FETCH R (request S lock on R) resume: FETCH R (acquire S lock on R) time t1 t2 t3 t4 transaction B UPDATE R (acquire X lock on R) synchpoint (release X lock on R) Alla transazione A viene impedito di vedere il record cambiato al tempo t2 fino a quando B non fa commit o rollback (t3 ) pag.34

35 UNCOMMITTED DEPENDENCY PROBLEM transaction A UPDATE R (request X lock on R) resume: UPDATE R (acquire X lock on R) time t1 t2 t3 t4 transaction B UPDATE R (acquire X lock on R) synchpoint (release X lock on R) Alla transazione A viene impedito di fare un update fino a quando B non ha raggiunto un synchpoint (t3) pag.35

36 The inconsistent analysis problem ACC1=4000 $ ACC2=5000 $ ACC3=3000 $ Transaction A Time Transaction B FETCH ACC1(4000) (acquire S lock on ACC1) :sum = 4000 FETCH ACC1(5000) (acquire S lock on ACC2) :sum = 9000 t1 t2 t3 FETCH ACC3(3000) (acquire S lock on ACC3) : t4 update ACC >2000 (acquire X lock on ACC3): > 2000 t5 FETCH ACC1(3000) (acquire S lock on ACC1) : fetch ACC1 (request S lock on ACC3): t6 t7 update ACC >5000 (request X lock on ACC1): L'inconsistenza è impedita, ma il deadlock si verifica al tempo t7 pag.36

37 In generale ogni operazione che richiede lock può ricevere di ritorno un codice di errore che indica che si è verificato deadlock e che la transazione è stata scelta come vittima. DEADLOCK transaction A LOCK R1 IN X MODE LOCK R2 IN X MODE time t1 t2 t3 t4 transaction B LOCK R2 IN X MODE LOCK R1 IN X MODE Un esempio di deadlock EXEC SQL... IF SQLCODE = value indicating "deadlock victim" then DO ; EXEC SQL ROLLBACK; reinitialize variables from initial input data; GO TO beginning of program; END; pag.37

38 Transazioni distribuite Def: Una transazione e' distribuita quando e' costituita da sottotransazioni eseguite concorrentemente da processi diversi. Nel caso di DBMS distribuiti le sottotransazioni sono eseguite su nodi diversi di una rete. Il frammento di programma riportato descrive una transazione per trasferimento di fondi, nell' ipotesi che le due relazioni ContiCorrenti(Numero,Saldo) ContiRisparmi(Numero,Saldo) siano memorizzate in due nodi diversi della rete e che la transazione inizi nel nodo dove si trova la relazionecontirisparmi. La transazione distribuita viene eseguita come due processi che si scambiano messaggi. Process Coordinatore; var EXEC SQL begin declare section Ammontare, xsaldo: integer; Numero,DaConto,AConto: array[1..6] of char; EXEC SQL end declare section begin transaction begin writeln('scrivi Ammontare, Da quale conto, A quale conto'); read (Ammontare, DaConto, AConto); EXEC SQL pag.38

39 Select Saldo into :xsaldo from ContiRisparmi where Numero = :DaConto if xsaldo < Ammontare then begin writeln('saldo Insufficiente); ABORT; end end; else begin EXEC SQL UPDATE ContiRisparmi set Saldo=:xSaldo- :Ammontare where Numero = :DaConto; create Partecipante; send (Ammontare, AConto); COMMIT; end; end transaction; end Coordinatore; Process Partecipante; var EXEC SQL begin declare section Ammontare, xsaldo:integer; AConto: array[1..6] of char; EXEC SQL end declare section begin pag.39

40 receive (Ammontare, AConto) from Coordinatore; EXEC SQL UPDATE ContiCorrenti set Saldo = :xsaldo + :Ammontare where Numero = :AConto; if sqlcode = 0 then commit else abort end Partecipante pag.40

41 Transazioni distribuite Protocollo two-phase commit La terminazione di una transazione distribuita T avviene in due fasi: tutte le sottotransazioni Ti prendono una decisione comune sul modo di terminare vengono eseguite le operazioni corrispondenti alla decisione presa. coordinatore: a) prepara "precommit" sul log b) fissa un tempo max di attesa c) invia un messaggio "preparati" a tutti i partecipanti d) se scade il tempo max senza avere ricevuto pronto da tutte le transazioni, registra abort sul log e invia il messaggio "abort" a tutti i partecipanti; pag.41

42 se ha ricevuto commit da tutte in tempo utile registra commit sul log e invia il messaggio "commit" a tutti i partecipanti e) se riceve eseguito da tutti i partecipanti registra end commit sul log. Sottotransazione partecipante a) esegue le operazioni e rimane in attesa del messaggio "preparati" b) quando riceve "preparati" se può terminare registra sul log "pronto" e invia tale messaggio al coordinatore. Se non può terminare registra sul log "non pronto" e invia al coordinatore tale messaggio (fase di precommit) c) quando riceve dal coordinatore il messaggio "commit" o "abort" registra sul log il messaggio, esegue il comando e invia al coordinatore il messaggio "eseguito" (fase di commit) Fallimenti Fallimento nodo partecipante P a) prima di precommit abort globale pag.42

43 b) dopo precommit richiesta al coordinatore C e decisione coordinatore C a) fallisce tra precommit e commit. La procedura di ripristino riavvia il protocollo dall'inizio b) fallisce dopo aver registrato "commit" o "abort" e prima di "end commit" invia di nuovo il messaggio pag.43