Tecnologia di un data base server: Controllo della Concorrenza

1. Tecnologia di un data base server: Controllo della Concorrenza Leonardo Mostarda Sea Lab

2. Controllo della concorrenza • La concorrenza delle transazioni consente un uso efficiente del DBMS, massimizzando il tps. • Il controllo di concorrenza fa riferimento al livello più basso che attua il trasferimento di blocchi fra memoria centrale e memoria di massa (r/w). • Le operazioni di r/w sono richieste dallo scheduler.

3. Controllo della concorrenza • Con r(x) si indica la lettura dell’area di memoria contenente il dato x. • Con w(x) si indica la scrittura dell’area di memoria contenente il dato x. • x, y .. Sono oggetti del database su cui verranno effettuate operazioni numeriche • Eseguire transazioni concorrenti aumenta il tps ma può causare problemi.

4. bot r1(x) x=x+1 w1(x) commit bot r2(x) x=x+1 w2(x) commit Anomalia delle transazioni concorrentiperdita di update • Siano date le transazioni: • t1: r1(x), x = x +1, w2(x) t2: r1(x), x = x +1, w2(x)

5. bot r1(x) x=x+1 w1(x) abort bot r2(x) x=x+1 w2(x) commit Anomalia delle transazioni concorrentiLetture sporche • Siano date le transazioni: • t1: r1(x), x = x +1, w2(x) t2: r1(x), x = x +1, w2(x)

6. bot s=0 r1(x) r1(y) s = x + s s = y + s r1(z) s = z + s commit bot r2(z) z=z+10 r2(y) y = y -10 w2(y) w2(z) commit Tecnologia data base server Tre oggetti x y z con definito il vincolo di integirtà x + y + z = 1000

7. Teria della concorrenza • Modello formale di transazione: “sequenza di azioni di lettura o scrittura, che si riconoscono eseguiti da una stessa transazione in quanto caratterizzati dallo stesso indice” • Assunzioni: • si considerano le sole operazioni di lettura e scrittura, omettendo qualsiasi manipolazione dei dati • bot e eof vengono omessi. • non si conosce a priori l’esito della transazione • supponiamo che una transazione non legga o scriva più di una volta la stessa informazione S9 = r1(x) r1(z) w1(x)

8. Teria della concorrenza • Le transazioni avvengono in modo concorrente quindi le letture e scritture sono richieste in istanti successivi da diverse transazioni. • Uno schedule rappresenta la sequenza di operazioni di read e write effettuate da transazioni concorrenti come • w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) • Le operazioni compaiono nello schedule come esse vengono eseguite sulla base di dati • Il controllore di concorrenza a il compito di accettare o meno un determinato schedule, al fine di evitare i problemi esposti.

9. Teria della concorrenza • Lo scheduler effettua il compito di coordinare le esecuzioni parallele: • tiene traccia di tutte le operazioni compiute • accetta o rifiuta le operazioni progressivamente richieste dalle transazioni • produce uno schedule che non contiene i problemi esposti.

10. Teria della concorrenza • Consideriamo inizialmente transazioni con esito noto, questo consente di: • eliminare le transazioni che contengono abort • considerare solo transazioni che eseguono commit (schedule commit proiezione) • Questo tipo di trattazione ha funzionalità teorica dato che: • uno scheduler non conosce a priori l’esito di una transazione • non consente di trattare letture sporche

11. Teria della concorrenza • Schedule seriale “tutte le azioni di una transazione compaiono in sequenza senza essere intercalate da azioni di altre transazioni” w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z) • “L’esecuzione di una commit-proiezione di uno schedule S è corretta quando produce lo stesso risultato di un qualunque schedule seriale contenente le stesse transazioni. In tal caso lo schedule si dice serializzabile.” • Per introdurre la nozione di stesso risultato si introducono diverse nozioni di equivalenza

12. View-equivalenza • Definiamo una relazione leggeda che lega due operazioni: lettura e scrittura. • Un operazione di lettura ri(x)leggeda wk(x) ( leggeda ( ri(x) , wk(x) ) ) quando wk(x) precede ri(x) e non vi è nessun wn(x) compreso fra le due operazioni. • Formalmente leggeda ( ri(x) , wk(x) )  wk(x) < ri(x)    wn(x) | wk(x) < wn(x) < ri(x) S5 = w0(x) r2(x) w2(x) r1(x) w2(z) Non sono in relazione visto che  w2(x) che precede r1(x) e viene effettuata dopo w0(x)

