Concorrenza, lucidi integrativi

Transcript

1 Concorrenza, lucidi integrativi Paolo Atzeni, gennaio 2001 Anomaly 5: Phantom Transaction t 1 Transaction t 2 bot read salaries of employees in dept A and compute average bot insert new employee in Dept A commit read salaries of employees in dept A and compute average commit 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 2 1

2 Anomaly 5: Phantom, again Transaction t 1 Transaction t 2 bot bool:=(there is BD course) if not bool then insert BD course... commit bot bool:=(there is BD course) if not bool then insert BD course... commit 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 3 CSR e VSR Ogni schedule conflict-serializzabile è view-serializzabile, ma non necessariamente viceversa Controesempio per la non necessità: r1(x) w2(x) w1(x) w3(x) view-serializzabile: view-equivalente a r1(x) w1(x) w2(x) w3(x) non conflict-serializzabile Sufficienza: vediamo 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 4 2

3 CSR implica VSR CSR: esiste schedule seriale conflict-equivalente VSR: esiste schedule seriale view-equivalente Per dimostrare che CSR implica VSR è sufficiente dimostrare che la conflict-equivalenza C implica la view-equivalenza V, cioè che se due schedule sono C allora sono V Quindi, supponiamo S 1 C S 2 e dimostriamo che S 1 V S 2 I due schedule hanno: stesse scritture finali: se così non fosse, ci sarebbero almeno due scritture in ordine diverso e poiché due scritture sono in conflitto i due schedule non sarebbero C stessa relazione legge-da : se così non fosse, ci sarebbero scritture in ordine diverso o coppie lettura-scrittura in ordine diverso e quindi, come sopra sarebbe violata la C 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 5 CSR e aciclicità del grafo dei conflitti Se uno schedule S è CSR allora è C ad uno schedule seriale. Supponiamo le transazioni nello schedule seriale ordinate secondo il TID: t 1, t 2,, t n. Poiché lo schedule seriale ha tutti i conflitti nello stesso ordine dello schedule S, nel grafo di S ci possono essere solo archi (i,j) con i<j e quindi il grafo non può avere cicli, perché un ciclo richiede almeno un arco (i,j) con i>j. Se il grafo di S è aciclico, allora esiste fra i nodi un ordinamento topologico (cioè una numerazione dei nodi tale che il grafo contiene solo archi (i,j) con i<j). Lo schedule seriale le cui transazioni sono ordinate secondo l ordinamento topologico è equivalente a S, perché per tutti i conflitti (i,j) si ha sempre i<j. 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 6 3

4 Controllo della concorrenza in pratica Anche la conflict-serializabilità, pur più rapidamente verificabile, è inutilizzabile in pratica La tecnica sarebbe efficiente se potessimo conoscere il grafo dall inizio, ma così non è: uno scheduler deve operare incrementalmente, cioè ad ogni richiesta di operazione decidere se eseguirla subito oppure fare qualcos altro; non è praticabile mantenere il grafo, aggiornarlo e verificarne l aciclicità ad ogni richiesta di operazione Inoltre, la tecnica si basa sull ipotesi di commit-proiezione In pratica, si utilizzano tecniche che garantiscono la conflict-serializzabilità senza dover costruire il grafo non richiedono l ipotesi della commit-proiezione 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 7 Two-phase locking (2PL) 2PL (Two-Phase Locking, Locking a due fasi ): Protocollo che impone a ciascuna transazione di acquisire tutti i propri lock prima di iniziare a rilasciarne (o, in altre parole, che impedisce l aquisizione di nuovi lock a transazioni che ne abbiano gia rilasciati) Uno scheduler 2PL e e uno scheduler che genera solo schedule 2PL cioe schedule in cui tutte le transazioni rispettano il protocollo 2PL (e gestisce i lock come visto in precedenza) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 8 4

