Livelli di Isolamento delle Transazioni

Il livello di isolamento delle transazioni è inteso come uno stato all’interno dei database che specifica la quantità di dati visibili a un’istruzione in una transazione, specialmente quando gli stessi dati sono accessibili da molte transazioni contemporaneamente. Immaginiamo una situazione in cui abbiamo una tabella Clienti con 1 milione di righe che occupa 10 GB di spazio su disco. Alle 9 in punto abbiamo avviato una query “SELECT * FROM Clienti”, che interroga tutte le righe della tabella. Nel nostro caso, questa query richiede circa 5 minuti per essere completata. Questo tempo è necessario per eseguire una scansione completa della nostra tabella e recuperare le righe. Questo tipo di query esegue una scansione completa della tabella e non può essere consigliata dal punto di vista delle prestazioni. Alle 9:01 UtenteB aggiorna l’ultima riga nella tabella Clienti e conferma la modifica. Poco dopo, la nostra query arriva all’ultima riga modificata da UtenteB. Cosa succederà? Vedremo il valore originale della riga o il valore modificato? Il nuovo valore della riga è legittimo e confermato, ma è stato aggiornato dopo l’inizio della nostra query.

Il risultato della nostra query dipende dal livello di isolamento delle transazioni. Fondamentalmente, ci sono 4 livelli di isolamento spiegati di seguito:

1. Read uncommitted. Vedremo le modifiche effettuate da UtenteB. Questo livello di isolamento è anche chiamato “dirty reads”, il che significa che i dati letti non sono coerenti con altre parti della tabella o della query e potrebbero non essere ancora stati confermati. “Dirty reads” garantisce le prestazioni più rapide, poiché i dati vengono letti direttamente dai blocchi della tabella senza convalida.
2. Read committed. Non vedremo le modifiche effettuate da UtenteB. Questo accade perché con questo livello di isolamento della query le righe recuperate da una query sono le righe che sono state confermate prima che la query iniziasse. Ciò significa che le modifiche apportate da UtenteB non erano presenti quando la query è iniziata, quindi le modifiche non saranno incluse nel risultato della query.
3. Repeatable read. Non vedremo le modifiche effettuate da UtenteB. Questo accade perché, nel livello di isolamento repeatable read, le righe recuperate da una query sono le righe che erano state confermate quando la transazione è iniziata. Significa che le modifiche apportate da UtenteB non erano presenti quando la transazione è iniziata, e quindi non saranno incluse nel risultato della query. “Tutte le letture coerenti all’interno della stessa transazione leggono l’istantanea stabilita dalla prima lettura” (dalla documentazione di MySQL)
4. Serializable. Questo livello di isolamento significa che tutte le transazioni del database si verificano in modo completamente isolato. In questo livello di isolamento, tutte le transazioni vengono eseguite in modo seriale, una dopo l’altra. Il DBMS può eseguire due o più transazioni contemporaneamente solo se si può mantenere l’illusione dell’esecuzione seriale. In pratica, serializable è molto simile a repeatable read, ma utilizza una tecnica di implementazione diversa per ciascun motore di database. Ad esempio, in Oracle, il livello di isolamento repeatable read non è supportato e Serializable fornisce il più alto livello di isolamento. Questo livello di isolamento è come repeatable read, ma InnoDB implicitamente converte tutte le istruzioni SELECT semplici in “SELECT … LOCK IN SHARE MODE”.