Anno 2013-2014 Architetture dati DBMS Centralizzati Controllo di concorrenza Carlo Batini.

Presentazione sul tema: "Anno 2013-2014 Architetture dati DBMS Centralizzati Controllo di concorrenza Carlo Batini."— Transcript della presentazione:

1 Anno 2013-2014 Architetture dati DBMS Centralizzati Controllo di concorrenza Carlo Batini

2 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 2 Sappiamo gia’ che ….

3 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 3 Concurrency control

4 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 4 Concorrenza - 1  Il throughput di un sistema e’ il numero di transazioni per secondo (tps) accettate dal sistema a regime  In un sistema che non prevede esecuzione concorrente, il throughput e’ al massimo pari al tempo di esecuzione di una singola transazione –Puo’ essere dell’ordine dei secondi per una normale applicazione OLTP  In un DBMS, si vuole ottenere un throughput dell’ordine di 100- 1000tps  Questo impone un alto grado di concorrenza tra le transazioni in esecuzione –Es Se una transazione impiega mediamente 0.1 secondi ad eseguire, ad un throughput di 100tps corrispondono mediamente 10 transazioni in esecuzione concorrente  Esempi tipici: applicazioni bancarie, di prenotazione voli

5 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 5 Concorrenza - esempio Void chooseSeat() { /* codice C che verifica la disponibilita’ di posti su un volo e prenota un posto */ (1) EXEC SQL SELECT occupied INTO :occ FROM flights WHERE fltNum = :flight AND fltDate = :date AND fltSeat = :seat; (2) if (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltNum = :flight AND fltDate = :date AND fltSeat = :seat; /* notifica posto prenotato */ } else /* notifica volo completo */ }

6 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 6 Concorrenza - 2  Supponiamo che la funzione chooseSeat() venga eseguita simultaneamente da due o piu’ applicazioni (es due agenzie viaggi), che cercano di prenotare lo stesso posto sullo stesso volo  E’ possibile un’evoluzione temporale come la seguente:  A questo punto, abbiamo una doppia prenotazione  Il DBMS transazionale gestisce questo problema garantendo la proprieta’ di isolamento Appl. 1 Esegue (1), trova posto Esegue (2), alloca il posto Appl. 2 Esegue (1), trova posto Esegue (2), alloca il posto tempo

7 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 7 Proprieta’ di Isolamento delle transazioni  Scriviamo la funzione precedente come una transazione:  La proprieta’ di isolamento di una transazione garantisce che essa esegua come se non ci fosse concorrenza  Questa proprieta’ e’ garantita facendo in modo che ciascun insieme di transazioni concorrenti sottoposte al sistema sia sempre serializzabile Void chooseSeat() { Begin transaction (1) EXEC SQL SELECT occupied INTO :occ FROM flights WHERE fltNum = :flight AND fltDate = :date AND fltSeat = :seat; (2) if (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltNum = :flight AND fltDate = :date AND fltSeat = :seat; /* notifica posto prenotato */ } else { /* notifica volo completo */ } commit work; }

8 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 8 Introduciamo ora un primo insieme di concetti  Schedule  Schedule seriale  Schedule serializzabile e serializzabilita’

9 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 9 Schedule  Una sequenza di esecuzione di un insieme di transazioni e’ detta schedule  Es e’ uno schedule la sequenza  T1: trova posto, T2: trova posto; T1: alloca posto; T2 alloca posto   Una schedule e’ seriale se una transazione termina prima che la successiva inizi  Lo schedule seguente e’ seriale  T1: trova posto, T1: alloca posto; T2: trova posto; T2 alloca posto  Il precedente non lo e’.

10 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 10 Osservazione  Date due transazioni T1, T2, in generale  A. eseguire T1 prima di T2  porta ad un risultato (modifica dello stato del DB) diverso che  B. Eseguire T2 prima di T1

11 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 11 Serializzabilita’  La proprieta’ di isolamento:  Ogni transazione esegue come se non ci fosse concorrenza  coincide con la proprieta’ per cui un insieme di transazioni eseguite concorrentemente produce lo stesso risultato che produrrebbe una (qualsiasi) delle possibili esecuzioni sequenziali delle stesse transazioni.  Ne basta una!  Quella esecuzione e’ proprio la esecuzione che garantisce l’isolamento (… come se fosse eseguita da sola)