5 2PL e CSR Ogni schedule 2PL e anche conflict serializzabile, ma non necessariamente viceversa Controesempio per la non necessita : r 1 (x) w 1 (x) r 2 (x) w 2 (x) r 3 (y) w 1 (y) Viola 2PL Conflict-serializzabile Sufficienza: vediamo 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 9 2PL implica CSR S schedule 2PL Consideriamo per ciascuna transazione l istante in cui ha tutte le risorse e sta per rilasciare la prima Ordiniamo le transazioni in accordo con questo valore temporale e consideriamo lo schedule seriale corrispondente Vogliamo dimostrare che tale schedule è equivalente ad S: allo scopo, consideriamo un conflitto fra un azione di t i e un azione dei t j con i<j; è possibile che compaiano in ordine invertito in S? no, perché in tal caso t j dovrebbe aver rilasciato la risorsa in questione prima della sua acquisizione da parte di t i 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 10 5

6 Basic timestamp mechanism The scheduler has counters RTM(x) and WTM(x) for each object: RTM(x): the youngest transaction that has read x WTM(x): the youngest transaction that has written x The scheduler receives read and write requests: read(x,ts): if ts < WTM(x) then the request is rejected and the transaction is killed, otherwise the request is accepted and RTM(x) is set equal to the greater of RTM(x) and ts write(x,ts): if ts < WTM(x) or ts < RTM(x) then the request is rejected and the transaction is killed, otherwise the request is accepted and WTM(x) is set equal to ts Each schedule is conflict-equivalent to the serial schedule (induced by the timestamps), so TS implies CSR 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 11 Inefficiencies of TS The method causes the forced abort of a large number of transactions To avoid dirty reads, the system must buffer writes until commit, and this introduces waiting of transactions 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 12 6

7 2PL vs TS Sono incomparabili Schedule in TS ma non in 2PL r 1 (x) w 1 (x) r 2 (x) w 2 (x) r 0 (y) w 1 (y) Schedule in 2PL ma non in TS r 2 (x) w 2 (x)r 1 (x) w 1 (x) Schedule in TS e in 2PL r 1 (x) r 2 (y) w 2 (y) w 1 (x) r 2 (x) w 2 (x) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 13 Comparison 2PL vs TS In 2PL the transactions are put in waiting. In TS they are killed and then restarted The serialization order in 2PL is imposed by locks, while in TS it is imposed by the timestamps The necessity of waiting for the commit of the transaction causes strict 2PL and buffering of writes in TS 2PL can give rise to deadlocks (discussed next) Restarting costs more than waiting: 2PL wins! 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 14 7

8 Granularita dei lock I lock possono essere acquisiti a diversi livelli di granularita : Tutta la base di dati Tutta una relazione Parte di una relazione (con criterio logico e fisico) Singola ennupla Vantaggi e svantaggi: Granularita fine: Riduce le probabilita di conflitto Richiede piu operazioni Granularita grossolano: Il contrario Permette forme di predicate-locking 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 15 Predicate locking Anomalia phantom : Inserimento di una ennupla, dopo aver verificato che non ce ne sia un altra con lo stesso valore della chiave Puo essere evitata con un lock a livello dipredicato Concettualmente, su una parte di relazione che soddisfa una condizione (valore della chiave) in pratica sull indice 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 16 8

9 Tuning dei lock e della granularita Compito del progettista (fisico) e del DBA Parametri a disposizione Granularita ; criteri base: A livello di ennupla per transazioni brevi e locali A livello di pagina per transazioni medie che sfruttino l ordinamento fisico A livello di relazione (o base di dati) per transazioni che ne coinvolgano porzione significativa Soglia (numero massimo di lock) oltre la quale si passa ad una granularita meno fine ( lock escalation ) Dimensione della tabella di lock 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 17 Deadlock resolution techniques A deadlock is a cycle in the wait-for graph which indicates wait conditions between transactions (node=transaction, arc=wait condition). Three techniques: 1. Timeout (most used; problem: choice of timeout with tradeoffs) 2. Deadlock detection 3. Deadlock prevention Deadlock detection: performs the search for cycles in a wait-for graph Deadlock prevention: kills the transactions that could cause a cycle (thus: it overkills) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 18 9

