Problemi di transazioni concorrenti

1.1 Introduzione

E ora inizia il divertimento: la teoria di come funzionano le transazioni. Come mantenere il sistema funzionante quando si modificano gli stessi dati in thread diversi? O vuoi eseguire una transazione in un'altra? Inizieremo a cercare risposte a queste domande studiando l'isolamento delle transazioni ...

Il livello di isolamento della transazione è un valore condizionale che determina la misura in cui, a seguito dell'esecuzione di transazioni logicamente parallele nel DBMS, sono consentiti dati incoerenti. La scala dei livelli di isolamento delle transazioni contiene un numero di valori, ordinati dal più basso al più alto; un livello di isolamento più elevato corrisponde a una migliore coerenza dei dati, ma il suo utilizzo può ridurre il numero di transazioni fisicamente parallele.

Al contrario, un livello di isolamento inferiore consente più transazioni parallele, ma riduce la precisione dei dati. Pertanto, scegliendo il livello di isolamento delle transazioni utilizzato, lo sviluppatore del sistema informativo, in una certa misura, offre una scelta tra la velocità di lavoro e la garanzia della coerenza garantita dei dati ricevuti dal sistema.

Problemi di accesso concorrente tramite transazioni

Quando le transazioni vengono eseguite in parallelo, sono possibili i seguenti problemi:

• aggiornamento perso - se un blocco di dati viene modificato contemporaneamente da diverse transazioni, tutte le modifiche vengono perse, tranne l'ultima;
• lettura "sporca" (eng. Dirty read) - lettura dei dati aggiunti o modificati da una transazione, che successivamente non verranno confermati (rollback);
• lettura non ripetibile (ing. lettura non ripetibile) - durante la rilettura all'interno della stessa transazione, i dati letti in precedenza vengono modificati;
• letture fantasma : una transazione durante la sua esecuzione più volte seleziona molte righe in base agli stessi criteri. Un'altra transazione tra questi recuperi aggiunge righe o modifica colonne di alcune delle righe utilizzate nei criteri di recupero della prima transazione e termina correttamente. Di conseguenza, risulterà che le stesse selezioni nella prima transazione danno diversi set di righe.

Considera le situazioni in cui possono verificarsi questi problemi.

1.2 Aggiornamento perso

La situazione in cui, quando un blocco di dati viene modificato contemporaneamente da diverse transazioni, una delle modifiche viene persa.

Supponiamo che ci siano due transazioni in esecuzione contemporaneamente:

In entrambe le transazioni cambia il valore del campo f2, al termine il valore del campo deve essere incrementato di 45. Infatti può verificarsi la seguente sequenza di azioni:

1. Entrambe le transazioni leggono contemporaneamente lo stato corrente del campo. Qui non è richiesta la concorrenza fisica esatta, è sufficiente che la seconda operazione di lettura in ordine sia completata prima che un'altra transazione scriva il suo risultato.
2. Entrambe le transazioni calcolano il nuovo valore del campo aggiungendo rispettivamente 20 e 25 al valore letto in precedenza.
3. Le transazioni provano a scrivere il risultato del calcolo nel campo f2. Poiché è fisicamente impossibile eseguire due scritture contemporaneamente, in realtà una delle operazioni di scrittura verrà eseguita prima, l'altra dopo. La seconda operazione di scrittura sovrascriverà il risultato della prima.

Di conseguenza, il valore del campo f2, al completamento di entrambe le transazioni, potrebbe aumentare non di 45, ma di 20 o 25, ovvero una delle transazioni di modifica dei dati "scomparirà".

1.3 Lettura "sporca".

Lettura dei dati aggiunti o modificati da una transazione che in seguito non riuscirà a eseguire il commit (rollback).

Supponiamo di avere due transazioni aperte da diverse applicazioni che eseguono le seguenti istruzioni SQL:

Nella transazione 1, il valore del campo f2 viene modificato, quindi nella transazione 2 viene selezionato il valore di questo campo. Successivamente, viene eseguito il rollback della transazione 1. Di conseguenza, il valore ricevuto dalla seconda transazione sarà diverso dal valore memorizzato nel database.

1.4 Lettura non ripetibile

La situazione in cui, durante la rilettura all'interno della stessa transazione, i dati letti in precedenza risultano essere modificati.

Supponiamo di avere due transazioni aperte da diverse applicazioni che eseguono le seguenti istruzioni SQL:

Nella transazione 2 viene selezionato il valore del campo f2, quindi nella transazione 1 viene modificato il valore del campo f2. Se si riprova a selezionare un valore dal campo f2 nella transazione 2, si otterrà un risultato diverso. Questa situazione è particolarmente inaccettabile quando i dati vengono letti per modificarli parzialmente e riscriverli nel database.

1.5 Leggere "fantasmi"

La situazione in cui, durante la lettura ripetuta all'interno della stessa transazione, la stessa selezione fornisce diversi set di righe.

Supponiamo che ci siano due transazioni aperte da diverse applicazioni che eseguono le seguenti istruzioni SQL:

La transazione 2 esegue un'istruzione SQL che utilizza tutti i valori del campo f2. Quindi viene inserita una nuova riga nella transazione 1, facendo in modo che la riesecuzione dell'istruzione SQL nella transazione 2 produca un risultato diverso. Questa situazione è chiamata lettura fantasma (lettura fantasma). Si differenzia dalla lettura non ripetibile in quanto il risultato dell'accesso ripetuto ai dati è cambiato non a causa della modifica/cancellazione dei dati stessi, ma a causa della comparsa di nuovi dati (fantasma).