12 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 12 Serializzabilita’  Uno schedule e’ serializzabile se l’esito della sua esecuzione e’ lo stesso che si avrebbe se le transazioni in esso contenute fossero eseguite in una (qualsiasi) sequenza seriale

13 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 13 Esempio - 1  Lo schedule  T1: trova posto, T2: trova posto; T1: alloca posto; T2 alloca posto  non e’ serializzabile, perche’ da’ risultato diverso da  A. lo schedule seriale  T1: trova posto, T1: alloca posto; T2: trova posto, T2 alloca posto assegna il posto alla T1, e da  B. lo schedule seriale  T2: trova posto, T2: alloca posto; T1: trova posto, T1 alloca posto assegna il posto alla T2

14 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 14 Esempio – 2 E’serializzabile il seguente schedule?  T1 (x=x+x; x= x+2) e T2 (x= x**2; x=x+2) concorrenti nel seguente schedule  S = [T1:x= x+x; T2: x= x**2; T1: x= x+2; T2:x=x+2]  Eseguito per x= 5 da come risultato  x=104  Possibili sequenze seriali: Sequenza T1 T2 : Pre: x=5 T1, T2: post: x = 146 Sequenza T2 T1 : Pre: x=5 T2, T1: post: x = 56 Lo schedule non e’ serializzabile

15 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 15 Esempio di proprieta’ di serializzabilita’  Insieme concorrente  t11 t21 t31 t32 t12 t22 t23 t13  Quante e quali sono le possibili esecuzioni seriali?  t1, t2, t3  t1, t3, t2  t2, t1, t3  t2, t3, t1  t3, t1, t2  t3, t2, t1  Una delle sequenze deve dare lo stesso risultato finale

16 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 16 Introduciamo ora una notazione semplificata per descrivere transazioni

17 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 17 Ruolo dello scheduler  Lo scheduler (concurrency controller) –Ha il compito di garantire l’isolamento –Accoglie una transazione e le assegna un identificatore unico –Chiede al buffer manager del DBMS di leggere/scrivere sul DB secondo una particolare sequenza –Quindi,dobbiamo assumere che non sia in grado di interpretare le specifiche operazioni sui dati: – la serializzabilita’ non puo’ dipendere dal tipo di operazioni eseguite ne’ dall’input

18 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 18 Notazione semplificata per lo schedule  Semplifichiamo quindi la nostra notazione –Le transazioni degli esempi precedenti si scrivono: T1: r(A) r(B) w(A) w(B) c –Un esempio di schedule: r1(A) w1(A) r2 (A) w2(A) r1(B) w1(B) c1 r2(B) w2(B) c2 T1 legge A T2 scrive A T1 commit

19 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 19 3. Definizione di diversi livelli di serializzabilita’

20 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 20 Serializzabilita’ ed equivalenza tra schedules  La definizione generale di serializzabilita’ si basa sulla nozione di equivalenza tra due schedules:  Una schedule e’ serializzabile se e solo se esso e’ equivalente ad uno schedule seriale  A diverse definizioni della relazione di equivalenza corrispondono diversi livelli di serializzabilita’

21 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 21 Algoritmi per verificare la equivalenza  Interessa definire due tipi di algoritmi: –Algoritmi per il test di equivalenza: date due schedules, determina se esse sono equivalenti (semplice) –Data una schedule, determina se essa e’ equivalente ad una qualunque schedule seriale (complesso)  Nella pratica, definiremo delle regole di comportamento dello scheduler che garantiscono un dato livello di serializzabilita’, senza eseguire alcun test esplicito

22 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 22 Classi di schedules  Idea base: individuare classi di schedules serializzabili … Schedules Seriali Schedules Schedules Serializzabili  che siano sottoclassi degli schedules possibili, siano serializzabili e la cui proprieta’ di serializzabilita’ sia verificabile con complessita’ ragionevole

