Gestione delle transazioni
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.
à
Gestione delle transazioni
pag.1
Il frammento di programma in ambiente DB2 per la
transazione in esame è:
à
EXEC SQL
UNDO;
WHENEVER
SQLERROR
GOTO
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.
à
Gestione delle transazioni
pag.2
¨
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.
¨
Gestione delle transazioni
pag.3
¨
Stati di una transazione
c omm it
eseg uit a
r ea d/wr it e
t er mi na t a
en d
t r an sac t io n
a t t iv a
abo r t
fa llit a
beg in
t r a n sac t io n
¨
a livello sintattico
sintassi non standard
ANSI standard
BEGIN TRANSACTION
statement;
statement;
statement;
statement;
.........
END TRANSACTION
Gestione delle transazioni
.........
COMMIT
pag.4
a bor t it a
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)
Gestione delle transazioni
pag.5
¨
¨
¨
¨
¨
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.
Gestione delle transazioni
pag.6
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)
Eventi per una operazione di lettura
(scrittura)
1
DBMS
Pr ogr am ma
Sta to
Ar ea di
la vor o
2
6
Sc h ema
E ster no
3
Sc hem a
L ogic o
5
Sistem a
Oper ativo
Sc hema
F isic o
4
B uffer
Gestione delle transazioni
B a se di dati
pag.7
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.
Gestione delle transazioni
pag.8
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.
Gestione delle transazioni
pag.9
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.
Gestione delle transazioni
pag.10
¨
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
transaction
abort
system abort
Frequenza
system crash
alcuni all'anno
Gestione delle transazioni
alcuni
al minuto
alcuni al mese
pag.11
Tempo
di ripristino
millisecondi
secondi
minuti
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.
Gestione delle transazioni
pag.12
à
Lost Update Problem
Transaction A
read R
Time
t1
t2
update R
commit
Transaction B
read R
t3
t4
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.
à
Gestione delle transazioni
pag.13
à
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
t1
read R
update R
t2
t3
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.
Gestione delle transazioni
pag.14
Un altro esempio di questo tipo con conseguenze più
gravi:
à
Transaction A
Time
Transaction B
t0
t1
update R
update R
t2
t3
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.
à
Gestione delle transazioni
pag.15
à
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 $
Transaction A
read ACC1
ACC2=5000 $
Time
ACC3=3000 $
Transaction B
t1
sum = 4000
read ACC2
t2
sum = 9000
t3
read ACC3
t4
update ACC3
3000-->2000
read ACC1
t5
t6
update ACC1
4000-->5000
commit
t7
read ACC3
t8
sum = 11000
Gestione delle transazioni
pag.16
La transazione A opera un'analisi inconsistente dei
dati e fornisce come risultato 11000 $ in luogo di 12000 $.
à
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.
Gestione delle transazioni
pag.17
Modello per la gestione delle transazioni
T1
Tn
T
2
Tr ansac tion
Man a ger
Sc hed uler
Rest a r t
Da t a Ma na ger
Rec over y
Ma nager
B uffe r
Ma na ge r
St a ble Stor age
DB
DB
c opy
Vola tile Stor age
DB B uffer
page
Log B u ffer
Log
Gestione delle transazioni
pag.18
¨
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;
¨
Gestione delle transazioni
pag.19
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
read Acc
Time
t1
t2
read Acc
t3
update Acc
t4
commit
update Acc
t5
commit
t6
Gestione delle transazioni
Transaction B
pag.20
à
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.
Gestione delle transazioni
pag.21
¨
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.
Gestione delle transazioni
pag.22
¨
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.
Gestione delle transazioni
pag.23
¨
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
Gestione delle transazioni
pag.24
¨
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.
Gestione delle transazioni
pag.25
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).
Gestione delle transazioni
pag.26
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
(DUPLEXING)
Gestione delle transazioni
e'
pag.27
duplicato
su
disco
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.
Gestione delle transazioni
pag.28
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.
Gestione delle transazioni
pag.29
Ripresa da malfunzionamenti
à
fallimenti di transazioni
si scrive sul log (T, abort) e si fa
della transazione T
à
UNDO
fallimenti di sistema
si attiva restart che:
•
riporta la base di dati allo stato corretto
esistente prima del malfunzionamento;
•
segnala al gestore delle transazioni
fallimento di alcune transazioni;
il
•
riprende il funzionamento del
sistema
à
fallimenti hardware
•
di dati;
si carica la dump più recente della
•
si ricostruisce la copia corretta più
dei
dati
usando
il
Gestione delle transazioni
pag.30
base
recente
log.
Esempio di ripristino dopo fallimento di
sistema
t1
t2
t3
t4
t5
S1
S0
S2
S0
Stato iniziale
S1
Stato al punto di allineamento
S2
Stato al tempo di malfunzionamento
S3
Stato in assenza di malfunzionamento
S3
à
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.
Gestione delle transazioni
pag.31
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:
•
operazioni a livello di record
•
una transazione in richiesta di lock aspetta. Se
raggiunge un tempo di attesa massimo fallisce.
X
S
—
S (Shared) e X (eXclusive)
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à
Gestione delle transazioni
pag.32
•
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)
wait
wait
wait
wait
wait
wait
time
transaction B
—
—
—
—
—
FETCH R
(acquire S lock on R)
—
—
—
—
UPDATE R
(request X lock on R)
wait
wait
wait
t1
t2
t3
t4
non si perde nessuna modifica, ma si verifica
DEADLOCK al tempo t4
UNCOMMITTED DEPENDENCY PROBLEM
Gestione delle transazioni
pag.33
transaction A
—
—
—
—
—
FETCH R
(request S lock on
R)
wait
wait
wait
resume: FETCH R
(acquire S lock on
R)
—
time
transaction B
—
—
UPDATE R
(acquire X lock on
R)
—
—
—
—
synchpoint
(release X lock on
R)
t1
t2
t3
t4
Alla transazione A viene impedito di vedere il record
cambiato al tempo t2 fino a quando B non fa commit o
rollback (t3 )
Gestione delle transazioni
pag.34
UNCOMMITTED DEPENDENCY PROBLEM
transaction A
—
—
—
—
—
UPDATE R
(request X lock on
R)
wait
wait
wait
resume: UPDATE R
(acquire X lock on
R)
—
time
transaction B
—
—
UPDATE R
(acquire X lock on
R)
—
—
—
—
synchpoint
(release X lock on
R)
t1
t2
t3
t4
Alla transazione A viene impedito di fare un update fino a
quando B non ha raggiunto un synchpoint (t3)
Gestione delle transazioni
pag.35
The inconsistent analysis problem
ACC1=4000 $
ACC2=5000 $
Transaction A
Time
FETCH
ACC1(4000)
(acquire S lock on ACC1)
:sum = 4000
t1
FETCH
ACC1(5000)
(acquire S lock on ACC2)
:sum = 9000
t2
Transaction B
t3
FETCH
ACC3(3000)
(acquire S lock on ACC3)
:
t4
update ACC3
3000-->2000
(acquire X lock on ACC3):
3000 - > 2000
FETCH
ACC1(3000)
(acquire S lock on ACC1)
:
t5
t6
fetch ACC1
(request S lock on ACC3):
wait
wait
ACC3=3000 $
t7
update ACC1
4000-->5000
(request X lock on ACC1):
wait
wait
wait
wait
wait
wait
L'inconsistenza è impedita, ma il deadlock si verifica al tempo t7
Gestione delle transazioni
pag.36
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
wait
wait
wait
wait
time
t1
t2
t3
t4
transaction B
—
—
—
—
LOCK R2 IN X MODE
—
—
—
LOCK R1 IN X MODE
wait
wait
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;
Gestione delle transazioni
pag.37
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
Gestione delle transazioni
pag.38
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
Gestione delle transazioni
pag.39
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
Gestione delle transazioni
pag.40
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;
Gestione delle transazioni
pag.41
•
e)
se ha ricevuto commit da tutte in tempo utile
registra commit sul log e invia il messaggio
"commit" a tutti i partecipanti
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
Gestione delle transazioni
®
pag.42
abort globale
b)
dopo precommit
C e decisione
®
richiesta al coordinatore
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
Gestione delle transazioni
pag.43