13. View-equivalenza • Un operazione di scrittura wk(x) viene detta finale se è l’ultima scrittura sull’ oggetto x che appare nello schedule. • w0(x) non è l’ultima scrittura sull’oggetto x • w2(x) è una scrittura finale sull’ oggetto x • w2(z) è una scrittura finale sull’ oggetto z S5 = w0(x) r2(x) w2(x) r1(x) w2(z)

14. View-equivalenza • Due schedule vengono detti view-equivalenti ( SiV Sk ) se possiedono la stessa relazione leggeda e le stesse scritture finali. • Uno schedule viene detto view-serializzabile se è view equivalente ad un generico schedule seriale. • VSR è l’insieme degli schedule view-serializzabili.

15. View-equivalenza S5 = w0(x) r2(x) w2(x) r1(x) w2(z) leggeda = { ( r2(x) , w0(x) ) } leggeda = { ( r2(x) , w0(x) ) , ( r1(x) , w2(x) )} scrittura finale di x = w2(x) scrittura finale di z = w2(z) S6 = w0(x) r2(x) w2(x) w2(z) r1(x) leggeda = { ( r2(x) , w0(x) ) } leggeda = { ( r2(x) , w0(x) ) , ( r1(x) , w2(x) )} scrittura finale di x = w2(x) scrittura finale di z = w2(z) S4 = w0(x) r1(x) r2(x) w2(x) w2(z) leggeda = { ( r1(x) , w0(x) ) , ( r2(x) , w0(x) )} scrittura finale di x = w2(x) scrittura finale di z = w2(z) S5V S6 visto che hanno la stessa relazione leggida e le stesse scritture finali S5V S4 visto che non hanno la stessa relazione leggida S6 è uno schedule seriale poiché le azioni di tutte le transazioni sono in sequenza quindi S5 è view-serializzabile

16. View-equivalenza S3 = w0(x) r2(x) r1(x) w2(x) w2(z) leggeda = { ( r2(x) , w0(x) ) , ( r1(x) , w0(x) )} scrittura finale di x = w2(x) scrittura finale di z = w2(z) leggeda = { ( r1(x) , w0(x) ) , ( r2(x) , w0(x) )} S4 = w0(x) r1(x) r2(x) w2(x) w2(z) scrittura finale di x = w2(x) scrittura finale di z = w2(z) S5 = w0(x) r2(x) w2(x) r1(x) w2(z) leggeda = { ( r2(x) , w0(x) ) , ( r1(x) , w2(x) )} scrittura finale di x = w2(x) scrittura finale di z = w2(z)

17. View-equivalenza • Lo schedule S corrisponde alla perdita di update e non è view serializzabile. • Questo corrisponde ad una schedulazione delle transazioni in modo da non ottenere un esecuzione isolata. • In generale, per dimostrare la non view-serializzabilità occorre permutare in tutti i possibili modi le transazioni presenti negli schedule seriali e confrontarli con lo schedule S. S = r1(x) r2(x) w1(x) w2(x) S’ = r1(x) w1(x) r2(x) w2(x) S’ = r2(x) w2(x) r1(x) w1(x)

18. View-equivalenza • Determinare la view-equivalenza di due schedule è un problema lineare: • si determinano le due relazioni leggida • e le scritture finali • Per verificare che uno schedule è view-serializzabile è necessario confrontarlo con tutti i possibili schedule seriali ottenuti permutando le transazioni in esso contenuto. • Determinare se uno schedule è view equivalente ad un qualsiasi schedule seriale è un problema NP-hard • Si preferisce quindi una nozione di equivalenza più stretta che non copre tutti i casi, ma che abbia una complessità inferiore.

19. Conflict-equivalenza • definizione di conflitto: “Due azioni ai e ak si dicono in conflitto (i  k) se entrambe operano sullo stesso oggetto ed almeno una di esse è una write” • r2(x) w1(x) è un conflitto lettura scrittura • w2(x) w1(x) è un conflitto lettura scrittura • r2(x) w2(x) non è un conflitto

20. Conflict-equivalenza • Uno schedule Si è confilt-equivalente ad uno schedule Sj ( Sic Sk ) se presentano le stesse operazioni ed ogni coppia di operazioni in conflitto è nello stesso ordine in entrambi gli schedule. • Uno schedule è confilct serializzabile se esiste uno schedule seriale ad esso conflict equivalente. • CSR è l’insieme di tutti gli schedule per cui esiste uno schedule seriale conflict equivalente.

