La gestione della concorrenza

Transcript

1 La gestione della concorrenza R. A. Elmasri, S. B. Navathe (Addison Wesley - Pearson) Sistemi di Basi di dati Complementi Capitolo 1 e Capitolo 2 Appunti dalle lezioni Transazione Transazioni e tecnologie di supporto Gestione della concorrenza Gestione della affidabilità La gestione della concorrenza 2 1

2 Isolamento Per migliorare i tempi medi di risposta (TpS), è necessario eseguire più transazioni in maniera concorrente. La proprietà di isolamento garantisce che: il risultato di un insieme di transazioni eseguite in maniera concorrente è in qualche modo equivalente (?) a quello che si otterrebbe se le transazioni fossero eseguite una dopo l altra. venga evitato il Rollback a catena l abort di una transazione provoca l abort di un altra transazione e così via; il Rollback a catena sarebbe particolarmente pericoloso qualora coinvolgesse transazioni che hanno già effettuato il commit. La gestione della concorrenza 3 Anomalie delle Transazioni Concorrenti Perdita di Update Letture sporche Update fantasma Letture inconsistenti Le illustreremo con riferimento ad un oggetto che può essere Un attributo di una tupla Una tupla Un blocco di disco Una tabella L intera base dati La gestione della concorrenza 4 2

3 Anomalie delle Transazioni Concorrenti T1 r(x) x = x+1 w(x) commit Perdita di Update T2 r(x) x = x+1 w(x) commit T1 r(x) x = x + 1 w(x) abort Letture Sporche T2 r(x) x = x+1 w(x) commit La gestione della concorrenza 5 Anomalie delle Transazioni Concorrenti T1 r(x) r(y) r(z) somma=x+y+z commit Update Fantasma T2 r(y) y = y-500 r(z) z = z+500 w(y) w(z) commit T1 r(x) Letture Inconsistenti r(x) commit T2 r(x) x = x+1 w(x) commit La gestione della concorrenza 6 3

4 Teoria Della Concorrenza Il gestore della concorrenza è lo strato più interno di un DBMS. Si occupa di trasferire: blocchi in memoria centrale (read); pagine verso la memoria di massa (write). Scheduler: gestisce le operazioni di lettura/scrittura. La gestione della concorrenza 7 Equivalenza di Scheduling E un concetto complesso Si considerino 2 transazioni T1 e T2. Esistono 2 scheduling sequenziali: T1 T2 T2 T1 n è detto che essi forniscano lo stesso risultato. T1 Update CC set saldo = 0 Commit T2 Update CC set saldo = saldo + 30 Commit La gestione della concorrenza 8 4

5 Soluzioni possibili Uno scheduling è considerato corretto se è equivalente a UNO dei possibili scheduling sequenziali Soluzioni: Protocollo 2 phase locking (2PL) Tecnica basata sui timestamps Tecniche multi-versione Tecniche ottimistiche La gestione della concorrenza 9 Lock Dato Un oggetto della base dati L intera base dati, una tabella, una riga, un attributo Lock Una variabile associata ad un dato che ne descrive lo stato con riferimento alle varie operazioni che ad esso possono essere applicate. Lock binari Due stati: locked/unlocked Troppo restrittivo La gestione della concorrenza 10 5

6 Lock Shared/Exclusive lock: Permettere a più transazioni di accedere allo stesso dato per scopi di sola lettura Se una transazione deve modificare un dato, allora deve averne il controllo esclusivo Primitive: r_lock w_lock unlock. La gestione della concorrenza 11 La gestione dei lock Stato R_locked W_locked Free R_lock OK / r_locked NO / W_locked OK / r_locked Richiesta W_lock NO/ r_locked NO / w_locked OK / w_locked Unlock OK / dipende OK / free error I lock garantiscono che sui dati si operi in maniera mutuamente esclusiva. n garantiscono in alcun modo la serializzabilità. La gestione della concorrenza 12 6

