Basi di Dati Complementi Esercizi Esercizi su concurrency control

Transcript

1 Basi di Dati Complementi Esercizi Esercizi su concurrenc control Esercizio. Dati gli schedule : s r w r w r w s r w r w r3 w r r3 s3 r r3 rz w w3 a. specificare, con una breve giustificazione, a quali delle seguenti classi ciascuno di essi appartiene: S (seriale), CSR (conflict serializzabile), PL (generabile da uno scheduler basato sul lock a due fasi), e TS (generabile da uno scheduler che utilizzi il metodo dei time stamp; si assuma che l ordinamento degli identificatori delle transazioni corrisponda quello dei timestamp). b. Specificare inoltre quali schedule provochino eventualmente un deadlock. Schedule s r w r w r w Caso seriale Lo schedule non e seriale perche le transazioni e effettuano letture e scritture inserite all interno della transazione. Schedule s r w r w r w Caso conflict serializable - Costruiamo il grafo dei conflitti: r w r w r w t t t - Lo schedule appartiene alla classe CSR in quanto il grafo dei conflitti e aciclico Schedule s r w r w r w Caso PL Simuliamo il funzionamento dello scheduler: Per ogni operazione, inseriamo il lock corrispondente, se necessario A. Costruiamo uno schedule con i lock esclusivi a partire da s, rispettando le regole: lock ben formato, lock legale, PL Lock acquisiti subito prima di effetturare l operazione B. verifichiamo che lo schedule sia eseguibile e che non dia luogo ad attese su singoli comandi che alterano l ordine dei comandi e quindi rendono lo schedule non Pl NB se nel corso della assegnazione dei lock verifichiamo che qualche regola e violata, possiamo sospendere la analisi.

2 Eseguiamo i due passi r w r w r w A. costruiamo uno schedule con i lock esclusivi a partire da s. Risultato: T T T l r w (qui non possiamo inserire u per non violare PL) l r w (non e rispettata la legalita ) Per rispettare la proprieta di legalita, avremmo dovuto prima fare unlock su, ma allora non possiamo rispettare la proprieta di PL perche la transazione deve ancora effettuare lock su. Lo schedule non e PL Qui chiede il lock prima che To lo rilasci e una delle possibili combinazioni di eventi, dipende dalla velocita relativa dei processi Tuttavia, non si creano deadlock Schedule con richieste di lock lx rx wx lx ly ry ly uy wy uy ux rx wx ux Locks X: X: ( attende ) Y: Y: ( attende ) Y: ( puo procedere) Y: X: ( puo procedere) Schedule originale: r w r w r w Schedule eseguito : r w r w r w Schedule s r w r w r w Schedule s r r Schedule s r w Schedule s r w r r w r w r

3 Schedule s r w r w Schedule s r w r w r r w r w r r w r w Schedule s r w r w r w r w r w r w Schedule S3 - r r3 rz w w3 Le assegnazioni non generano conflitti quindi s e della classe TS Schedule s3 r r3 rz w w3 Caso seriale Lo schedule non e seriale perche le transazioni 3 e effettuano letture e scritture inserite all interno della transazione Schedule s3 r r3 rz w w3 Caso conflict serializable - Costruiamo il grafo dei conflitti: r r3 rz w w3 t t3 Grafo dei conflitti - Lo schedule non appartiene alla classe CSR in quanto il grafo dei conflitti e ciclico 3

4 Schedule s3 r r3 rz w w3 Caso PL Metodo : Costruiamo uno schedule con i lock esclusivi a partire da s, rispettando le regole: lock ben formato, lock legale, PL Se ci riusciamo, lo schedule e PL. Eseguiamo le assegnazioni del lock e unlock r r3 rz w w3 l r l3 r3 lz rz uz l (negato, in coda) l3 (negato, 3 in coda) La richiesta di lock su e negata, altrimenti non verrebbe rispettata la proprieta ldi legalita. Lo schedule non e PL. Nel nuovo schedule che viene eseguito viene negato il lock anche a l3, per cui lo schedule va in deadlock. In questo caso, si crea un deadlock Schedule con richieste di lock lx l3y lz ly l3x T Locks X: Y: 3 Z: Y: 3 ( attende 3) X: 3 (3 attende deadlock) r w Schedule s3 r r3 rz w w3 rz 3 r3 w3 3 z Il comando w della transazione tenta di scrivere in dopo che il comando r3 ha letto in, questo crea conflitto. Lo schedule non appartiene alla classe TS Esercizio. operazioni Risultato timestamps dati commento Si consideri uno scheduler basato su timestamps. Sono date tre transazioni T, T, con i rispettivi timestamps, ottenuti dallo scheduler: ts(t) =, ts(t) = 5, ts() = 75. Descrivere il comportamento dello scheduler rispetto alla seguente sequenza di operazioni: R(B) R(A) R3(C) W(B) W(A) W(C) W3(A) T R(B) W(B) W(A) T R(A) W(C) R(C) W(A) A RT WT 5 75 B RT WT RT 75 C WT 5 T scrive un valore gia' letto da che e' piu' recente => viene terminata sovrascrive un valore gia' scritto da T che e' piu' recente => l'operazione viene ignorata e puo' proseguire 4