23 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 23 Nel seguito vedremo la classe di schedule in cui il controllo di concorrenza e’ effettuato tramite lock

24 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 24 Controllo di concorrenza tramite locks  Idea: definizione di un protocollo che garantisca a priori la conflict serializability –Richiede la presenza di uno scheduler nell’architettura del DBMS Scheduler DB T 1 T 2 ……T n

25 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 25 Primitive di lock  Introduciamo due nuove operazioni, che richiedono l’utilizzo ed il rilascio, per ora, esclusivo di una risorsa: –Lock (esclusivo): l i (A)  Voglio la risorsa –Unlock: u i (A)  Rilascio la risorsa  Le primitive di lock vengono aggiunte alle transazioni e inserite all’interno delle sequenze di operazioni wi(A), rj(A)

26 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 26 Compito dello scheduler  Trasformare le transazioni aggiungendo i comandi di lock, sulla base della conoscenza delle assegnazioni precedenti, in modo da garantire la serializzabilita’  Memorizzare tali assegnazioni in una tabella di lock scheduler T 1 T 2 lock table wi(A) … rj(A)…… li(A) … wi(A) … ui(A)... lj(A) … rj(A) … uj(A)...

27 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 27 Lock info per T1 T1... H Ti T2 T3 Lock info per T2 Tabelle di lock

28 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 28 Esecuzione delle transazioni con lock  Ora lo scheduler esegue le transazioni, e, quando una transazione chiede di accedere a una risorsa gia’ lockata da un’ altra transazione, la sospende e la mette in coda.

29 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 29 Uso dei lock  Vogliamo definire le regole di composizione dei protocolli di lock sulle transazioni e sugli schedule che garantiscano la serializzabilita’ delle schedules  Definiamo: –Transazioni ben formate e schedules legali –Protocollo Two phase locking (2PL) –Ulteriori tipi di lock - cenni

30 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 30 Transazioni ben formate  Regola #1 – Transazione ben formata: Ogni azione p(A) (lettura o scrittura di A) deve essere contenuta in una “sezione critica” definita da una coppia di lock: Ti: … l i (A) … w i (A) … u i (A)... La regola esprime la ovvia proprieta’ per cui ogni lettura/scrittura deve avere una coppia l/u e ad ogni lock deve corrispondere un unlock

31 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 31 Schedule legale  Regola #2 – Schedule S legale: ogni coppia lock unlock in uno schedule deve essere esclusiva: S = ……l i (A) ………u i (A) …… La regola permette di rispettare la semantica dei lock e assegnare ogni risorsa a una transazione alla volta non ci sono altri l j (A)

32 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 32 Esempi di schedule con lock -1 S1 = l1(A) l1(B) r1(A) w1(B) l2(B) u1(A) u1(B) r2(B) w2(B) u2(B) l3(B) r3(B) u3(B) Le transazioni sono ben formate? Mettiamo in evidenza T1 S1 = l1(A) l1(B) r1(A) w1(B) l2(B) u1(A) u1(B) r2(B) w2(B) u2(B) l3(B) r3(B) u3(B) La transazione T1 e’ ben formata, analogamente per le altre Lo schedule e’ legale? S1 = l1(A) l1(B) r1(A) w1(B) l2(B) u1(A) u1(B) r2(B) w2(B) u2(B) l3(B) r3(B) u3(B) No!

33 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 33 Esempi di schedule con lock-2 S2 = l 1 (A) r 1 (A) w 1 (B) u 1 (A) u 1 (B) l 2 (B) r 2 (B) w 2 (B) l 3 (B) r 3 (B) u 3 (B)… T 1 non ben formata: Write senza lock S2 non legale

34 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 34 Esempi di schedules con lock S3 = l 1 (A) r 1 (A) u 1 (A) l 2 (B) r 2 (B) w 2 (B) u 2 (B) l 1 (B) w 1 (B) u 1 (B) l 3 (B) r 3 (B) u 3 (B) Transazioni ben formate e schedule legale

