Cosa si intende per transazione di una base di dati e come funzionano
Un sistema transazionale è un sistema informatico generalmente di tipo enterprise che è caratterizzato una logica applicativa complessa e da molti utenti che richiedono servizi in concorrenza, consultando archivi di grandi dimensioni con organizzazione di dati complessi e distribuita; l’unità di elaborazione elementare di questo sistema si chiama transazione.
In un sistema transazionale il termine transazione indica un’unità logica di elaborazione che corrisponde a una serie di operazioni fisiche elementari (di lettura o scrittura) sul database che quindi generano una variazione del suo stato.
Ad ogni transazione devono essere garantite 4 proprietà indicate con l’acronimo ACID:
- Atomicity: deve essere eseguita come se fosse un’unica operazione;
- Consistency: deve lasciare il DB in uno stato consistente;
- Isolation: è indipendente rispetto alle altre, quindi deve essere correttamente gestita l’esecuzione concorrente delle transazioni;
- Durability: gli effetti di una transazione eseguita correttamente devono essere persistenti nel tempo.
Ognuna di queste proprietà è gestita da uno dei diversi moduli interni ad un DBMS (Database Management System):
- Transaction Manager: coordina l’esecuzione delle transazioni;
- Logging & Recovery Manager: si occupa di gestire l’ Atomicity e la Durability;
- Concurrency Manager: garantisce l’Isolation;
- DDL Compiler: genera i controlli per garantire la Consistency.
In generale gli stati intermedi in cui si trova il DB durante una transizione non è richiesto che siano consistenti. É importante poi ricordare che ogni transizione inizia con il comando BEGIN, implicito in SQL.
Esecuzione di una transazione
Il modello di una transazione può avere solo 2 esiti:
- Terminare correttamente: Questo avviene quando l’applicazione, dopo aver eseguito tutte le operazioni, esegue una particolare istruzione SQL, chiamata COMMIT, con la quale comunica al Transaction Manager il termine delle operazioni.
- Terminare non correttamente: Questo accade in due casi:
- La transazione decide, per un determinato motivo, che non ha senso continuare e quindi “abortisce” eseguendo l’istruzione di ROLLBACK.
- Il sistema non è in grado (ad es. per un guasto) di garantire la corretta prosecuzione della transazione, che viene quindi abortita.
Se per qualche motivo la transazione non può terminare correttamente il DBMS deve scartare (UNDO) le eventuali modifiche apportate al database ma il modello di transazioni è in realtà più articolato. Per esempio è possibile definire dei cosiddetti “savepoint” che vengono utilizzati da una transazione per disfare solo parzialmente il lavoro svolto. Il DBMS esegue più transazioni in concorrenza, alternando l’esecuzione di operazioni di una transazione con quelle di altre, questo tipo di esecuzione è chiamata “interleaved execution”. Eseguire più transazioni in maniera concorrente è necessario per garantire buone prestazioni assicurando un elevato throughput di sistema e un tempo medio di risposta ridotto.
Problemi dell’esecuzione concorrente di transazioni
Se le transazioni eseguite concorrentemente interferiscono tra loro si possono avere 4 tipi base di problemi:
- Lost Update: si verifica quando un dato viene utilizzato mentre un altro processo lo sta modificando;
- Dirty Read: si verifica quando un dato instabile viene letto;
- Unrepeatable Read: si verifica quando alla lettura ripetuta di uno stesso dato vengono trovati valori diversi;
- Phantom Row: si può presentare quando vengono inserite o cancellate tuple che un’altra transazione dovrebbe logicamente considerare.
Il livello di isolamento predefinito in SQL è il Cursor Stability, tuttavia è possibile decidere di operare ad altri livelli. Ogni livello si differenzia da un altro per la possibilità di presentare o no uno dei precedenti problemi. In generale più problemi è possibile riscontrare, più si ha il vantaggio di aumentare il grado di concorrenza raggiungibile e quindi migliorare le prestazioni.
Lo standard SQL definisce 4 livelli di isolamento:
Il Repeatable Read (RR) in cui non si verifica nessun problema di interferenza. Il Read Stability (RS) in cui si può verificare il Phantom Row. Il Cursor Stability (CS) in cui si può verificare sia il Phantom Row che l’Unrepeatable Read. Ed infine l’Uncommitted Read (UR) in cui si possono verificare il Phantom Row, l’Unrepeatable Read e il Dirty Read.