21. Conflict-equivalenza • CSR è strettamente contenuto in VSR. In altre parole esistono schedule che sono view serializzabili ma non sono conflict serializzabili. • Tutti gli schedule in CSR sono in VSR • Quindi la conflict-serializzabilità è una condizione sufficiente ma non necessaria per la view seriabilizzabilità.

22. Conflict-equivalenza • Domande da porre: • operano sullo stesso oggetto • almeno una delle operazioni è di scrittura • i diverso da j S9 = w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) S10 = w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z)

23. Conflict-equivalenza • Naturalmente enumerare in modo esaustivo tutti gli schedule seriali ripone lo stesso problema. • E’ possibile determinare se uno schedule è conflict-serializzabile mediante il grafo dei conflitti. • Ad ogni transazione dello schedule corrisponde un nodo del grafo S9 = w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) T0 T1 T2 S10 = w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z) T3

24. Conflict-equivalenza • E’ possibile determinare se uno schedule è conflict-serializzabile mediante il grafo dei conflitti. • Ad ogni transazione dello schedule corrisponde un nodo del grafo • Si traccia un arco fra i nodi Ti e Tk se esiste il conflitto ai ak e ai precede ak nello schedule S9 = w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) T0 T1 T2 S10 = w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z) T3

25. Conflict-equivalenza • E’ possibile determinare se uno schedule è conflict-serializzabile mediante il grafo dei conflitti. • Ad ogni transazione dello schedule corrisponde un nodo del grafo • Si traccia un arco fra i nodi Ti e Tk se esiste il conflitto ai ak e ai precede ak nello schedule • Lo schedule è in CSR se e solo se il corrispondente grafo dei conflitti è aciclico S9 = w0(x) r1(x) w0(z) r1(z) r2(x) r3(z) w3(z) w1(x) T0 T1 T2 S10 = w0(x) w0(z) r2(x) r1(x) r1(z) w1(x) r3(z) w3(z) T3

26. Conflict-equivalenza • Nonostante la linearità per determinare se uno schedule sia serializzabile o meno questa tecnica non viene applicata: • il grafo risultante può essere di dimensioni notevoli • La dinamicità vincola in alcuni casi a ricostruire il grafo. • Si sta operando ancora in un contesto commit-proiezione di schedule • I metodi di locking a due fasi e timestamp rimuovono le suddette assunzioni

27. Esercizio 1 • Si consideri il seguente schedule, dove ogni operazione ri/wi si intende effettuata dalla transazione Ti: • r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) • si dica se lo schedule è VSR oppure no, e perché, in termini delle relazioni legge-da e scrittura-finale.

28. Esercizio 1 • r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) • Dire che lo schedule è in VSR equivale a dimostrare che esiste un qualunque schedule seriale view-equivalente ad esso. • La view-equivalenza è definita in terimini delle relazioni: • Un operazione di lettura ri(x)leggeda wk(x) ( leggeda ( ri(x) , wk(x) ) ) quando wk(x) precede ri(x) e non vi è nessun wn(x) compreso fra le due operazioni. • Un operazione di scrittura wk(x) viene detta finale se è l’ultima scrittura sull’ oggetto x che appare nello schedule • soluzione1: permutare in tutti i possibili modi le transazioni presenti negli schedule seriali e confrontarli con lo schedule. • r2(x) w2(t) w2(z) r1(x) r1(t) w1(r) w1(t) w1(y) w3(t) r3(r) r3(x) • r1(x) r1(t) w1(r) w1(t) w1(y) r2(x) w2(z) w2(t) w3(t) r3(r) r3(x) • Potrebbero esserci troppe permutazioni possibili

29. Esercizio 1 • r1(x) r3(x) r2(x) r1(t) w1(r)r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) • Soluzione 2: • A causa della presenza della scrittura del dato r da parte della transazione T1, e la conseguente lettura del dato da parte della transazione T3. la relazione leggeda contiene la coppia w1(r)r3(r) • l’ ipotetico schedule seriale view-equivalente deve quindi avere elencate prima le operazioni delle transazioni T1 poi quelle di T3 per avere la stessa relazione leggeda. • r1(x) r3(x) r2(x) r1(t) w1(r) r3(r) w1(y) w2(t) w2(z) w3(t) w1(t) • ma la relazione T1 è l’ultima a scrivere il dato t quindi l’ ipotetico schedule seriale view-equivalente deve avere elencate prima le operazioni delle transazioni T3 poi quelle di T1 per avere la stessa scrittura finale. • ASSURDO