5 Esercizio.3 E' dato il seguente schedule S, costituito dalle transazioni T, T, : S = rz r w r3 r3z r w w3 w3z r r w w a) Dire se S e' serializzabile ai conflitti, indicando il suo grafo di precedenza; b) Modificare le transazioni T, T,, inserendo primitive di lock/unlock binario in modo che ciascuna segua il protocollo PL, e in modo che per ciascun item venga acquisito il lock il piu' tardi possibile e rilasciato prima possibile (compatibilmente con le regole PL). Scrivere le tre transazioni cosi' modificate; c) Riscrivere S utilizzando le nuove transazioni con i lock, cercando cioe' di eseguire le operazioni nello stesso ordine indicato da S. Ogni volta che una operazione pone una transazione in attesa su un lock, si passi alle operazioni successive, nell'ordine, delle transazioni che possono proseguire. Indicare la sequenza ottenuta. Che fenomeno si verifica? In che modo lo scheduler potrebbe prevenire tale fenomeno? Domanda a Schedule s rz r w r3 r3z r w w3 w3z r r w w - Costruiamo il grafo dei conflitti: rz r w r3 r3z r w w3 w3z r r w w t t t3 - Lo schedule non appartiene alla classe CSR in quanto il grafo dei conflitti e ciclico Domanda b Lo schedule e rz r w r3 r3z r w w3 w3z r r w w Le transazioni (con le versioni modificate ottenute con le assegnazioni di lock e unlock) sono: Nuovo schedule Lz rz l r w l3 r3 l3z r3z l r w w3 u3 w3z u3z l uz u r l u r w u w u T r w r w -> l r w l u r w u T rz r w r w -> lz rz l r w l uz u r w u r3 r3z w3 w3z -> l3 r3 l3z r3z w3 u3 w3z u3z Eseguiamo il nuovo schedule Lz rz l r w l3 r3 l3z r3z l r w w3 u3 w3z u3z l uz u r l u r w u w u 3 lz rz l r w l3 (attesa) l r w l (attesa) l (attesa deadlock) Si verifica un deadlock Lo scheduler puo prevenire il fenomeno Con la politica di prevenzione descritta a lezione (dettagliare) Appendice Definizioni dei concetti utilizzati negli esercizi 5

6 Schedule Una sequenza di esecuzione di un insieme di transazioni e detta schedule Es e uno schedule la sequenza T: trova posto, T: trova posto; T: alloca posto; T alloca posto Una schedule e seriale se una transazione termina prima che la successiva inizi Lo schedule seguente e seriale T: trova posto, T: alloca posto; T: trova posto; T alloca posto Il precedente non lo e. Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 3 Ruolo dello scheduler Lo scheduler (concurrenc 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 assumiamo 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 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 3 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 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) Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 33 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 34 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 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 35 Conflitti - Parte dal concetto di conflitto tra azioni Due azioni consecutive in uno schedule sono in conflitto se, scambiando il loro ordine, il comportamento di almeno una delle transazioni coinvolte puo cambiare Normalmente, coppie di azioni non confliggono Es. coppie di letture di uno stesso elemento di transazioni diverse Una lettura di una transazione t di un elemento X e una scrittura di una transazione t di un elemento Y X Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier

7 Conflitti - Sono in conflitto le seguenti coppie di azioni: w(a) w(a) due scritture consecutive sullo stesso dato scambiandone l ordine, cambia il valore finale di A r(a) w(a) lettura e scrittura consecutive sullo stesso dato scambiandone l ordine, T legge valori diversi di A (prima e dopo la scrittura da parte di T, rispettivamente) Conflict-equivalence E condizione sufficiente per la serializzabilita Le schedules S, S sono conflict equivalent se S puo essere trasformato in S mediante una sequenza di scambi (swaps) tra azioni non in conflitto tra loro Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 37 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 38 Conflict-equivalence Es. S = r(a) w(a) r(a) w(a) r(b) w(b) r(b) w(b) è conflict serializable. Infatti puo essere trasformata in uno schedule seriale: r(a) w(a) r(b) w(b) r(a) w(a) r(b) w(b) mediante la seguente sequenza di scambi tra azioni non in conflitto: r(a) w(a) r(a) w(a) r(b) w(b) r(b) w(b) r(a) w(a) r(a) r(b) w(a) w(b) r(b) w(b) r(a) w(a) r(b) r(a) w(a) w(b) r(b) w(b) r(a) w(a) r(b) r(a) w(b) w(a) r(b) w(b) r(a) w(a) r(b) w(b) r(a) w(a) r(b) w(b) Conflict-serializabilit Una schedule e conflict serializable se e conflictequivalente ad una schedule seriale Come si verifica la proprieta di conflict serializabilit? Analizzando il grafo di precedenza associato ad una schedule: Data una schedule S su {T,, Tn}: Grafo di precedenza P=( {T,, Tn},E): Ti Tj E se Pi(A), Qj(A) sono azioni in S Pi(A) < S Qj(A) (precedenza nella schedule) Almeno una di P, Q e una operazione di write Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 39 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 4 Esempio di precedence graph S = w3(a) w(c) r(a) w(b) r(c) w(a) r4(a) w4(d) 3 Teorema: P(S) aciclico sse S conflict-serializable 4 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 4 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 4 7

