Questo post è la prima parte di una breve guida, atta a descrivere come il Progress database engine utilizza le
transazioni per migliorare affidabilità e prestazioni del database. Conoscere
questi argomenti permette di essere meglio attrezzati per sfruttare appieno il
Progress RDBMS.
Il concetto di transazione è fondamentale per il funzionamento dei sistemi
di basi di dati.
Le transazioni sono un meccanismo di gestione degli errori e un meccanismo
di strutturazione dei programmi.
Come meccanismo di gestione dell’errore, permettono di fare una quantità
arbitraria di lavoro in una unità di tempo e poi cambiare idea. Quando si
lavora all'interno di una transazione si può dire al sistema di ripristinare la
situazione al momento iniziale; oppure si può dire di rendere ufficiali le
modifiche.
Quando una transazione è in esecuzione si dice essere in stato active. Quando una transazione è
completata diciamo che è committed. Se
si verifica un errore prima che la transazione sia completa, il sistema annulla
automaticamente qualsiasi lavoro che non può essere terminato a causa del
fallimento. Il processo di annullare gli effetti di una operazione incompleta si chiama rollback.
Come il meccanismo di strutturazione di un programma, le transazioni hanno
confini ben definiti dove incapsulare le operazioni su database eseguite da un’applicazione.
L’incapsulamento in una transazione deve essere accompagnato dall'incapsulamento nell'applicazione.
Le transazioni hanno quattro proprietà di base (proprietà ACID): atomicità,
consistenza, isolamento e durabilità. Queste proprietà sono
strettamente correlate tra loro
e sono descritte di seguito.
Atomicità
La proprietà atomicità dice che le transazioni sono “tutto o niente”.
Le transazioni spesso apportano diverse modifiche ad un
database. Questi cambiamenti correlati sono una unità logica di lavoro che
deve essere eseguita insieme. Ad esempio, per trasferire denaro da un
conto bancario ad un altro, i fondi devono essere dedotti dal primo conto e
aggiunti al secondo. Queste operazioni devono essere eseguite come
un'unità.
Consistenza
La proprietà consistenza dice che le operazioni trasformano il database da
un
stato coerente ad un altro.
La nozione di coerenza si riferisce sia alla coerenza del database fisico (cioè
che le strutture interne del database, come gli indici, i records, ecc, sono
validi e coerenti) che alla coerenza del database logico (cioè che i dati contenuti
nel database sono validi dal punto di vista di un'applicazione).
La consistenza fisica è gestita interamente dal database manger. Si
tratta di un prerequisito per la consistenza logica.
La consistenza logica, d'altra parte, è gestita sia dal database manager,
attraverso meccanismi quali regole di convalida, trigger, vincoli di
integrità, ecc, che dalle azioni dell'applicazione.
Affinché la trasformazione da uno stato ad un altro sia valida , il database
manager e l’applicazione devono eseguire le azioni opportune per garantire la
consistenza.
Bisogna ricordare che durante l’esecuzione di una transazione, lo stato del
database può essere incoerente. La coerenza deve esistere solo quando una transazione
si conclude.
Isolamento
La proprietà di isolamento dà, ad ogni transazione, l'illusione che essa
sia l'unica in esecuzione.
Gli effetti delle diverse transazioni, contemporaneamente in esecuzione,
non devono essere visibili a ciascuna altra. Tutte le modifiche apportate
da una transazione sono considerate provvisorie, mentre è ancora in esecuzione. Diventano
"ufficiali" o permanenti solo quando la transazione si conclude con
successo (commit rollback).
Pertanto è importante che una transazione non prenda decisioni basate sulle
modifiche apportate da un’altra.
Il database manager provvede al concetto di isolamento attraverso l'uso di
un meccanismo di two-phase locking. Questo argomento esula dallo scopo di
questa guida.
Durabilità
La proprietà durabilità dice una volta committato, sempre committato.
Quando una transazione è committata, i suoi effetti sulla base di dati sono
permanenti. Non possono essere annullati anche se si verifica un
guasto. Gli effetti di una transazione committata possono essere invertiti
eseguendo una seconda transazione che annulla gli effetti della prima.
0 commenti:
Posta un commento