7 Esempio: Perdita di Update T1 RL(x)/r(x)/UL(x) x = x+1 T2 RL(x)/r(x)/UL(x) x = x+1 WL(x)/w(x)/UL(x) commit WL(x)/w(x)/UL(x) commit La gestione della concorrenza 13 Il protocollo 2PL Lo scheduler diventa un lock manager che riceve richieste di lock e decide il da farsi. Transazione ben formata rispetto al locking: ogni operazioni di lettura è preceduta da un r_lock e seguita da un unlock; ogni operazioni di scrittura è preceduta da un w_lock e seguita da un unlock; proprietà garantita di compilatori. La gestione della concorrenza 14 7

8 Il protocollo 2PL Una transazione, dopo aver rilasciato un lock, non può acquisirne altri. In una transazione esiste La fase crescente i lock vengono acquisiti la fase calante i lock vengono rilasciati. E concesso l incremento di lock. La gestione della concorrenza 15 Esempio: Perdita di Update T1 WL(x)/r(x) x = x+1 w(x)/ul(x) T2 WL(x) r(x) x = x+1 w(x)/ul(x) Commit Commit La gestione della concorrenza 16 8

9 Letture Sporche non risolte T1 WL(x)/r(x) x=x+1 w(x)/unlock(x) T2 WL(x)/r(x) x=x+1 w(x)/unlock(x) commit abort La gestione della concorrenza 17 2PL stretto Il problema è legato all ipotesi di Commit Proiezione che è alla base della teoria della concorrenza. Nei sistemi reali tale ipotesi deve, per forza di cose, essere abbandonata. 2PL stretto: al 2PL si aggiunge l ulteriore condizione che le risorse possono essere rilasciate solo dopo il commit/abort. La gestione della concorrenza 18 9

10 Deadlock Il meccanismo dei lock introduce un problema: siano T1 e T2 due transazioni; supponiamo che entrambe operino in scrittura su 2 oggetti x e y; T1 blocca x in scrittura; T2 blocca y in scrittura; T1 aspetta che T2 liberi y; T2 aspetta che T1 liberi x. La situazione può durare all infinito. La gestione della concorrenza 19 Deadlock: Prevention Tecnica di prevenzione esatta: le transazione acquisiscono le risorse di cui hanno bisogno in un colpo solo; se qualche risorsa non è disponibile, non viene assegnata nessuna risorsa. Problemi: non sempre una transazione sa in partenza ciò di cui avrà bisogno; si rischia di bloccare troppi oggetti inutilmente. La gestione della concorrenza 20 10

11 Deadlock: Prevention Tecnica approssimata: tutte le transazioni richiedono i lock nello stesso ordine; non sempre la transazione conosce tutto quello di cui avrà bisogno; Tecnica approssimata: ad ogni transazione è associato un timestamp; se un lock non è concesso, la transazione aspetta solo se essa è più giovane della transazione che detiene il lock; i deadlock sono eliminati ma possiamo avere starvation Una transazione viene continuamente uccisa La gestione della concorrenza 21 Deadlock: Detection n si pongono vincoli alle transazioni. Ad intervalli prefissati il contenuto della tabella dei lock è esaminato e comparato con le richieste pendenti. Si costruisce un grafo delle richieste. Se in tale grafico esiste un ciclo, c è un deadlock. Il ciclo deve essere spezzato uccidendo almeno una transazione. T1 T6 T7 T3 T5 T2 T8 La gestione della concorrenza 22 11

12 Deadlock: Time-Out E la tecnica più semplice e più usata. Ad richiesta di lock è associato un tempo massimo di attesa. Scaduto tale tempo, la richiesta si intende rifiutata e la transazione uccisa. La gestione della concorrenza 23 Granularità dei lock I lock entrano in tutti i metodi. E importante gestirli in maniera efficiente. Cosa blocco? Attributo Granularità fine Base Dati Granularità grossa La granularità ottimale dipende dalla transazione che sto eseguendo Un DBMS supporta diverse granularità e la possibilità di scegliere (in maniera più o meno trasparente all utente) cosa bloccare BD Table 1.. Table n Blocco 1.. Tupla 1.. Attributo 1.. Blocco n Tupla n Attributo n La gestione della concorrenza 24 12