8 PL Two Phase Locking: un protocollo che garantisca a priori la conflict serializabilit, basandosi sul lock delle risorse 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 (dallo scheduler) e inserite all interno dellesequenzedioperazioniwi(a), rj(a) Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 44 Costruzione del PL Definiamo: Transazioni ben formate e schedules legali Protocollo Two phase locking (PL) Transazioni ben formate Regola # 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)... Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 45 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 46 Schedule legale Regola # Schedule S legale: ogni coppia lock unlock in uno schedule deve essere esclusiva: S = l i (A) u i (A) no lj(a) La regola permette di rispettare la semantica dei lock e assegnare ogni risorsa a una transazione alla volta Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 47 Esempio: uso dei lock Le due regole non sono sufficienti a garantire la serializzabilita A B T T 5 5 l(a);read(a) A A+;Write(A);u(A) 5 l(a);read(a) A A;Write(A);u(A) 5 l(b);read(b) B B;Write(B);u(B) 5 l(b);read(b) B B+;Write(B);u(B) 5 Ghost update: Il valore finale di A e B 5 5 L isolamento viene rotto deve comunque essere lo stesso! nonostante i lock Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier

9 Two-Phase Locking Aggiungiamo l ulteriore terza regola di Two Phase Locking (PL): In ogni transazione tutte le richieste di lock precedono tutti gli unlock Ti =.. li(a)... ui(a). Ti =. li(a)... ui(a) no unlocks # locks ottenuti da Ti Two-Phase Locking no locks no unlocks no locks Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 49 Growing Phase Shrinking Phase Time Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 5 Il deadlock Il deadlock Problema comune a tutte le strategie di controllo di concorrenza basate su locking Un deadlock e una condizione in cui due transazioni T e T 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. Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 5 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 5 T l(a) r(a) w(a) l(b) Esempio di deadlock T l(b) r(b) w(b) l(a) Tecniche utilizzate per risolvere i deadlock Uso del timeout Rilevazione dei deadlock Prevenzione dei deadlock In attesa 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 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 53 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier

10 Uso del timeout Viene fissato un tempo t di timeout oltre il quale le transazioni in attesa di lock vengono uccise Molto semplice Criticita T alto risolve tardi i deadlock T basso uccide troppe transazioni Rilevazione del deadlock Costruzione incrementale del grafo di precedenza (Wait-for graph) Lock esclusivi Quando si genera un ciclo scelta della vittima e rollback Es.: l (X) l (Y) r (X) r (Y) l (Y) l (X) X Y T T Ciclo Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 55 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 56 Due diverse politiche per la scelta della transazione da uccidere. Interrompente ( preemptive ) risolve il conflitto uccidendo la transazione che possiede la risorsa. Uccide quelle che hanno fatto meno lavoro Problema: la transazione che ha fatto meno lavoro viene uccisa ripetutamente blocco individuale (starvation) Prevenzione del deadlock: wait-die Ad ogni transazione e assegnato un timestamp: ts(t i ) al momento in cui arriva allo scheduler Regola: in caso di conflitto su un lock, T i puo attendere T j solo se e piu vecchio : ts(t i ) < ts(t j ) Altrimenti subisce un rollback Quindi se ad es. Ti Tj e un nuovo arco: se ts(ti) < ts(tj): nessuna azione di prevenzione se ts(ti) > ts(tj): Ti subisce un rollback Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 57 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 58 Esempio wait-die Altro esempio T wait (ts =) wait? rolled back wait (ts =5) T (ts =) B(T) B(T) B() l (Y) T accede a Y l 3 (X) accede a X l (X) T attende l (X) T attende T l 3 (Y) rolled back Nota: ts tra e 5 T (ts =) (ts =5) T richiede A: aspetta su T o T 3? T (ts =) B(T) B(T) B() l 3 (X) accede a X l (X) T attende l (X) Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 59 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 6

11 Prima opzione: coda FIFO Seconda opzione T ottiene il lock su A solo dopo che T, T 3 terminano, quindi T in coda a T T muore subito T (ts =) (ts =5) T (ts =) T anticipa T, quindi T aspetta solo T 3 ; T poi aspetta T 3 e T... T puo attendere per sempre? T (ts =) (ts =5) T (ts =) Arco ridondante Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 6 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 6 Struttura del lock Manager Tabella dei lock T i Read(A),Write(B) Decide politiche di lock e Scheduler, part I inserisce i lock l(a),read(a),l(b),write(b) Esegue i lock, utilizzando Scheduler, part II la tabella dei lock, se provocano attesa gestisce le code Read(A),Write(B) Relazioni di inclusione tra tipologie di transazioni serializzabili Time stamp Seriali PL Conflict serializzabili DB Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 63 Complementi di Basi di Dati Controllo di Concorrenza Carlo Batini e Paolo Missier 3 64