35 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 35 Aggiungiamo l’ulteriore terza regola di Two Phase Locking (2PL): In ogni transazione tutte le richieste di lock precedono tutti gli unlock T i = ….……. l i (A) ………... u i (A) ………. no unlocks no locks Two-Phase Locking Si puo’ dimostrare che le tre proprieta’ definite rendono lo schedule serializzabile

36 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 36 T i = ……. l i (A) ………... u i (A) …… no unlocks no locks Growing Phase Shrinking Phase Time # locks ottenuti da Ti Two-Phase Locking

37 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 37 Dai lock agli shared locks  2PL con lock esclusivi restringe molto l’insieme degli schedule serializzabili:  come fare ad estenderli? Schedules Seriali Schedules Schedule Serializ zabili Schedules Serializ zabili Con 2PL

38 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 38 Due tipi di “rilassamenti”: shared locks e lock gerarchici Read Write Singoli record Intere basi di dati Lock gerarchici Lock parziali sulle Operazioni di lettura scrittura

39 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 39 Shared locks Finora la situazione e’: S =...l1(A) r1(A) u1(A) … l2(A) r2(A) u2(A) … In realta’, le due letture protette da lock non sono in conflitto. E’ possibile introdurre un nuovo tipo di lock: shared lock lsi(A) In questo esempio otteniamo: S =... ls1(A) r1(A) ls2(A) r2(A) …. us1(A) us2(A) Le primitive di lock ora diventano: lxi(A): lock in modalita’ esclusiva lsi(A): lock in modalita’ condivisa ui(A): unlock

40 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 40 Lock gerarchici: cenni

41 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 41 Struttura di uno schema fisico di BD Schema Relazioni Blocchi Tuple BD R2R1Rn B11B12B1n T111T11n ……..

42 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 42 Granularita’ del locking – locking gerarchico Relation A Relation B... DB Tuple A Tuple B Tuple C... DB Disk block A Disk block B... DB In molti DBMS e’ possibile specificare i locks a diverse granularita’:

43 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 43 Opzioni per la granularita’  Utilizzando lock su oggetti grandi (esempio Relazioni) –Sono sufficienti pochi locks –La concorrenza e’ ridotta – le risorse restano bloccate con alta probabilita’  Utilizzando lock su oggetti piccoli (esempio record, campi) –Occorrono piu’ locks  aumenta il carico di gestione –La concorrenza aumenta

44 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 44 Esempi  Esempio 1  DB bancaria e operazioni su conti (depositi e prelievi)  Non conviene mettere lock su intere relazioni perche’ cosi’ si permette una operazione alla volta. Conviene porre lock a livello di pagina o blocco, non conviene scendere fino a livello di tupla  Esempio 2  Basi di documenti e operazioni di editing e retrivial  In genere le operazioni di modifica/ scrittura dei documenti sono poco frequenti rispetto a quelle di retrieval/ lettura  In questo caso conviene fare lock a livello dell’intero documento e non delle sue parti

45 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 45 Il deadlock

46 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 46 Il deadlock  Problema comune a tutte le strategie di controllo di concorrenza basate su locking  Un deadlock e’ una condizione in cui due transazioni T1 e T2 si trovano ad occupare due risorse A e B e ciascuna chiede la risorsa occupata dall’altra  Cio’ provoca un blocco delle due transazioni, che non possono procedere.

47 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 47 Esempio di deadlock T1T2 l1(A) r(A) w(A) l2(B) r(B) w(B) l2(A) l1(B)  La probabilita’ di deadlock cresce in modo lineare con il numero di transazioni e in modo quadratico con il numero di richieste di lock da parte di ogni transazione In attesa Sequenza Di esecuzione

48 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 48 Tecniche utilizzate per risolvere i deadlock  Uso del timeout  Rilevazione dei deadlock  Prevenzione dei deadlock

49 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 49 Struttura del lock Manager Scheduler, parte I DB Tabella dei lock l(A),Read(A),l(B),Write(B)… Read(A),Write(B) TiTi Decide politiche di lock e inserisce i lock Scheduler, parte II Read(A),Write(B) Esegue i lock, utilizzando la tabella dei lock, se provocano attesa gestisce le code