13 Lock gerarchici IS (Intention Shared) Saranno richiesti uno o più lock condivisi su qualche nodo discendente IX (Intention Exclusive) Saranno chiesti uno o più lock esclusivi su qualche nodo discendente SIX (Shared Intension Exclusive) Si richiede il blocco del nodo corrente in maniera condivisa e si annuncia che qualche nodo discendente sarà bloccato in maniera esclusiva La gestione della concorrenza 25 Lock gerarchici Stato Richiesta IS IX S SIX X IS OK OK OK OK IX OK OK S OK OK SIX OK X La gestione della concorrenza 26 13

14 2PL a granularità multipla Si parte dalla radice dell albero Un nodo N può essere bloccato in modalità S o IS solo se il padre è bloccato in modalità IS o IX Un nodo N può essere bloccato in modalità X o IX solo se il padre è bloccato in modalità IX o SIX Una transazione può bloccare un nodo solo se non ne ha sbloccato altri Una transazione T può sbloccare un nodo N solo se T non blocca nessuno dei figli di N La gestione della concorrenza 27 Timestamps Timestamp Identificatore numerico assegnato dal DBMS ad ogni transazione TS(T1)<TS(T2) T1 è iniziata prima di T2 Idea base del Timestamp Ordering Ordinare le transazioni in base ai loro timestamps La gestione della concorrenza 28 14

15 Basic Timestamp ordering Ad ogni oggetto X del DB vengono associati Read_TS Valore del TS della transazione più giovane (TS più elevato) tra le transazioni che hanno letto X Write_TS Valore del TS della transazione più giovane (TS più elevato) tra le transazioni che hanno modificato X La gestione della concorrenza 29 Basic Timestamp ordering La transazione T con timestamp TS chiede di leggere X Se Write_TS(X) > TS T vuole leggere qualcosa scritto da una transazione più giovane La transazione viene annullata e risottomessa al sistema con un nuovo timestamp Altrimenti L operazione di scrittura viene concessa Read_TS(X) = max {Read_TS(X),TS} La gestione della concorrenza 30 15

16 Basic Timestamp ordering La transazione T con timestamp TS chiede di scrivere X Se Read_TS(X) > TS oppure Il dato è stato già letto da una transazione più giovane Se Write_TS(X) > TS Il dato è stato già scritto da una transazione più giovane La transazione viene annullata e risottomessa al sistema con un nuovo timestamp Altrimenti L operazione di scrittura viene concessa Write_TS(X) = TS La gestione della concorrenza 31 Strict Timestamp ordering La versione basic dell algoritmo non ci tutela dai rollback a cascata Versione Strict L operazione di lettura o scrittura di T su X viene ritardata fino a che l ultima transazione T1 che ha scritto X non è terminata (con un committ o con un abort) Tale meccanismo è implementato tramite lock n si generano deadlock in quanto T attende solamente se TS(T) > TS(T1) La gestione della concorrenza 32 16

17 Tecniche multi-versione (MVCC) Ogni volta che un oggetto X viene aggiornato, si tiene traccia anche del suo vecchio valore. X {X 1,X 2, X n } Idea base: Alcune operazioni di lettura rifiutate, ad esempio con una tecnica timestamp, potrebbero essere accettate leggendo una versione più vecchia. La gestione della concorrenza 33 MVCC basato su 2PL Il meccanismo di base è lo strict 2PL Qui, se una transazione ha il WL su un oggetto, le altre non possono né leggerlo né scriverlo. Idea: Manteniamo, per ogni oggetto X, due versioni X1: versione scritta da una transazione che ha eseguito il commit (versione committed) X2: create nel momento in cui una transazione T acquisisce il lock in scrittura La gestione della concorrenza 34 17