30. Esercizio 2 • Si consideri il seguente schedule, dove ogni operazione ri/wi si intende effettuata dalla transazione Ti: • r1(x) r3(x) w3(x) r2(x) r2(v) r1(t) w1(r) r3(r) w1(y) w2(z) w3(t) w3(v) w1(t) w3(t) • si dica se lo schedule è VSR, indicando (se esiste) un possibile schedule seriale equivalente. Si svolga l’esercizio, specificando le relazioni legge-da e scrittura-finale.

31. Locking a due fasi • Meccanismi che superano le limitazioni discusse: • Locking a due fasi • Timestamp • Le operazioni di scrittura e lettura sono protette con l’esecuzione di tre primitive: • r_lock • w_lock • unlock

32. DB Locking a due fasi scheduler r_lock1(x) w_lock1(y)r_lock2(z) …… struttura dei dati Lo scheduler riceve una serie di richieste di queste primitive ne determina la correttezza attraverso l’ispezione di una struttura dati

33. DB Locking a due fasi r_lock1(x) r1(x)… r_lock1(x) r1(x) r_lock2(x) r2(x) unlock2(x) unlock1(x) scheduler r_lock1(x) r1(x) unlock1(x)…… struttura dei dati Vincoli sulle operazioni di read: ogni operazione di read è preceduta da un r_lock l’r_lock deve essere seguito da un unlock il lock è condiviso perché su un dato possono essere attivi contemporaneamente più lock

34. DB Locking a due fasi scheduler w_lock1(x) w1(x) unlock1(x)…… w_lock1(x) w1(x) w_lock2(x) w2(x) unlock2(x) unlock1(x) w_lock1(x) w1(x)… w_lock1(x) w1(x) unlock1(x) w_lock2(x) w2(x) unlock2(x) struttura dei dati Vincoli sulle operazioni di write: ogni operazione di write è preceduta da un w_lock il w_lock deve essere seguito da un unlock il lock è esclusivo perché su un dato non possono essere attivi contemporaneamente più lock

35. Locking a due fasi • Proprietà • una transazione si dice ben formata quando rispetta le regole precedentemente illustrate • l’operazione di lock della risorsa può avvenire anche prima rispetto all’effettiva lettura e scrittura • potremmo avere un’unica operazione di lock che di fatto è un lock esclusivo • in generale un lock esclusivo in scrittura consente anche la lettura o si può passare da un lock condiviso ad uno esclusivo.

36. Locking a due fasi • Lo scheduler riceve le richieste di lock dalle transazioni e le concede in base a quelle già precedentemente richieste. • Quando la richiesta di lock viene concessa allora si dice che la risorsa viene acquisita dalla transazione richiedente. • All’ atto dell’ unlock viene rilasciata. • Se la richiesta di lock non viene concessa la transazione viene messa in stato di attesa.

37. Locking a due fasi • La richiesta di lock è caratterizzata dalla transazione richiedente, e dalla risorsa richiesta. • La politcha di decisione per la concessione dei lock e’ rappresentata nella tabella dei conflitti.

38. Locking a due fasi • In generale, lo schedule ottenuto seguendo queste regole non è serializzabile. • Occorre porre delle restrizioni sulle singole transizioni relative all’ordinamento della richiesta dei lock. • Locking a due fasi ( 2PL ): una transazione dopo aver rilasciato un lock non può acquisirne altri.

39. Locking a due fasi Risorse richieste Fase crescente Fase calante t

40. Locking a due fasi • Terema: Se il lock manager rispetta la politica definita nella tabella dei conflitti e le transazioni seguono il 2PL, genera schedule serializzabile. • La classe 2PL contiene gli schedule che soddisfano queste condizioni.

