Two Phase Locking

Da Wikipedia, l'enciclopedia libera.

Il two phase locking (2PL) è un protocollo per il controllo della concorrenza utilizzato nel campo dei database per garantire la serializzabilità di uno schedule di transazioni.

Questo protocollo assume che ogni transazione in esecuzione preveda due fasi principali:

  • nella prima fase tutti i lock sulle risose necessarie all'esecuzione dell'intera transazione vengono acquisiti;
  • nella seconda vengono tutti rilasciati senza possibilità di acquisirne dei nuovi fino alla fine della transazione.

Se tutte le transazioni rispettano il 2PL allora (si dimostra formalmente) uno schedule 2PL è conflict serializzabile. Il 2PL garantisce l'assenza di Deadlock in un sistema NON distribuito.

Richieste di Lock[modifica | modifica wikitesto]

Una transazione gestita con il Two Phase Locking può richiedere diverse operazioni al gestore della concorrenza:

  • R-LOCK: richiesta per il blocco di una risorsa in sola lettura. Questo tipo di lock è condiviso quindi più di una transazione contemporaneamente può fare la stessa richiesta di lock sulla stessa risorsa;
  • W-LOCK: richiesta per il blocco di una risorsa in scrittura. Questo tipo di blocco è esclusivo quindi nessun'altra transazione può usare la risorsa finche è bloccata con questo tipo di lock;
  • UNLOCK: richiesta per il rilascio di un blocco su una risorsa.

Le richieste di lock sono inviate dalle transazioni al gestore della concorrenza il quale in base allo stato della risorsa interessata valuta se concedere il lock oppure far aspettare la transazione. Questa scelta è fatta consultando la seguente tabella:

FREE R-LOCK W-LOCK
R-LOCK Sì/R-LOCK Sì/R-LOCK ggNO/W-LOCK
W-LOCK Sì/W-LOCK NO/R-LOCK NO/W-LOCK
UNLOCK NO/FREE Sì/DEPENDS Sì/FREE

Questa tabella mostra sulla prima colonna le richieste possibili delle transazioni, sulla prima riga i possibili stati di una risorsa e all'interno delle caselle se la richiesta è stata accettata dal gestore della concorrenza e il rispettivo stato successivo della risorsa.[1]

Nel caso in cui la risorsa sia nello stato di R-LOCK e la transazione richieda un UNLOCK la risorsa diventa libera solo se non c'erano altre R-LOCK che la tenevano bloccata, infatti lo stato di R-LOCK è condiviso quindi più di una transazione può richiederlo e la risorsa diventa effettivamente libera solo quando tutte le risorse che la bloccavano in lettura la liberano. Per questo motivo solitamente si usa un contatore che tiene traccia di quante transazioni sono in read-lock su una risorsa, che viene incrementato dopo ogni R-LOCK e decrementato dopo ogni UNLOCK. La risorsa diventa effettivamente libera solo quando tale contatore è a zero.

Strict 2PL[modifica | modifica wikitesto]

La versione standard del locking a due fasi non riesce a prevenire il conflitto da lettura sporca, ovvero il fatto che che un dato possa essere modificato da una transazione t1, letto nella sua versione modificata da una transazione t2 e riportato alla sua versione originaria nel caso che t1 esegua un abort. Il two-phase locking stretto (strict 2PL) è una versione di locking a due fasi che previene questo tipo di anomalia garantendo che tutti gli UNLOCK delle risorse vengano eseguiti solo dopo l'eventuale commit o abort della transazione; in questo modo se una transazione è in WRITE-LOCK su una certa risorsa e abortisce, prima di liberare il lock esegue il rollback di tutte le modifiche. Questa versione di 2PL è quella maggiormente adottata nei DBMS commerciali[1].

Esempio di transazioni concorrenti con il 2PL[modifica | modifica wikitesto]

Di seguito due transazioni che rispettano il 2PL, ma non il 2PL stretto:

T1 T2
lock(p1)
read(p1)
lock(p1)
write(p1)
lock(p2)
unlock(p1)
read(p1)
write(p1)
lock(p2)
unlock(p1)
read(p2)
write(p2)
unlock(p2)
read(p2)
write(p2)
unlock(p2)

Come si può vedere dalla tabella, sia in T1 che in T2 i lock e gli unlock sono acquisiti e rilasciati secondo il 2PL, ma non secondo il 2PL stretto; la transazione t1 infatti compie un unlock sulla risorsa p1 prima del commit, dopo aver rilasciato pi infatti esegue le azioni di read e write su p2.

Collegamenti esterni[modifica | modifica wikitesto]

Note[modifica | modifica wikitesto]

  1. ^ a b c "Paolo Atzeni", "Stefano Ceri", "Stefano Paraboschi" e "Riccardo Torlone", "Controllo della concorrenza" in "Basi di dati: concetti, linguaggi e architettura", "", "McGraw-Hill", "1999".