10 Prevenzione dello stallo Si basa su note condizioni necessarie per lo stallo; evitandone almeno una, lo si impedisce hold and wait: in caso di stallo, ci deve essere una transazione con risorse assegnate e in attesa su altre. Per evitare questo si possono assegnare tutte le risorse in blocco a ciascuna transazione. Poco efficiente: occorre attendere che tutte le risorse siano libere. circular wait: ci deve essere una situazione di attesa circolare. Per evitare questo si considerano i timestamp delle transazioni, e si impone che una transazione possa porsi in attesa solo su un dato detenuto da una transazione piu giovane, altrimenti una delle due deve essere abortita. Causa un numero eccessivo di restart (molto superiore al rischio di stallo) ed e difficile scegliere la vittima (con rischio di blocco individuale, o starvation). 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 19 Isolation levels offered by SQL2 Some transactions are defined as read-only (they can t request exclusive locks and cannot write [except for temporary ones]) The level of isolation can be set for each transactions Read uncommitted no concurrency control, allows all anomalies Read committed avoids dirty reads and lost updates, but not inconsistent reads and phantoms Repeatable read allows phantoms, avoids other anomalies Serializable avoids all anomalies 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 20 10

11 Isolation levels, come sono realizzati Read uncommitted non richiede niente (e ammesso solo per transazioni read-only) Read committed rispetta gli altrui lock in scrittura (mantenuti fino al commit) Repeatable read 2PL, ma senza predicate lock Serializable 2PL e predicate lock 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 21 Isolation levels, commenti Le definizioni sono diventate standard di recente, ma la terminologia e variegata (e incoerente) guardare i manuali! Level 0, Level 1, Level 2, Level 3 (o Degree 0, ) Read uncommitted, Read committed, Repeatable read, Serializable Read uncommitted, Cursor stability, Read stability, Repeatable read 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 22 11

12 Concorrenza, lucidi integrativi Paolo Atzeni, gennaio 2001 Anomaly 5: Phantom Transaction t 1 Transaction t 2 bot read salaries of employees in dept A and compute average bot insert new employee in Dept A commit read salaries of employees in dept A and compute average commit 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 2 1

13 Anomaly 5: Phantom, again Transaction t 1 Transaction t 2 bot bool:=(there is BD course) if not bool then insert BD course... commit bot bool:=(there is BD course) if not bool then insert BD course... commit 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 3 CSR e VSR Ogni schedule conflict-serializzabile è view-serializzabile, ma non necessariamente viceversa Controesempio per la non necessità: r1(x) w2(x) w1(x) w3(x) view-serializzabile: view-equivalente a r1(x) w1(x) w2(x) w3(x) non conflict-serializzabile Sufficienza: vediamo 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 4 2

14 CSR implica VSR CSR: esiste schedule seriale conflict-equivalente VSR: esiste schedule seriale view-equivalente Per dimostrare che CSR implica VSR è sufficiente dimostrare che la conflict-equivalenza C implica la view-equivalenza V, cioè che se due schedule sono C allora sono V Quindi, supponiamo S 1 C S 2 e dimostriamo che S 1 V S 2 I due schedule hanno: stesse scritture finali: se così non fosse, ci sarebbero almeno due scritture in ordine diverso e poiché due scritture sono in conflitto i due schedule non sarebbero C stessa relazione legge-da : se così non fosse, ci sarebbero scritture in ordine diverso o coppie lettura-scrittura in ordine diverso e quindi, come sopra sarebbe violata la C 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 5 CSR e aciclicità del grafo dei conflitti Se uno schedule S è CSR allora è C ad uno schedule seriale. Supponiamo le transazioni nello schedule seriale ordinate secondo il TID: t 1, t 2,, t n. Poiché lo schedule seriale ha tutti i conflitti nello stesso ordine dello schedule S, nel grafo di S ci possono essere solo archi (i,j) con i<j e quindi il grafo non può avere cicli, perché un ciclo richiede almeno un arco (i,j) con i>j. Se il grafo di S è aciclico, allora esiste fra i nodi un ordinamento topologico (cioè una numerazione dei nodi tale che il grafo contiene solo archi (i,j) con i<j). Lo schedule seriale le cui transazioni sono ordinate secondo l ordinamento topologico è equivalente a S, perché per tutti i conflitti (i,j) si ha sempre i<j. 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 6 3