41. Locking a due fasi • Dim: • Dimostriamo che la classe 2PL è strettamente contenuta nella classe CSR • Se uno schedule è in 2PL allora è anche CSR • Supponiamo che lo schedule sia in 2PL sia e non in CSR. S2PL e SCSR. • evidentemente esiste un ciclo t1 t2 t3 t4 t5 t6 ….. tn t1, t1 e t2 operano in modo conflittuale sulla stessa risorsa • quindi t1 deve rilasciare la risorsa a t2 affinchè si possa procedere • il conflitto tn t1 stabilisce che la transazione t1 deve attendere cha la transazione tn rilasci la risorsa prima di acquisirla • Assurdo la transazione t1 non segue il 2PL.

42. Locking a due fasi • Le classi 2PL e CSR non sono equivalenti ci sono schedule in CSR che non sono in 2PL. • r1(x) w1(x) r2(x) w2(x) r3(y) w1(y) Non è 2PL visto che la transazione T1 deve necessariamente rilasciare la risorsa x per T2 e richiedere un lock successivo per la risorsa y. T1 T2 T3

43. bot s=0 r_lock(y) read(y) s = y + s r_lock(z) read(z) s=s+z r_lock(x) read(x) s=s+x unlock(x) unlock(y) unlock(z) commit w_lock(x) w_lock(z) read(x) read(z) x=x+10 z=z-10 write(z) unlock(z) write(x) unlock(x) commit Locking a due fasi Tre oggetti x y z con definito il vincolo di integirtà x + y + z = 1000

44. Timestamp • Semplice ma meno efficace del locking a due fasi • Un timestamp è un evento che viene assiciato ad ogni operazione nel sistema. (ad esempio l’orario) • Il controllo mediante il metodo TS avviene nel seguente modo: • Ad ogni transazione si associa un timestamp che rappresenta il momento di inizio • si accetta uno schedule se e solo riflette l’ordinamento seriale delle transazioni in base al valore del timestamp di ciascuna transazione.

45. Timestamp • Ad ogni oggetto x si associano due indicatori • WTM(x): il ts della transazione con timestamp più grosso che ha eseguito l’ultima scrittura • RTM(x): il ts della transazione con timestamp più grosso che ha eseguito l’ultima lettura • Le richieste che arrivano allo scheduler sono del tipo read(x,ts) e write(x,ts) dove ts è il timestamp della transazione che esegue la lettura o la scrittura.

46. Timestamp • Politica dello scheduler • read(x,ts): se ts < WTM(x) la transazione viene uccisa altrimenti è accettata, RTM(x) è posto al valore massimo fra RTM(x) e ts • write(x,ts): se ts < WTM (x) o ts < RTM(x) la transazione viene uccisa altrimenti viene accettata. WTM(x) viene aggiornato con il valore di ts • Ogni transazione non può leggere o scrivere un dato scritto da una transazione con timestamp superiore • Non può scrivere un dato già letto da una transazione con timestamp superiore

47. Timestamp • read(x,ts): se ts < WTM(x) la transazione viene uccisa altrimenti è accettata, RTM(x) è posto al valore massimo fra RTM(x) e ts • write(x,ts): se ts < WTM (x) o ts < RTM(x) la transazione viene uccisa altrimenti viene accettata. WTM(x) viene aggiornato con il valore di ts • RTM(x)=7 • WTM(x)=5

48. Timestamp • IL metodo TS uccide un elevato numero di transazioni. • Per migliorarlo: • Pre-write: simile ad un lock in scrittura. Vengono rimandate le letture che manderebbero in cattivo esito la scrittura. Fino a quando il valore non viene effettivamente scritto. RTM (x)=0 WTM(x)=0 RTM (x)=4 WTM(x)=0 r2(x) r3(x) r4(x) w1(x) w1(x)r2(x) r3(x) r4(x) La transazione t1 viene uccisa visto che 1<RTM(x)=4 La transazione t1 segnala l’intenzione di effettuare una scrittura

49. Timestamp • Utilizzo delle multiversioni: si mantengono diverse copie dello stesso oggetto una per ogni transazione che lo modifica. • Ogni volta che una transazione genera una nuova copia dell’oggetto x, (la i-esima) viene creata una nuova copia WTMi(x). • RTM(x) rimane globale

50. Timestamp • Regole: • r(x,ts): una lettura è sempre accettata, sia WTMi(x) l’ultima versione aggiornata di x • se ts > i si legge WTMi(x) • altrimenti si sceglie una versione k t.c. WTMk(x) < ts < WTMk+1 (x) • w(x,ts): se ts < RTM si rifiuta la richiesta altrimenti si inserisce la i-esima copia WTMi(x)=ts