Tratti dal cap. 9 di: Atzeni, Ceri, Paraboschi, Torlone Basi di Dati II edizione, 1999, McGraw-Hill

/XFLGLVXOFRQWUROORGHOODFRQFRUUHQ]D Tratti dal cap. 9 di: Atzeni, Ceri, Paraboschi, Torlone Basi di Dati II edizione, 1999, McGraw-Hill

$QRPDOLD /RVW8SGDWH Si considerino le due transazioni identiche: W1 : Ux), [= [+ 1, Zx) W2 : Ux), [= [+ 1, Zx) Si assuma inizialmente [=2; dopo un esecuzione seriale: [=4 Si consideri l esecuzione concorrente: Transaction W 1 Transaction W bot U 1([) [= [+ 1 bot U 2([) [= [+ 1 Z 1([) commit Z 2 [) commit Un update e perso. Valore finale [=3

$QRPDOLD 'LUW\UHDG Si considerino le medesime transazioni e la seguente esecuzione (si noti che la prima transazione fallisce): Transaction W 1 Transaction W 2 bot U 1([) [= [+ 1 Z 1([) bot U 2([) [= [+ 1 abort Z 2 [) commit W 2 legge uno stato intermedio (dirty read)

$QRPDOLD,QFRQVLVWHQWUHDG W 1 ripete due letture: Transaction W 1 Transaction W 2 bot U 1([) bot U 2([) [= [+ 1 Z 2 [) commit U 1([) commit W 1 legge valori differenti per [

$QRPDOLD *KRVWXSGDWH Si assuma che valga il vincolo d integrita : [+ \+ ]= 1000; Transaction W 1 Transaction W 2 bot U 1([) bot U 2 \) U 1 \) \= \- 100 U 2 ]) ]= ]+ 100 Z 2 \) Z 2 ]) commit U 1(]) V= [+ \+ ] commit Alla fine V = 110: il vincolo non e soddisfatto W 1 vede un ghost update

/RFNLQJDGXHIDVL Usato da molti DBMS commerciali Principio: Tutte le operazioni di lettura sono precedute da una UBORFk (lock condiviso) e seguite da una XQORFk Tutte le operazioni di scrittura sono precedute da una ZBORFk (lock esclusivo) e seguite da una XQORFk Una transazione che segue queste regole e EHQIRUPDWD ULVSHWWRDOORFNLQg Quando una transazione legge e poi scrive un oggetto puo : Usare un write lock Promuovere un lock condiviso ad un lock esclusivo(orfn HVFDODWLRn) Il ORFNPDQDJHr riceve queste primitive dalle transazioni e concede le risorse secondo una politica indicata dalla tabella dei conflitti Quando un lock e concesso, la risorsa e acquisita Con una unlock, la risorsa e rilasciata

&RPSRUWDPHQWRGHOORFNPDQDJHU Conflict table: 5HTXHVW 5HVRXUFHVWDWH IUHH UBORFNHG ZBORFNHG UBORFN OK / r_locked OK / r_locked NO/ w_locked ZBORFN OK / w_locked NO / r_locked NO / w_locked XQORFN error OK / depends OK / free un contatore tiene traccia del numero dei lettori; la risorsa e rilasciata quando il contatore vale zero. Se una richiesta di lock non e concessa, la transazione richiedente e messa in stato di attesa L attesa termina quando la risorsa viene rilasciata (unlocked) I lock gia concessi sono memorizzati in una tabella gestita dal lock manager

/RFNLQJDGXH IDVL La serializzabilita richiede, in aggiunta, che il locking sia in due fasi: 8QD WUDQVD]LRQHGRSR DYHUH ULODVFLDWR XQ ORFNQRQSXR DFTXLVLUHDOWULORFN Due fasi: crescente e calante Se uno scheduler opera su transazioni ben formate e a due fasi e concede i lock in base alla tabella dei conflitti, esso produce la classe degli schedule 2PL Gli schedule 2PL sono serializzabili e la classe 2PL e strettamente inclusa nella classe CSR Esempio di schedule che e in CSR e non in 2PL: 6 12 : U 1 ([) Z 1 ([) U 2 ([) Z 2 ([) U 3 (\) Z 1 (\)

/RFNLQJDGXH IDVLVWUHWWR Dobbiamo ancora rimuovere l ipotesi sull uso di commit proiezioni Passiamo al 2PL Stretto (aggiungendo il vincolo):,orfndftxlvlwlgd XQD WUDQVD]LRQH SRVVRQR HVVHUH ULODVFLDWL VRORGRSR FKH ODWUDQVD]LRQH KDO RSHUD]LRQH GL FRPPLWDERUW Questa versione e normalmete usata dai DBMS commerciali elimina l anomalia della dirty read

&RQWUROORGHOODFRQFRUUHQ]DEDVDWRVXL 7LPHVWDPp: WLPHVWDPSV identificatore che definisce un ordinamento totale fra eventi temporali nel sistema Ad ogni transazione viene assegnato un timestamp WV che rappresenta il tempo d inizio della transazione Uno schedule e accettato solo se riflette l ordine seriale delle transazioni basato sul valore del timestamp di ogni transazione

&RPHVLXWLOL]]DQRLWLPHVWDPS Lo scheduler ha un contatore RTM([) and WTM([) per ogni oggetto Lo scheduler riceve richieste di read e write sugli oggetti etichettate con un timestamp: UHDG([,Ws): se WV < WTM(x) allora la richiesta e riufiutata e la transazione uccisa, altrimenti la richiesta e accettata e RTM([) e posto uguale al massimo fra RTM([) e Ws ZULWe([,Ws): se WV < WTM([) o WV < RTM([) allora la richiesta e riufiutata e la transazione uccisa, altrimenti la richiesta e accettata e WTM([) e posto uguale a Ws (Sotto l ipotesi di considerare la commit-proiezione) Il metodo causa l abort di un gran numero di transazioni Per rimuovere l assunzione di commit proiezione le scritture devono essere bufferizzate finche la transazione non esegue il commit. Le letture dei dati memorizzati nel buffer in attesa di commit vengono a loro volta messe in attesa

(VHPSLRGLFRQWUROORGHOODFRQFRUUHQ]D EDVDWRVXL WLPHVWDPSV Richiesta Risposta Nuovo valore UHDG([,6) ok UHDG([,8) ok RTM([) = 8 UHDG([,9) ok RTM([) = 9 ZULWe([,8) no W 8 killed ZULWe([,11) ok WTM([) = 11 UHDG([,10) no W 10 killed

&RQWUROORGHOODFRQFRUUHQ]DPXOWLYHUVLRQH Idea principale: le write producono nuove copie, le read accedono alla copia corretta Le write generano nuove copie con un WTM nuovo. In ogni istante ci sono 1>1 copie di ogni oggetto [attive con writetimestamp WTM ([ ),,WTM 1 ([). C e un unico RTM([) globale Meccanismo: UHDG([,Ws): e sempre accettata. Per la lettura e selezionata una copia [ k tale che: se > WV WTM ([), allora k = 1, 1 altrimenti k e tale che WTM k ([) < WV < WTM k+1 ([) ZULWe(x,Ws): se ts < RTM([) la richiesta e rifiutata, altrimenti si aggiunge una nuova versione del dato 1viene incrementato di uno) con WTM 1 ([) = Ws Le copie vecchie sono rilasciate quando non ci sono piu transazioni in lettura interessate ai loro valori

0HFFDQLVPLSHUODJHVWLRQHGHLORFN Il lock manager viene invocato da tutti i processi che vogliono accedere alla base di dati Interfaccia: r_lock(t, x, errcode, timeout) w_lock(t, x, errcode, timeout) unlock(t, x) T: identificatore della transazione X: dato timeout: massima attesa in coda Allo scadere del timeout, errcode segnala un errore e tipicamente la transazione esegue un roll back e riparte

/RFNLQJJHUDUFKLFR In molti sistemi reali i lock possono essere specificati a diversi livelli di granularita, ad esempio, le tabelle, i frammenti, le tuple, i campi. Questi sono organizzati in una gerarchia di risorse (ad esempio, un grafo diretto aciclico) 5 modalita di locking : le due precedentemente introdotte: XL: lock esclusivo SL: lock condiviso 3 nuove: ISL: intenzione di lock condiviso IXL: intenzione di lock esclusivo SIXL: lock condiviso e intenzione di lock esclusivo La scelta del livello di granularita e lasciata a che progetta l applicazione; se livello troppo grossolano: molte risorse bloccate se livello troppo fine : molte richieste di lock

3URWRFROORGLORFNLQJJHUDUFKLFR I lock sono richiesti dalla radice ai discendenti nella gerarchia I lock sono rilasciati partendo dal nodo bloccato e risalendo lungo l albero Per richiedere un SL o un ISL su di un nodo, la transazione deve gia possedere un ISL o IXL sul padre Per richiedere un IXL, XL o un SIXL su di un nodo, la transazione deve gia possedere un SIXL o IXL sul padre La nuova tabella dei conflitti segue

&RQIOLWWLQHO ORFNLQJ JHUDUFKLFR 6WDWRULVRUVD 5LFKLHVWD ISL IXL SL SIXL XL ISL OK OK OK OK No IXL OK OK No No No SL OK No OK No No SIXL OK No No No No XL No No No No No

0RGDOLWD GLORFNRIIHUWHGD 64/ Alcune transazioni sono definite come read-only (non possono modificare il contenuto della base di dati) Il livello di isolamento puo essere specificato per ogli transazione Serializable garantisce il massimo isolamento: vengono mantenuti i lock per non modificare il valore delle funzioni aggregate valutate su insiemi di dati Repeatable read corrisponde a 2PL stretto (nota: letture ripetute di valori danno risultati uguali, ma non letture ripetute di valori aggregati) Committed read esclude la lettura di stati intermedi (uncommitted data) Uncommitted read nessuna azione di locking e utilizzata per le letture

'HDGORFNV Prodotto da transazioni concorrenti, ognuna delle quali blocca delle risorse ed attende di acquisire risorse bloccate dalle altre Esempio: W 1 : UHDG([), ZULWH(\) W 2 : UHDG(\), ZULWH([) Schedule: UBORFN 1 ([), UBORFN 2 (\), UHDG 1 ([), UHDG 2 (\) ZBORFN 1 (\), ZBORFN 2 ([) Questa e una situazione di deadlock!

7HFQLFKH GL ULVROX]LRQH GHOGHDGORFN Una situazione di deadlock produce un ciclo nel grafo delle attese, che descrive le relazioni di attesa fra le transazioni (nodo=transaction, arco=wait condition). Tre tecniche: 7LPHRXW (problema: la scelta del timeout) 5LOHYDPHQWR GHOGHDGORFN : ricerca dei cicli nel grafo delle attese 3UHYHQ]LRQH GHOGHDGORFN : si uccidono le transazioni che possono causale cicli. Opzioni per la scelta della transazione da uccidere: politica SUHHPSWLYH o QRQSUHHPSWLYH