15 Controllo della concorrenza in pratica Anche la conflict-serializabilità, pur più rapidamente verificabile, è inutilizzabile in pratica La tecnica sarebbe efficiente se potessimo conoscere il grafo dall inizio, ma così non è: uno scheduler deve operare incrementalmente, cioè ad ogni richiesta di operazione decidere se eseguirla subito oppure fare qualcos altro; non è praticabile mantenere il grafo, aggiornarlo e verificarne l aciclicità ad ogni richiesta di operazione Inoltre, la tecnica si basa sull ipotesi di commit-proiezione In pratica, si utilizzano tecniche che garantiscono la conflict-serializzabilità senza dover costruire il grafo non richiedono l ipotesi della commit-proiezione 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 7 Two-phase locking (2PL) 2PL (Two-Phase Locking, Locking a due fasi ): Protocollo che impone a ciascuna transazione di acquisire tutti i propri lock prima di iniziare a rilasciarne (o, in altre parole, che impedisce l aquisizione di nuovi lock a transazioni che ne abbiano gia rilasciati) Uno scheduler 2PL e e uno scheduler che genera solo schedule 2PL cioe schedule in cui tutte le transazioni rispettano il protocollo 2PL (e gestisce i lock come visto in precedenza) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 8 4

16 2PL e CSR Ogni schedule 2PL e anche conflict serializzabile, ma non necessariamente viceversa Controesempio per la non necessita : r 1 (x) w 1 (x) r 2 (x) w 2 (x) r 3 (y) w 1 (y) Viola 2PL Conflict-serializzabile Sufficienza: vediamo 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 9 2PL implica CSR S schedule 2PL Consideriamo per ciascuna transazione l istante in cui ha tutte le risorse e sta per rilasciare la prima Ordiniamo le transazioni in accordo con questo valore temporale e consideriamo lo schedule seriale corrispondente Vogliamo dimostrare che tale schedule è equivalente ad S: allo scopo, consideriamo un conflitto fra un azione di t i e un azione dei t j con i<j; è possibile che compaiano in ordine invertito in S? no, perché in tal caso t j dovrebbe aver rilasciato la risorsa in questione prima della sua acquisizione da parte di t i 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 10 5

17 Basic timestamp mechanism The scheduler has counters RTM(x) and WTM(x) for each object: RTM(x): the youngest transaction that has read x WTM(x): the youngest transaction that has written x The scheduler receives read and write requests: read(x,ts): if ts < WTM(x) then the request is rejected and the transaction is killed, otherwise the request is accepted and RTM(x) is set equal to the greater of RTM(x) and ts write(x,ts): if ts < WTM(x) or ts < RTM(x) then the request is rejected and the transaction is killed, otherwise the request is accepted and WTM(x) is set equal to ts Each schedule is conflict-equivalent to the serial schedule (induced by the timestamps), so TS implies CSR 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 11 Inefficiencies of TS The method causes the forced abort of a large number of transactions To avoid dirty reads, the system must buffer writes until commit, and this introduces waiting of transactions 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 12 6

18 2PL vs TS Sono incomparabili Schedule in TS ma non in 2PL r 1 (x) w 1 (x) r 2 (x) w 2 (x) r 0 (y) w 1 (y) Schedule in 2PL ma non in TS r 2 (x) w 2 (x)r 1 (x) w 1 (x) Schedule in TS e in 2PL r 1 (x) r 2 (y) w 2 (y) w 1 (x) r 2 (x) w 2 (x) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 13 Comparison 2PL vs TS In 2PL the transactions are put in waiting. In TS they are killed and then restarted The serialization order in 2PL is imposed by locks, while in TS it is imposed by the timestamps The necessity of waiting for the commit of the transaction causes strict 2PL and buffering of writes in TS 2PL can give rise to deadlocks (discussed next) Restarting costs more than waiting: 2PL wins! 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 14 7

