Q: Transazioni: gestione dei deadlock
A:
Durante l'esecuzione di più transazioni in parallelo, è possibile il verificarsi di deadlock. Ad esempio si verifica deadlock quando si applica il protocollo Strict 2PL.
In tal caso, due transazioni T1 e T2, hanno ottenuto uno S-lock su una risorsa. Entrambe poi desidereno effettuare un'operazione di scrittura, quindi richiedono l'X-lock.
Il lock manager non concede l'X-lock a nessuna delle due transazioni, in quanto quanto tipo di lock è incompatibile con ogni altro lock acquisito dalla transazione.
Per uscire da questa condizione di deadlock è necessario abortire una transazione.
Esisono 2 possibilità per gestire i deadlock:
Deadlock prevention: sono tecniche atte a prevenire il verificarsi di deadlock. In questa categoria troviamo due politiche di gestione, in cui entrambe utilizzano il concetto di priorità (solitamente identificata da un valore numerico o il timestamp):
Deadlock detection: è una tecnica che fa uso di timer. In questo caso non si cerca di prevenire il verificarsi di deadlock ma di identificarne la loro esistenza e di conseguenza gestirli (facendo abortire una transazione).
Al momento della creazione di una transazione, viene fatto partire un timer il quale una volta scaduto, se la transazione a cui esso è associato è ancora in esecuzione, fa abortire la transazione, in quanto probabilmente in deadlock. Ovviamente questo controllo viene fatto solo se esistono più di una transazione attiva, quindi una potrebbe bloccare l'esecuzione dell'altra, altrimenti è inutile effettuarlo.
Inoltre, non è detto che venga abortita proprio la transazione in esame, ma potrebbe anche essere abortita un'altra transazione (che potrebbe causare il deadlock di quella con il timer attualmente scaduto associato). La scelta di quale transazione fare abortire è un parametro di progetto e può essere fatta solo dal progettista del DBMS.
La transazione abortita viene successivamente ricreata, con un valore di timer maggiore, in quanto è possibile che questa fosse effettivamente in corso d'esecuzione e non bloccata, perché computazionalmente intensiva.
Un'ulteriore maniera per gestire i deadlock è dato dall'uso del protocollo Conservative 2PL.
Che è esattamente come il protocollo Strict 2PL, con la sola differenza che la fase 1 consiste nell'acquisizione di tutti i lock.
Finché non sono stati acquisiti tutti i lock la transazione non può essere eseguita.
Dal momento che la transazione viene eseguita solo quando si hanno tutti i lock, è impossibile che un'altra transazione possa interferire.
Questo protocollo evita i deadlock, ma riduce il grado di parallelismo.
A:
Durante l'esecuzione di più transazioni in parallelo, è possibile il verificarsi di deadlock. Ad esempio si verifica deadlock quando si applica il protocollo Strict 2PL.
In tal caso, due transazioni T1 e T2, hanno ottenuto uno S-lock su una risorsa. Entrambe poi desidereno effettuare un'operazione di scrittura, quindi richiedono l'X-lock.
Il lock manager non concede l'X-lock a nessuna delle due transazioni, in quanto quanto tipo di lock è incompatibile con ogni altro lock acquisito dalla transazione.
Per uscire da questa condizione di deadlock è necessario abortire una transazione.
Esisono 2 possibilità per gestire i deadlock:
- Deadlock prevention
- Deadlock detection
Deadlock prevention: sono tecniche atte a prevenire il verificarsi di deadlock. In questa categoria troviamo due politiche di gestione, in cui entrambe utilizzano il concetto di priorità (solitamente identificata da un valore numerico o il timestamp):
- Wound-wait: se la priorità di una transazione T1 > T2 e T2 è in esecuzione, viene abortita T2 in quanto possiede risorse necessarie a T1 che ha una priorità maggiore. Successivamente T2 verrà ricreata con una priorità maggiore.
Evidentemente questa è una politica con prerilascio. - Wait-die: se la priorità di una transazione T1 > T2 e T2 è in esecuzione, viene abortita T1 in quanto non può interrompere l'esecuzione di una transazione già in esecuzione. Successivamente verrà ricreata T1 ed inserita nella coda delle transazioni da eseguire, in maniera ordinata, a seconda del momento in cui esse sono state abortite.
Questa politica è evidentemente senza prerilascio, ed è quella che si preferisce adottare.
Deadlock detection: è una tecnica che fa uso di timer. In questo caso non si cerca di prevenire il verificarsi di deadlock ma di identificarne la loro esistenza e di conseguenza gestirli (facendo abortire una transazione).
Al momento della creazione di una transazione, viene fatto partire un timer il quale una volta scaduto, se la transazione a cui esso è associato è ancora in esecuzione, fa abortire la transazione, in quanto probabilmente in deadlock. Ovviamente questo controllo viene fatto solo se esistono più di una transazione attiva, quindi una potrebbe bloccare l'esecuzione dell'altra, altrimenti è inutile effettuarlo.
Inoltre, non è detto che venga abortita proprio la transazione in esame, ma potrebbe anche essere abortita un'altra transazione (che potrebbe causare il deadlock di quella con il timer attualmente scaduto associato). La scelta di quale transazione fare abortire è un parametro di progetto e può essere fatta solo dal progettista del DBMS.
La transazione abortita viene successivamente ricreata, con un valore di timer maggiore, in quanto è possibile che questa fosse effettivamente in corso d'esecuzione e non bloccata, perché computazionalmente intensiva.
Un'ulteriore maniera per gestire i deadlock è dato dall'uso del protocollo Conservative 2PL.
Che è esattamente come il protocollo Strict 2PL, con la sola differenza che la fase 1 consiste nell'acquisizione di tutti i lock.
Finché non sono stati acquisiti tutti i lock la transazione non può essere eseguita.
Dal momento che la transazione viene eseguita solo quando si hanno tutti i lock, è impossibile che un'altra transazione possa interferire.
Questo protocollo evita i deadlock, ma riduce il grado di parallelismo.