2.

Sistemi transazionali Sistema Transazionale:

Contenuto:

Il concetto di Transazione

Affidabilità (Reliability)

Controllo della concorrenza
Lock, Two-Phase Lock, Deadlock

Sicurezza e Privatezza (Security)
sistema capace di eseguire programmi gestionali, detti
transazioni
Es.: sistema informativo di una banca
I sistemi transazionali sono in genere associati a una o più
DB di grandi dimensioni.
Possono essere sistemi centralizzati o distribuiti, comunque
operanti su una rete di calcolatori.

1 2

Il concetto di Transazione Questo esempio mostra che il buon funzionamento di una
transazione richiede che la stessa abbia le seguenti
Es. di transazione: proprietà:
Accredito di £. L dal conto corrente X della filiale b1 della
Atomicità:
banca B1 al conto corrente Y della filiale b2 della banca B2. una transazione può terminare in due soli modi:



  commit




  abort


annullamento del tutto e ripristino
della situazione precedente l’inizio della
transazione

Persistenza

Serializzabilità:
In un sistema transazionale di grandi dimensioni è
generalmente necessario poter eseguire transazioni
concorrenti (in esecuzione contemporanea).
Al fine di mantenere una situazione corretta e consistente,
le transazioni concorrenti devono essere serializzabili.
Ciò vuol dire che la loro esecuzione concorrente deve
equivalere ad una qualsiasi esecuzione in sequenza delle
stesse.

3 4

Affidabilità (Reliability)
Un sistema transazionale è affidabile quando è in grado di
sopportare guasti e malfunzionamenti senza pregiudicare
atomicità e persistenza delle transazioni.
L’affidabilità è demandata a due componenti principali:

Memoria stabile “resistente ai guasti”

Protocolli “robusti” nel trattare le operazioni di
modifica dei dati (fra le operazioni read/write, quelle
pericolose sono le write)
5 6

Memoria stabile
La memoria stabile è un dispositivo fisico, quindi non
esente da guasti: ad esempio, la testina di un disco
magnetico può rovinare e rendere illeggibili delle tracce.
Precauzioni:
Ci sono vari metodi e livelli di sicurezza.
Ad esempio, più dischi con copie (mantenute) identiche dei
dati e modalità di guasto indipendenti.

Protocolli(*) e meccanismi di ripresa (tipo undo-redo):
Controllo della concorrenza:

T: <begin transaction T> Problemi nell’esecuzione concorrente:

op1, op2, ... opn
<end transaction T> Esempio “tipico” di esecuzione non corretta:
Siano T1 e T2 due transazioni che accedono
<end transaction T> = {commit T | abort T} concorrentemente al dato D, residente su file.
Siano X, Y variabili locali alla transazione T1
Sia D inizialmente pari a 0

Molto grossolanamente:
Si supponga che T1 e T2 operino come segue:
Log (giornale di transazione):
è un file, mantenuto in memoria stabile, che mantiene T1: leggi D e scrivilo in X
sempre copia dell’ultima transazione terminata (T), per leggi D e scrivilo in Y
poter eventualmente ripristinare la situazione precedente
l’avvio di una transazione successiva (Tsucc) nel caso T2: scrivi 3 in D
quest’ultima non vada a buon fine.
Si osservi che l’esecuzione di T1, transazione atomica
<begin transaction Tsucc> composta da due operazioni di lettura, deve restituire lo
stesso valore in X e Y. Inoltre, dopo l’esecuzione delle due
begin T ..... end T il log contiene copia di T
transazioni concorrenti, D deve valere 3
....
<end transaction Tsucc>
Si consideri l’esecuzione:
commit Tsucc
sul log viene scritta copia di Tsucc 1. T1: leggi D e scrivilo in X (X =0)
abort Tsucc
dal log viene letta T e ripristinata la 2. T2: scrivi 3 in D (D vale 3)
situazione precedente <begin transaction Tsucc> 3. T1:leggi D e scrivilo in Y (Y vale 3)

L’esecuzione viola l’atomicità di T1