50 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 50 Finora abbiamo svolto il ragionamento non preoccupandoci di cio’ che puo’ avvenire riguardo alla correttezza dello schedule a seguito di rollback Insomma, non abbiamo tenuto in conto i problemi di recovery, e abbiamo assunto che non ci siano guasti Ora dobbiamo tenerne conto!

51 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 51 Commit, rollback e correttezza delle transazioni  Esistono situazioni in cui la serializability non e’ proprieta’ sufficiente a garantire la correttezza della esecuzione. Esempio  ……w1(A) …… r2(A) ……C2………C1  Supponiamo che dopo C2 per qualche ragione T1 debba abortire: T2 ha letto un dato che non e’ piu’ valido  fenomeno di dirty data  Lo schedule e’ conflict-serializable, ma non “corretto”:T2 ha usato un valore che non esiste nello stato finale

52 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 52 Concetto di Recoverable schedule - 1 Per permettere il recovery di un insieme di transazioni, deve valere la seguente proprieta’ Se una transazione T1 e’, dopo il recovery, considerata committed, allora lo deve essere ogni altra transazione da cui T1 ha letto. Per committed, qui e nel seguito, intendiamo il fatto che il commit record nel log ha raggiunto la memoria stabile.

53 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 53 Concetto di Recoverable schedule - 2  Esempio  S1 = ……w2(A) …… r1(A) ……C1………C2  Non e’ recoverable  S2 = ……w2(A) …… r1(A) ……C2………C1  E’ recoverable

54 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 54 Relazione tra i concetti di serializable e recoverable  I due concetti sono ortogonali  Es. lo schedule S1 = w2A w1B w1A r2B c1 c2  e’ recoverable ma non serializable Recov Serializ. S1 S2 Lo schedule S2 = w1A w1B w2A r2B c2 c1 e’ serializable ma non recoverable

55 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 55 Dunque Serializable Recoverable Seriale

56 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 56 Recoverable transactions e 2PL  Nella discussione sulle recoverable transactions ci siamo fino ad ora preoccupati della relazione tra: –Operazioni di lettura –Operazioni di rollback –Operazioni di commit  E non abbiamo piu’ considerato i lock  Dobbiamo ora capire, per garantire la serializability, come si modificano i lock e dunque la struttura del 2PL

57 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 57 Protocollo Strict 2PL  S e’ Strict 2PL se e’ 2PL e i lock di ogni transazione Ti vengono mantenuti fino al commit o l’abort di Ti  ……wi(A)……Ci Ui(A)…… rj(A)

58 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 58 Valgono le seguenti proprieta’  Ogni schedule strict 2PL e’ serializzabile –Infatti la strict schedule e’ equivalente alla schedule seriale in cui ogni transazione esegue i comandi al tempo del commit

59 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 59 Riassumendo: le transazioni serializable non sono necessariamente recoverable ……… Serializable Recoverable Seriale

60 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 60 Strict 2PL Abbiamo bisogno di un concetto piu’ forte del 2PL per garantire tutte le proprieta’: lo strict 2PL Serializable Recoverable Seriale

61 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 61 Uso dei lock in pratica  Un lock manager semplificato:  Acquisisce i locks necessari automaticamente –Dopo BEGIN TRANSACTION e prima di ogni operazione SQL (SELECT, UPDATE, INSERT ecc)  Li mantiene fino al COMMIT WORK ovvero ROLLBACK WORK  strict 2PL

62 Complementi di Basi di Dati Controllo di Concorrenza – Carlo Batini e Paolo Missier 2003– 62 2PL e scheduler con lock management  Se una transazione non fa richieste esplicite al lock manager, allora: –lo scheduler garantisce che ogni transazione e’ ben formata  Chiede al lock manager l’acquisizione dei lock prima delle operazioni  Chiede al lock manager il rilascio dei lock al momento del commit –Il lock manager garantisce che la schedule effettivamente eseguita e’ legale  Le richieste di lock su risorse gia’ allocate in modo esclusivo vengono accodate –Come risultato, lo schedule eseguito nella realta’ puo’ essere diverso dalla sequenza con la quale le operazioni vengono richieste dalle transazioni