La gestione delle transazioni in ambiente distribuito

Una transazione è l’esecuzione di un insieme di operazioni su un sistema tali da far evolvere il sistema da uno stato valido verso un altro stato valido. Ad esempio l’operazione di pagamento di un’imposta comunale con addebito diretto su conto corrente bancario richiede che le operazioni di accredito della somma dovuta sul conto corrente d’appoggio del Comune, di addebito della medesima somma sul conto corrente del contribuente e di registrazione del pagamento nel sistema informatico comunale avvengano tutte con successo, pena il disallineamento dello stato del sistema informatico dalla realtà che esso rappresenta (pagamento avvenuto oppure non avvenuto).

In termini ingegneristici, una transazione di un sistema informatico è una unità indivisibile di lavoro che soddisfa le proprietà ACID (Atomicity, Consistency, Isolation, Durability), portando il sistema da uno stato consistente ad un altro stato consistente. Il significato delle proprietà è:

• Atomicity: garanzia che le operazioni previste dalla transazione vengano eseguite tutte, una sola volta, o che non ne venga eseguita nessuna;
• Consistency: garanzia che la transazione porti la base informativa da uno stato consistente ad un nuovo stato consistente;
• Isolation: garanzia che i dati coinvolti in una transazione non siano visibili o impiegabili da un’altra transazione, durante la sua esecuzione;
• Durability: garanzia che i dati coinvolti in una transazione rimangano disponibili per il tempo utile, anche in presenza di eventi catastrofici (rottura del disco, gravi errrori, ecc.).

I sistemi transazionali (che fanno parte della categoria dei sistemi distribuiti) sono pertanto sistemi di supporto all’esecuzione delle transazioni e hanno il compito di garantire le proprietà ACID, la predicibilità dei tempi di risposta, la priorità di alcuni task su altri e la riservatezza dei dati protetti. Normalmente queste funzioni sono realizzate da un componente software (middleware transazionale) denominato TP Monitor.

Quando la transazione viene eseguita su sistemi diversi si ha una transazione distribuita. Per garantire le proprietà ACID, nel caso di transazioni distribuite, è necessario che tutti  i nodi elaborativi partecipanti giungano alla stessa decisione finale (portare a buon fine la transazione o abortirla); il meccanismo con il quale si coordina l’attività dei nodi partecipanti a una transazione è chiamato protocollo di commit.

Il modello di commit (commit è l’operazione con cui si dichiara conclusa una transazione) a due fasi  (in inglese 2-Phase Commit, o 2PC) è un protocollo di comunicazione tra i partecipanti a una transazione, in cui un sistema si identifica come coordinatore (TM Transaction Manager) e (prima fase) verifica la disponibilità di tutti gli altri partecipanti (RM Resource Manager) a terminare la transazione. Nel caso in cui riceva parere negativo da uno dei partecipanti, o non riceva alcuna risposta da uno dei partecipanti allo scadere di un tempo predefinito (time-out), il coordinatore invia un messaggio di rollback (l’operazione con cui si dichiara il fallimento di una transazione) ai partecipanti residui. Altrimenti (seconda fase), invia un messaggio di commit a tutti i partecipanti. Il protocollo di 2PC si presta facilmente ad un meccanismo di ricorsione per cui la comunicazione tra i partecipanti assume una struttura ad albero, con la radice situata nel coordinatore, e le foglie nei partecipanti che eseguono la parte di transazione di loro competenza senza coinvolgere altri sistemi.

X/Open, un consorzio di fornitori hardware e software e di utenti, ha definito un modello di riferimento per ambienti transazionali distribuiti, il DTP (Distributed Transaction Processing) che sostanzialmente realizza il 2PC. Il modello assume la presenza di un processo client (quello che avvia la transazione), di vari processi RM e di un processo TM, come si vede nella figura seguente. Di fatto, Il modello DTP prevede due interfacce, quella tra il client ed il TM, chiamata TM-interface, e quella tra TM e RM, chiamata XA-interface. I produttori di DBMS, per garantire che i loro server siano accessibili dai TM (e quindi aderenti allo standard) devono garantire la disponibilità della XA-interface. I produttori di TP monitor (come Encina e Tuxedo) debbono invece garantire la disponibilità sia della TM – Interface, sia della XA – Interface.

In relazione all’esempio applicativo fatto all’inizio dell’articolo:

• la transazione distribuita è “il pagamento di una imposta comunale con addebito diretto sul conto corrente bancario del contribuente”.
• le tre transazioni elementari costituenti la transazione distribuita sono:
  • l’accredito sul conto corrente bancario d’appoggio del Comune;
  • l’addebito sul conto corrente bancario del contribuente;
  • la registrazione, nel sistema informatico del Comune del versamento effettuato;
• i tre Resource Manager coinvolti sono, rispettivamente:
  • il sistema informatico della banca d’appoggio del Comune;
  • il sistema informatico della banca del contribuente;
  • il sistema informatico del Comune beneficiario;
• il Transaction Manager, nel caso in oggetto, fa probabilmente parte del sistema informatico del Comune beneficiario, in quanto la transazione distribuita descritta è di interesse specifico del Comune stesso.

Il paradigma ad oggetti spesso può portare, durante il funzionamento di un sistema, all’allocazione di una grande quantità di oggetti, con conseguente necessità di un gran numero di risorse, soprattutto in termini di memoria. Inoltre è necessario un controllo efficace sulla consistenza delle operazioni eseguite contemporaneamente su questo elevato numero di oggetti, tanto più se esse coinvolgono i dati contenuti nei RDBMS o nelle applicazioni legacy.

La soluzione di questi due problemi è cruciale per poter costruire applicazioni mission-critical basate sul DOC, che possano eguagliare l’affidabilità e l’efficienza proprie delle applicazioni basate sul paradigma terminale-mainframe.

In tale senso, le tecnologie di middleware ad oggetti stanno evolvendo verso l’integrazione dei TP Monitor con gli ORB. Questi nuovi prodotti, chiamati OTM – Object Transaction Monitor, mirano a garantire l’integrità delle operazioni eseguite sugli oggetti, la disponibilità e il bilanciamento delle risorse che forniscono i servizi, in una logica di alta affidabilità, scalabilità e gestibilità dei sistemi.

In base alle soluzioni attualmente adottate dai fornitori per la gestione delle transazioni all’interno di un sistema distribuito, si possono distinguere tre tipologie di OTM:

• TP Monitor integrato: l’OTM è il frutto della combinazione di un ORB con un potente motore TP preesistente, del quale costituisce la naturale evoluzione; offre il vantaggio di fare leva su una tecnologia consolidata, funzionalmente ricca e con provate capacità di bilanciamento del carico; inoltre spesso abilita l’interazione, sullo stesso sistema o su macchine diverse, tra gli oggetti serventi di nuova concezione e i servizi offerti da sistemi legacy e gestiti con Transaction Monitor tradizionali;
• ORB interfacciato a TP Monitor: è un modello ibrido o di transizione, nel quale un ORB di nuova concezione si connette ad un TP Monitor commerciale usando una interfaccia proprietaria; anche in questo caso il vantaggio consiste nel riuso di TP Monitor consolidati;
• ORB con estensioni TP: l’ORB in tale caso si fa carico di svolgere servizi tipici di un TP Monitor; tale approccio è sicuramente innovativo ma vanno attentamente valutate la reale scalabilità e solidità.