In questo esempio, la transazione T1, pur non operando
(*)
Si assume che i dati della memoria stabile non vengano persi: già modifiche sul dato D, termina in modo non corretto.
con due dischi, il tempo medio fra due guasti è circa di 700 anni
7 8
 Controllo della concorrenza: locking Controllo concorrenza: locking condiviso e locking
esclusivo

Per evitare esecuzioni errate di transazioni concorrenti, è

necessario gestire le situazioni di conflitto:

È possibile distinguere due modalità di locking: locking

Tipi di conflitto:
condiviso (C) e locking esclusivo (E).
T1: Read, T2: Read
T1: Read, T2: Write
T1: Write, T2: Write Un lock condiviso deve essere ottenuto prima di una
transazione che comprenda una lettura (R).
Osservazione: vi è effettivo conflitto quando almeno una
delle n transazioni concorrenti esegue una scrittura!!!
Un lock esclusivo deve essere ottenuto prima di una
Di questo problema si occupa il Gestore delle Transazioni,
transazione che comprenda una scrittura (W).
tramite il meccanismo di locking.

Il locking si basa su due operazioni, dette lock (blocca) e

Il gestore dei lock ammette infatti letture contemporanee,
unlock (sblocca), effettuate dalle transazioni sui dati.
mentre una scrittura deve essere effettuata in mutua
esclusione da altre operazioni.

9 10
 Controllo concorrenza: gestione dei lock

Locking Condiviso (C):

Più precisamente:
T1 è una lettura e blocca D
con un lock condiviso: T2 e
CONFLITTO:
T3 possono leggere D
situazione in cui l’accesso non viene concesso

COME SI EVIDENZIA UN CONFLITTO?

al dato D viene associato un descrittore di stato che può
assumere i tre valori:

Locking Esclusivo (E): s: {libero | bloccato C | bloccato E}

T1 è una scrittura e blocca D

Tabella dei conflitti nella gestione dei lock:
con un lock esclusivo: T2
non può leggere D, T3 non
Ti chiede lock Tj ha lock
può aggiornare D finchè T1 (W)
C E
non avrà eseguito unlock su
D
C Ti ottiene lock Ti non ottiene lock

E Ti non ottiene lock Ti non ottiene lock

11 12
 Controllo concorrenza: gestione degli unlock
Esempio 1:

1. Ciascuna transazione Ti invia, prima di ogni operazione

su un dato D, una richiesta di blocco al gestore dei lock.
Se l’operazione è di lettura, Ti chiede un lock condiviso; se
l’operazione è di scrittura, Ti chiede un lock esclusivo.

2. Il gestore analizza la richiesta pervenuta: se la richiesta

non genera conflitti, essa viene accolta ed il lock manager
provvede a bloccare il dato e aggiornarne lo stato. Se la
richiesta genera un conflitto, la transazione richiedente
viene sospesa, in attesa che la transazione bloccante
termini. Questo si realizza programmando il gestore dei
lock quale gestore di code di transazioni bloccate.

3. Prima del termine di una transazione, tutti i lock

vengono rilasciati; quando viene sbloccato un generico
dato D, il programma gestore provvede a riattivare la
prima delle transazioni eventualmente sospese sulla coda
relativa al dato D.

13 14
Esempio 2: Controllo concorrenza: problemi del locking C/E

Il meccanismo di locking descritto non assicura la

serializzabilità e l’isolamento di una transazione.
Controesempio:

D=0

T1:
T11: leggi D e scrivilo in X
T12: leggi D e scrivilo in Y

T2: scrivi 3 in D (D vale 0)

Sequenza d’ esecuzione 1: T11, T2, T12

D = 0; T11
X=0; T2
D=3; T12
Y=3;
T11 esegue un lock condiviso su D e legge D=0;
T2 chiede un lock esclusivo e non lo ottiene, quindi resta in
coda finchè, terminata T11, T1 non esegue unlock su D.
A questo punto, T2 esegue un lock esclusivo su D e lo
aggiorna a D=3 e T12 resta sospesa.
Quando T2 rilascia D, chiede un lock condiviso e legge D =
3
Questa esecuzione viola l’atomicità di T1