18 MVCC basato su 2PL Mentre T detiene il lock in scrittura Le altre che vogliono leggere X leggono la versione committed X1 Quando T vuole fare il commit deve ottenere un certify lock su ogni elemento su cui ha un WL. E un lock esclusivo La gestione della concorrenza 35 MVCC basato su timestamps X {X 1,X 2, X n } Alla generica copia X i Read_TS(X i ) TS della transazione più giovane che ha letto Write_TS(X i ) TS della transazione che ha scritto X i La gestione della concorrenza 36 18

19 MVCC basato su timestamps T richiede di leggere X La richiesta è sempre accettata Il valore letto è l X i tale che Il suo Write_TS(X i ) è il più grande che sia anche minore o uguale di TS(T) La gestione della concorrenza 37 MVCC basato su timestamps T richiede di scrivere X Sia X i : Il suo Write_TS(X i ) è il più grande che sia anche minore o uguale di TS(T) Se TS(T) < Read_TS(X i ) Abort di T Altrimenti Crea una nuova copia di X (X n+1 ) Read_TS(X n+1 ) = Write_TS(X n+1 ) = TS(T) Ancora una volta si presenta il problema dei rollback a catena per cui bisogna prevedere meccanismi di ritardo. La gestione della concorrenza 38 19

20 Tecniche ottimistiche Tecniche di validazione o certificazione. n si attua alcun controllo durante la transazione. Particolarmente efficaci per: Transazioni con basso livello di interferenza. Transazioni che leggono soltanto. La gestione della concorrenza 39 Tecniche ottimistiche Fase di lettura: Si leggono valori committed e le modifiche vengono applicate a copie locali. Se la transazione chiede il committ: Fase di validazione: Ci si assicura che applicare le modifiche non violi la serializzabilità. Fase di scrittura: Se la validazione è superata, le modifiche vengono riportate alla base dati. Altrimenti le modifiche sono scartate e la transazione è riavviata. La gestione della concorrenza 40 20

21 Fase di validazione: esempio Ad ogni transazione viene associato un timestamp. Per ogni transazione si mantiene anche: L istante di inizio e di fine delle tre fasi. Il write-set L elenco degli oggetti che essa scrive Il read-set L elenco degli oggetti che essa legge La gestione della concorrenza 41 Fase di validazione di T Sia TC l insieme delle transazioni che Ha effettuato il commit E in fase di validazione Entra in validazione TC = TC T T viene confrontata con ogni T j TC: T T j Passare la fase di validazione significa passare la validazione nei confronti di ogni T j La gestione della concorrenza 42 21

22 Fase di validazione di T verso T j La validazione di T verso T j è passata se: T j completa la sua fase di scrittura prima che T i inizi la sua fase di lettura Se T j completa la sua fase di scrittura prima che T inizi la sua fase di scrittura WS(T j ) RS(T) = Se T j completa la sua fase di lettura prima che T completi la sua fase di lettura WS(T j ) RS(T) = WS(T j ) WS(T) = Altrimenti T viene uccisa e riavviata. La gestione della concorrenza 43 Livello di isolamento delle Transazioni Il livello di isolamento di una transazione determina il comportamento della stessa. Io posso decidere di accettare alcune anomalie per andare più veloce Uncommitted Read Committed Read Repeatable Read Serializable Sono da intendersi come requisiti al negativo La gestione della concorrenza 44 22

23 Uncommitted Read La transazione accetta di leggere dati modificati da una transazione che non ha ancora fatto il commit Se usiamo il 2PL: Ignora i lock esclusivi in lettura n acquisisce i lock in lettura. Deve però acquisire i lock in scrittura La gestione della concorrenza 45 Committed Read La transazione non legge dati cambiati da una transazione che non ha ancora fatto il commit. Se però essa legge due volte lo stesso dato, può trovare dati diversi. n blocca i dati che legge La gestione della concorrenza 46 23