19 Granularita dei lock I lock possono essere acquisiti a diversi livelli di granularita : Tutta la base di dati Tutta una relazione Parte di una relazione (con criterio logico e fisico) Singola ennupla Vantaggi e svantaggi: Granularita fine: Riduce le probabilita di conflitto Richiede piu operazioni Granularita grossolano: Il contrario Permette forme di predicate-locking 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 15 Predicate locking Anomalia phantom : Inserimento di una ennupla, dopo aver verificato che non ce ne sia un altra con lo stesso valore della chiave Puo essere evitata con un lock a livello dipredicato Concettualmente, su una parte di relazione che soddisfa una condizione (valore della chiave) in pratica sull indice 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 16 8

20 Tuning dei lock e della granularita Compito del progettista (fisico) e del DBA Parametri a disposizione Granularita ; criteri base: A livello di ennupla per transazioni brevi e locali A livello di pagina per transazioni medie che sfruttino l ordinamento fisico A livello di relazione (o base di dati) per transazioni che ne coinvolgano porzione significativa Soglia (numero massimo di lock) oltre la quale si passa ad una granularita meno fine ( lock escalation ) Dimensione della tabella di lock 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 17 Deadlock resolution techniques A deadlock is a cycle in the wait-for graph which indicates wait conditions between transactions (node=transaction, arc=wait condition). Three techniques: 1. Timeout (most used; problem: choice of timeout with tradeoffs) 2. Deadlock detection 3. Deadlock prevention Deadlock detection: performs the search for cycles in a wait-for graph Deadlock prevention: kills the transactions that could cause a cycle (thus: it overkills) 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 18 9

21 Prevenzione dello stallo Si basa su note condizioni necessarie per lo stallo; evitandone almeno una, lo si impedisce hold and wait: in caso di stallo, ci deve essere una transazione con risorse assegnate e in attesa su altre. Per evitare questo si possono assegnare tutte le risorse in blocco a ciascuna transazione. Poco efficiente: occorre attendere che tutte le risorse siano libere. circular wait: ci deve essere una situazione di attesa circolare. Per evitare questo si considerano i timestamp delle transazioni, e si impone che una transazione possa porsi in attesa solo su un dato detenuto da una transazione piu giovane, altrimenti una delle due deve essere abortita. Causa un numero eccessivo di restart (molto superiore al rischio di stallo) ed e difficile scegliere la vittima (con rischio di blocco individuale, o starvation). 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 19 Isolation levels offered by SQL2 Some transactions are defined as read-only (they can t request exclusive locks and cannot write [except for temporary ones]) The level of isolation can be set for each transactions Read uncommitted no concurrency control, allows all anomalies Read committed avoids dirty reads and lost updates, but not inconsistent reads and phantoms Repeatable read allows phantoms, avoids other anomalies Serializable avoids all anomalies 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 20 10

22 Isolation levels, come sono realizzati Read uncommitted non richiede niente (e ammesso solo per transazioni read-only) Read committed rispetta gli altrui lock in scrittura (mantenuti fino al commit) Repeatable read 2PL, ma senza predicate lock Serializable 2PL e predicate lock 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 21 Isolation levels, commenti Le definizioni sono diventate standard di recente, ma la terminologia e variegata (e incoerente) guardare i manuali! Level 0, Level 1, Level 2, Level 3 (o Degree 0, ) Read uncommitted, Read committed, Repeatable read, Serializable Read uncommitted, Cursor stability, Read stability, Repeatable read 29/01/2001 Paolo Atzeni, Concorrenza, lucidi integrativi 22 11