15 16
Sequenza d’ esecuzione 1: T11, T2, T12
D = 0; T11
X=0; T2
D=3; T12
Y=3;
Sequenza d’ esecuzione 2: T1 T1 T2
1, 2,
D = 0; T11
X=0; T12
Y=0;T2
D=3;
Sequenza d’ esecuzione 3: T2, T11, T12
D = 0; T2
D=3;T11
X=3; T12
Y=3;
Le tre sequenze danno risultati diversi: viene violata la
serializzabilità
17
Controllo concorrenza: Two-Phase Lock
Per assicurare atomicità e serializzabilità, la gestione dei
lock deve seguire un particolare protocollo nelle operazioni
di lock e unlock.
Tale protocollo (ve ne sono altri) è detto di “lock a due fasi”
o “two-phase lock” e richiede quanto segue:
Garanzia di serializzabilità:
Non è possibile richiedere nuove risorse dopo averne
rilasciata una.
Garanzia di atomicità:
Non è possibile rilasciare una risorsa prima di aver
eseguito il commit o l’abort e di avere svolto su di
essa eventuali operazioni di scrittura.
Si può dimostrare che, se la gestione dei lock adotta questo
protocollo, l’esecuzione concorrente rispetta atomicità e
serializzabilità.
18
Two-Phase lock: Esempio 1 Controllo concorrenza: Deadlock

D=0 L’uso delle primitive di lock genera il rischio di condizioni

di stallo (“deadlock”).
T1:
T11: leggi D e scrivilo in X Esempio tipico:
T12: leggi D e scrivilo in Y Siano D1 e D2 due dati su cui operano le transazioni
concorrenti T1 e T2.
T2: scrivi 3 in D (D vale 0)
Il simbolo lock(Ti, Dh, {C|E}) indica che la transazione Ti
ha effettuato un lock condiviso o esclusivo sulla risorsa Dh.
Si consideri questa situazione:
Sequenze possibili La sequenza è ammissibile?
T11, T12, T2 Si: T1 non rilascia D e T2 T1:
esegue il commit T11: lock(T1, D1, E)
T12: lock(T1, D2, E)
T2:
T11, T2, T12 No: idem T21: lock(T2, D2, E)
T12, T11, T2 Si: T1 non rilascia D e T2 T22: lock(T2, D1, E)
esegue il commit
Si consideri la sequenza di esecuzione:
T12, T2, T11 No: idem T11, T21, T12, T22
T2, T11, T12 Si: T2 esegue il commit e T1
T11: lock concesso, D1 è bloccata e non può essere rilasciata
non rilascia D
perchè T1 non ha eseguito commit nè abort, anche se ha
T2, T12, T11 Si: idem scritto.
T21: lock concesso, D2 bloccata per gli stessi motivi
T21: lock non concesso, poichè la risorsa è bloccata
T11, T12, T2  T1, T2 in sequenza T22: lock non concesso, poichè la risorsa è bloccata
T12, T11, T2  T1, T2 in sequenza
T2, T11, T12  T2, T1 in sequenza
T2, T12, T11  T2, T1 in sequenza
19 20
Come risolvere un deadlock?
Sicurezza e Privatezza (Security):

Il sistema sceglie arbitrariamente una delle transazioni

Sicurezza:
bloccanti e la manda a termine in abort.
Capacità di prevenire attività dolose da parte di utenti non
autorizzati.

Privatezza:
Controllo di accesso, da concedere ai soli utenti autorizzati.

Sicurezza: difese possibili

1. Autenticazione:
username & password, eventualmente a più livelli
...
autenticazione tramite sistemi biometrici
2. Auditing: controllo a posteriori sul log
3. Crittografia: codifica dei dati che rende gli stessi
incomprensibili se non per chi ha il codice di
decodifica

Privatezza: difese possibili

Differenziazione dei diritti a seconda dell’utente

21 22