24 Repeatable Read Si aggiunge al commited read la caratteristica che, se un dato è letto due volte, si avrà sempre lo stesso risultato. Si applica il 2PL stretto Le righe realmente lette non possono essere modificate o cancellate. Possono però essere aggiunte righe anche nell intervallo specificato nella clausola where della transazione che legge. Tutti i dati letti sono read_locked; Un insert non interferisce con questi lock La gestione della concorrenza 47 Serializable Si aggiunge al repeatable read la caratteristica che, se una query è fatta due volte, non vengono aggiunte righe. n sono possibili modifiche neanche all interno dell intervallo coperto nella lettura. Il SERIALIZABLE blocca cioè intervalli di dati, inclusi quelli di fatto non esistono, impedendo cioè che vengano effettuati insert. La gestione della concorrenza 48 24

25 Gestione della concorrenza in PostgreSQL 9.0 Capitolo 13 del manuale Data consistency is maintained by using a multi-version model. This means that while querying a database each transaction sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data. This protects the transaction from viewing inconsistent data that could be caused by (other) concurrent transaction updates on the same data rows, providing transaction isolation for each database session. MVCC, by eschewing explicit locking methodologies of traditional database systems, minimizes lock contention in order to allow for reasonable performance in multiuser environments. The main advantage of using the MVCC rather than locking is that in MVCC locks acquired for reading data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading. La gestione della concorrenza 49 Isolation Levels in PostgreSQL 9.0 You can request any of the four standard transaction isolation levels. Internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you really get Read Committed When you select Repeatable Read you really get Serializable, so the actual isolation level might be stricter than what you select. This is permitted by the SQL standard: the four isolation levels only define which phenomena must not happen, they do not define which phenomena must happen. The reason that PostgreSQL only provides two isolation levels is that this is the only sensible way to map the standard isolation levels to the multiversion concurrency control architecture. La gestione della concorrenza 50 25

26 Isolation Levels in PostgreSQL 9.0 Read Committed is the default isolation level in PostgreSQL start transaction isolation level read uncommitted; start transaction isolation level read committed; start transaction isolation level read committed; start transaction isolation level read committed; set transaction isolation level read uncommitted; set transaction isolation level read committed; set transaction isolation level read committed; set transaction isolation level read committed; La gestione della concorrenza 51 Locks in PostgreSQL 9.0 Table- and row-level locking facilities are also available in PostgreSQL for applications that cannot adapt easily to MVCC behavior. However, proper use of MVCC will generally provide better performance than locks. In addition, application-defined advisory locks provide a mechanism for acquiring locks that are not tied to a single transaction. La gestione della concorrenza 52 26

27 Locks in PostgreSQL 9.0 Locks a livello di tabella LOCK [ TABLE ] [ ONLY ] name [,...] [ IN lockmode MODE ] [ NOWAIT ] lockmode: ACCESS SHARE ROW SHARE ROW EXCLUSIVE SHARE UPDATE EXCLUSIVE SHARE SHARE ROW EXCLUSIVE EXCLUSIVE ACCESS EXCLUSIVE ACCESS SHARE ACCESS EXCLUSIVE n esiste l Unlock! La gestione della concorrenza 53 Locks in PostgreSQL 9.0 Locks a livello di riga SELECT FOR SHARE.. SELECT FOR UPDATE. n esiste l Unlock! La gestione della concorrenza 54 27

28 Isolation levels in JDBC int Connection.getIsolationLevel(); Void Connection.setIsolationLevel(int) TRANSACTION_NONE TRANSCTION_READ_UNCOMMITTED TRANSCTION_READ_COMMITTED TRANSACTION_REPETEABLE_READ TRANSACTION_SERIALIZABLE La gestione della concorrenza 55 La gestione della concorrenza 56 28