Transazioni e gestione delle richieste concorrenti

Errori Logici

Quando vengono immessi dati errati o violati vincoli di integrità.

Fallimenti Voluti

Quando il programmatore la invoca esplicitamente.

Forzature del Sistema

Quando il DBMS impone il fallimento di una transazione per sbloccare una situazione di "stallo".

Crash del Sistema Guasti dell'hardware

Quando ci sono problemi relativi all'hardware o c'è un blackout elettrico.

A - Atomicità

Dopo essere stata avviata, una transazione può terminare con successo, può abortire o può essere abortita dal DBMS dopo l'esecuzione di tutte o alcune delle sue operazioni. Ogni transazione deve essere atomica (non suddivisibile) e quindi deve eseguire tutte le sue azioni o non deve eseguirne alcuna. Il DBMS controlla la sequenza di azioni registrandole (nel "database log file") in modo che ogni qual volta una transazione deve essere abortita le sue azioni vengono annullate.

C

Questa proprietà deve garantire che una transazione non violi i vincoli di integrità. Una transazione rappresenta una trasformazione corretta dello stato del database e quindi al suo termine quest'ultimo deve trovarsi in uno stato consistente senza che si verifichino contraddizioni (inconsistency) tra i dati archiviati.

I

Una transazione non può leggere risultati intermedi di altre transazioni e quindi deve sempre "osservare" una base di dati consistente. Questo tipo di proprietà deve garantire che gli effetti di una transazione siano isolati fino al termine della stessa. Per questo ogni transazione deve essere eseguita indipendentemente dall'esecuzione delle altre transazioni.

D

Nel caso in cui un operazione abbia modificato la base di dati i suoi effetti devono essere permanenti. Questo deve avvenire in tutti i casi anche in caso di errori eccezionali.

Race Contitions

Un fenomeno di corsa si verifica quando più processi effettuano concorrentemente operazioni di aggiornamento su una stessa risorsa. Per superare questo problema viene ritardata l'esecuzione di operazioni in conflitto imponendo alle transazioni di richiedere dei blocchi (detti lock) per poter effettuare le operazioni di lettura e scittura. Una
porzione di codice, che può essere eseguita solamente da un processo, viene detta "Sezione Critica

DeadLock

In questo tipo di problematica due o più processi che vogliono accedere ad una risorsa condivisa attendono tutti che un processo rilasci il controllo di una Sezione Critica così da bloccarsi vicendevolmente. In questo caso si dice che le transazioni sono poste in "mutua attesa" di risorse bloccate. Per gestire questo problema, si può adottare una
politica mirata di allocazione delle risorse o una allocazione non controllata seguita dall'aborto delle cause, per poter liberare le risorse.

Starvation

In questo tipo di problema un processo non riesce mai ad ottenere le risorse di cui necessita. Questa problematica è dipesa principalmente dalla priorità di accesso alla risorsa che il processo possiede. Può essere evitata con "tecniche di invecchiamento" che prevedono l'aumento progressivo e regolano la "priorità di accesso" del processo.

Concessione di blocchi esclusivi

Per ragioni di prestazioni è necessario utilizzare lock di granularità più fine. È necessario distinguere "lock in scrittura" e "lock in lettura" perchè se un dato deve essere aggiornato non si possono concorrentemente eseguire né operazioni di scrittura e né operazioni di lettura. Ne consegue che nelle tecniche di controllo reimplementate da
un database "lock in scrittura" agiscono in modo "esclusivo" senza permettere l'accesso ad un dato da parte di altri, mentre "lock in lettura" permettono altre letture per non inibire completamente l'accesso ad un dato.

Garantire la Durabilità

Una transazione deve essere riproducibile e annulabile in caso di guasti. Il Reliability/Recovery Manager gestisce l'esecuzione delle operazioni di rispristino.

Write-Write - Lost Update : Perdite di Aggiornamento

1. T1 UPDATE Y
2. T2 UPDATE Y
3. La transazione T1 ROLLBACK
4. La transazione T2 COMMIT

Read-Write - Unrepeatable Read : Letture non riproducibili

1. T1 SELECT Y
2. T2 UPDATE Y COMMIT
3. La transazione T1 SELECT Y

SELECT Y T2

Write-Read - Dirty Read : Letture Fantasma

1. T1 UPDATE Y
2. T2 SELECT Y
3. La transazione T1 ROLLBACK

T2

Gestione della Concorrenza

Per gestire queste anomalie bisogna aumentare il livello di isolamento che automaticamente diminuisce e regola il grado di concorrenza che un determinato dato può ottenere. I DBMS prevedono la possibilità di rilasciare i vincoli di isolamento tramite il concetto di "serializzabilità". Il DBMS nel rispettare questo concetto adotta un sistema di lock a livello di record (e non di tabella come nei sistemi operativi). I blocchi adottati sono:

Per la gestione delle acquisizioni di queste due tipologie di blocchi il DBMS implementa una strategia di "concessione dei lock" chiamata "Strict Two Phase Locking".

Il protocollo Strict 2PL stabilisce che:

1. Ogni transazione deve ottenere uno Shared Lock
2. Ogni transazione deve ottenere un Exclusive Lock
3. Se una transazione ha acquisito un Exclusive Lock
4. Ogni Lock acquisito da una transazione deve essere rilasciato al suo termine

Lo Strict 2PL permette solo esecuzioni seriali delle transazioni, snellisce l'esecuzione di aborto delle transazioni e risolve i problemi relativi alle perdite di aggiornamento (Lost Update) e alle letture non riproducibili (Unrepeatable Read).

Il problema relativo alle letture fantasma (Dirty Read) viene risolto adottando un'altra tipologia di Lock che nell'arco della durata di una transazione non permette la modifica del numero degli elementi che soddisfano le condizioni. I Lock vengono adottati sui predicati utilizzati nelle clausole WHERE livelli di isolamento

I livelli di isolamento previsti sono i seguenti:

Il livello SERIALIZABLE non risolve tutti i problemi: la sua dichiarazione richiede un numero elevato di blocchi e aumenta la competizione tra le transazioni per l'acquisizione di blocchi. Questo peggiora le prestazioni e aumenta drasticamente il rischio di stallo. La migliore soluzione sta nell'utilizzare un pò tutti i livelli di isolamento in base alle esigenze del dato o dell'applicazione.