1 Transazioni Distribuite

Transazioni Distribuite
Sistema distribuito con un insieme di serventi
Transazione distribuita: accede un insieme di oggetti gestiti da un
insieme di serventi che si coordinano per garantire lo stesso risultato
Atomicità
Controllo della concorrenza (locking, ottimistico, timestamp)
Protocollo di coordinamento fra i server
Two-phase commit
Stallo distribuito
piatta
Transazione distribuita
annidata - concorrenza nello stesso livello
Transazioni distribuite
(a) Transazione piatta
(b) Transazioni annidate
M
X
T11
X
Client
T
Y
T
T1
N
T 12
T
T
21
T2
Client
Y
P
Z
T
22
C13.2
1
Transazioni annidate: esempio
X
Client
A
a.withdraw(10)
B
b.withdraw(20)
T3
C
c deposit(10)
T
D
d.deposit(20)
T1
T
Y
T = openTransaction
openSubTransaction
a.withdraw(10);
openSubTransaction
b.withdraw(20);
openSubTransaction
c.deposit(10);
openSubTransaction
d.deposit(20);
closeTransaction
T2
Z
4
C13.3
Transazioni distribuite: esempio
join
openTransaction
closeTransaction
participant
A
.
a.withdraw(4);
join
BranchX
T
Client
participant
b.withdraw(T, 3);
T = openTransaction
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
closeTransaction
Nota: il coordinatore è uno dei serventi, es. BranchX
B
join
b.withdraw(3);
BranchY
participant
C
c.deposit(4);
D
d.deposit(3);
BranchZ
C13.4
2
Atomicità: protocolli
Atomicità in transazioni distribuite:
gestire le richieste all’insieme di serventi e il loro coordinamento
Protocolli
One phase commit
Il coordinatore informa tutti iI partecipanti dell’esito (commit/abort) e si pone in attesa
dell’ack
Ripete l’operazione fino al completamento
Svantaggi:se il cliente esegue commit, non permette ad un server di fare abort se
necessario; non permette al coordinatore di rilevare possibili guasti del server
Two phase commit
Tutti I partecipanti possono fare abort. Il cliente chiede al coordinatore di eseguire la
commit e viene attivato il protocollo two phase commit
Fase 1 - votazione (il coordinatore chiede se tutti sono pronti al commit)
Fase 2 - decisione (cominica il commit solo se tutti sono pronti)
Tutti devono votare e occorre raggiungere un accordo (protocollo di consenso) con
certezza anche in caso di guasti
C13.5
Operazioni per il protocollo two-phase commit
canCommit?(trans)-> Yes / No
Chiamata da coordinatore a partecipante per chiedere se può eseguire commit.
Il partecipante risponde con il voto.
doCommit(trans)
Chiamata da coordinatore a partecipante per dire al partecipante di eseguire il
commit della sua parte di transazione.
doAbort(trans)
Chiamata da coordinatore a partecipante per dire al partecipante di eseguire abort
della sua parte di transazione.
haveCommitted(trans, participant)
Chiamata da partecipante a coordinatore per confermare il commit della transazione.
getDecision(trans) -> Yes / No
Chiamata da partecipante a coordinatore per sapere della decisione su una
transazione dopo un voto positivo Yes ma senza aver ottenuto risposta dopo un certo
tempo. Usato per recupero dello stato da un guasto del servente o a causa di ritardi di
trasmissione.
C13.6
3
Protocollo two-phase commit
Fase 1 (votazione):
1. Il coordinatore invia una richiesta canCommit? ad ogni partecipante alla
transazione.
2. Quando un partecipante riceve una richiesta canCommit? risponde con il suo voto
(Yes o No) al coordinatore. Prima di votare Yes, si prepara al commit salvando gli
oggetti in memoria permanente. Se vota No il partecipante esegue la abort
immediatamente.
Phase 2 (completamento dell’accordo per il voto):
3. Il coordinatore raccoglie i voti (incluso il proprio).
(a) In assenza di guasti e se tutti i voti sono Yes il coordinatore decide di
eseguire commit della transazione e invia una richiesta di doCommit ad
ogni partecipante.
(b) Altrimenti il coordinatore decide una abort della transazione e invia una
richiesta di doAbort a tutti i partecipanti che hanno votato Yes.
4. I partecipanti che hanno votato Yes aspettano una richiesta di doCommit o doAbort
dal coordinatore. Quando un partecipante riceve uno di questi messaggi esegue
quanto richiesto e nel caso della commit, esegue una chiamata haveCommitted di
conferma al coordinatore.
C13.7
Comunicazione nel protocollo two-phase commit
Coordinatore
Partecipante
passi stato
1
3
prepared to commit
(waiting for votes)
committed
passi stato
canCommit?
Yes
2
prepared to commit
(uncertain)
4
committed
doCommit
haveCommitted
done
C13.8
4
Gestione dei guasti e prestazioni
Possibili guasti: - server
- comunicazione
Meccanismi di tolleranza ai guasti:
- copia informazioni e sostituzione del server guasto
- uso di timeout
Esempi:
• un partecipante dopo aver votato attende la risposta che tarda (passo 2):
-> può usare una getDecision per chiedere al coordinatore lo stato
ma un guasto del coordinatore può rallentare il partecipante
• un partecipante ha completato le operazioni su una transazione ed è in attesa
della canCommit?
-> possibili timeout al termine del quale si può eseguire una abort
Prestazioni
dell’algoritmo two phase commit con N partecipanti
caso ottimo
3N messaggi
caso pessimo
tempo illimitato
C13.9
Operazioni nel coordinatore per le transazioni annidate
Una sottotransazione conclude:
- abort
- provisional commit
locale e non permanente
Il coordinatore
openSubTransaction(trans) -> subTrans
apre una nuova sottotransazione il cui genitore è trans e restituisce un unico
identificatore di sottotransazione
Un coordinatore di sottotransazione può avere informazioni sullo stato del genitore
Se questa transazione è aborted, anche la sottotransazione va chiusa con abort
getStatus(trans)-> committed, aborted, provisional
Chiede al coordinatore un rapporto sullo stato della transazione trans
Restituisce un valore fra: committed, aborted, provisional
C13.10
5
La transazione T decide se eseguire commit
T
11
T1
provisional commit (at X)
T
T
provisional commit (at N)
T21
provisional commit (at N)
T
provisional commit (at P)
12
T
2
abort (at M)
aborted (at Y)
22
C13.11
Informazione delle transazioni annidate mantenuta nel coordinatore
Coordinatore della Transazioni
transazione
figlie
T
T1, T2
T1
T11, T12
T2
T21, T22
T11
T12, T21
T22
Partecipanti
Lista provvisoria
di commit
T1, T12
T1, T12
yes
yes
no (aborted)
no (aborted)
T12 ma nonT21
T21, T12
no (parent aborted) T22
Lista di abort
T11, T2
T11
T2
T11
C13.12
6
Protocollo two-phase commit per transazioni annidate
Protocollo realizzato in modo
piatto
Il coordinatore di alto livello
---> canCommit?---> coord. sottoT nella
lista provisional commit
Il partecipante può fare commit di
discendenti della trans. di alto livello
eccetto per quelle con antenati
aborted
gerarchico
Protocollo annidato a più livelli
Coordinatore alto livello
---> canCommit?---> coord. sottoT
----> ...
Le risposte risalgono dopo aver avuto le
risposte dai discendenti
Ognuno guarda solo al genitore
Si usa un abortList come parametro
della canCommit? per le sottoT già
aborted
C13.13
canCommit? Per il protocollo gerarchico two-phase commit
canCommit?(trans, subTrans) -> Yes / No
Chiama un coordinatore per chiedere ad un coordinatore della
sottotransazione figlia se può eseguire il commit della sottotransazione
subTrans
Il primo argomento trans è l’identificatore della transazione di livello top
Il partecipante risponde con un voto Yes / No in base al contetuto della
lista dei provisional committed transactions
Se vota Yes prepara gli oggetti al commit
C13.14
7
canCommit? per un protocollo piatto two-phase commit
canCommit?(trans, abortList) -> Yes / No
Chiamata da coordinatore a partecipante per chiedere se può eseguire la
commit di una transazione. Il partecipante risponde con il voto Yes / No
La abortList contiene l’elenco delle sottotransazioni già aborted.
La lista viene usata dal partecipante per controllare se una sottotransazione
già provisional committed è discendente di una transazione già aborted.
In tal caso anche la sottotransazione va aborted
C13.15
Controllo della concorrenza
I serventi applicano ai propri oggetti i protocolli di controllo della concorrenza per
transazioni distribuite:
locking, ottimistico, timestamp
I serventi si devono coordinare per assicurare l’equivalenza seriale
se T precede U nell’accesso (con conflitto) ad un oggetto su un servente
allora va mantenuto lo stesso ordine di accesso (con conflitto) su ogni altro
oggetto su cui T ed U competono
Locking lock locali; gli oggetti sono non disponibili ad altri per la durata del
protocollo atomico
-> possibili cicli di attesa -> stallo
Ottimistisco convalida prima della esecuzione del commit
numerazione delle transazioni all’inizio della fase di convalida
la convalida avviene nella fase 1 del protocollo two phase commit
-> possibili cicli di attesa per commit (convalida) ->
stallo di commit
C13.16
8
Controllo della concorrenza
Ottimistico in transazioni distribuite: convalida concorrente
Estensione del protocollo di convalida backward e forward per poter avere
parallelismo nella fase di convalida
(più transazioni simultaneamente nella fase di convalida)
-> occorre controllare anche la regola 3
p.es. nella backward controlla lle regole 2 e 3;
se il write set della Tv è sovrapposto al write set delle T sovrapposte
precedentemente
-> elimina lo stallo di commit
-> rimane il problema della serializzazione:
varie soluzioni (convalida globale dopo quella locale, numerazione globale,…)
Timestamp numerazione delle transazioni e degli oggetti
nel caso distribuito: timestamp globalmente unici dati dal coordinatore
al primo accesso
I server si coordinano per serializzare le transazioni
l’ordinamento globale dato da <timestamp locale, server id> si basa su
un ordinamento dei server
I conflitti sono risolti per ogni operazione tramite eventuali abort C13.17
Interleaving di transazioni U, V e W
U
d.deposit(10)
V
lock D
b.deposit(10)
a.deposit(20)
b.withdraw(30)
W
lock A
at X
lock B
at Y
c.deposit(30)
lock C
at Z
a.withdraw(20)
wait at X
wait at Y
c.withdraw(20)
wait at Z
C13.18
9
Stallo distribuito
(a)
(b)
W
Assegnato a
W
Attesa
D
C
A
X
Z
Assegnato a
Attesa
V
Assegnato a
V
U
U
Attesa
B
Assegnato a
Y
C13.19
Grafi di attesa locale e globale
grafo wait-for locale
T
U
X
grafo wait-for locale
V
rilevatore di stallo globale
T
T
Y
U
V
C13.20
10
Test trasmessi per identificare lo stallo
W
W→ U → V → W
Assegnato a
Attesa
Stallo
riconosciuto C
A
Z
Attesa
X
Inizio
W→ U → V
W→ U
V
U
Assegnato a
Y
Attesa
B
C13.21
Due test iniziati
(a) situiazione iniziale
In attesa di
V
(b) riconoscimento iniziato dall’oggetto
richiesto da T
In attesa di
T
U
W
In attesa di
T
V
T→U
T
W
U
T→U→W→V
(c) ) riconoscimento iniziato
dall’oggetto richiesto da W
T→U→W
→V →
W
V
→V→T→U
U
W
W
T
→V
In attesa di
W
C13.22
11
Spostamento del test
.
.
(a) V memorizza il test quando U inizia
l’attesa
(b) Test è inoltrato quando V inizia l’attesa
W
Waits
for C
U
V
probe
queue
U →V
W U→V
V→ W
Waits for
B
U →V
V
U→V
probe
queue
U
Waits for
B
C13.23
Gestione dei guasti
Possibili guasti: - server
- comunicazione
Mantenere: permanenza (durability) e atomicità (anche dei guasti)
Recovery manager
Gestione dei problemi di permanenza per transazioni committed
Recupero da guasti
Gestione dei file di recupero per ottimizzare le prestazioni dei tempi di ripristino
Gestione dei file di recovery
Per tenere traccia delle operazioni delle transazioni ogni server ha una
lista delle intenzioni
con l’elenco degli oggetti ed i valori modificati per ogni transazione attiva
Informazioni sullo stato della transazione
File di ripristino - approcci di uso
Logging
Versioni ombra
C13.24
12
Tipi di entry in un file di ripristino
Tipo di entry
Oggetto
Stato della
transazione
Descrizione dei contenuti di entry
Valore di un oggetto
Identificatore di transazione, stato di transazione (prepared ,
committed , aborted ) e altri valori di stato usati per il protocollo
two-phase commit
Lista di intenzioni Identificatore di transazione e sequenza di intenzioni, ognuna
ha
<identificatore di oggetto >, <posizione nel file di ripristino
del valore dell’oggetto>
C13.25
Esempio: log per il servizio bancario
P0
P1
P2
P3
P4
P5
P6
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T
Object:C Object:B
100
200
300
80
220
prepared committed 278
242
<A, P1>
<B, P2>
P0
P3
Checkpoint
P7
Trans:U
prepared
<C, P5>
<B, P6>
P4
End
of log
C13.26
13
Versioni ombra
Map at start
Map when T commits
A →P0
B → P 0'
A →P1
B →P2
C → P 0"
Version store
C → P 0"
P0
P0'
P0"
100
200
300
P1
80
P2
P3
P4
220
278
242
Checkpoint
C13.27
Log con elementi relativi al protocollo two-phase commit
Trans:T
Coord’r:T
Trans:T
prepared
part’pant
list: . . .
committed prepared
intentions
list
Trans:U
Part’pant:U Trans:U
Trans:U
Coord’r: . . uncertain
committed
intentions
list
C13.28
14
Ripristino del protocollo two-phase commit
Ruolo
Stato
Coordinatore prepared
Coordinatore committed
Partecipante committed
Partecipante uncertain
Partecipante prepared
Coordinatore done
Azione del gestore del ripristino
Nessuna decisione presa prima del guasto. Invia una
abortTransaction a tutti iserventi nella lista dei partecipanti e aggiunge
lo stato aborted nel suo file di ripristino. Lo stesso per lo stato
aborted. Se non c’e’ lista dei partecipanti alla fine i partecipanti hanno
Il segnale di timeout ed eseguono l’ abort della transazione.
Si è raggiunta la decisione commit prima del guasto.
Manda doCommit a tutti i particepanti nella lista dei partecipanti (se
non lo ha fatto prima) e ripristina il protocollo two-phase al passo 4
Il partecipante invia un messaggio haveCommitted al coordinatore (nel
caso in cui non sia stato fatto prima del guasto per permettere al coordinatore
di eliminare l’informazione di questa transazione al prossimo checkpoint.
Il participante fallisce prima di sapere il risultato della transazione
non può determinare lo stato della transazione prima che il coordinatore
lo informi della decisione. Manderà una getDecision al coordinatore
per determinare lo stato della transazione. Alla ricezione della risposta
eseguirà la commit o abort relativa.
Il partecipante non ha ancora votato e può abortire la transazione.
Nessuna azione richiesta
C13.29
Transazioni annidate
Testa della pila
T11
T
T
A1
1
T12
T2
A11
A11
A1
T1
A12
A12
A11
T11
A2
A2
A12
T12
T2
C13.30
15