SOA (Service Oriented Architecture), Web As Platform, Data, Java and Open Source
Il Try-Cancel/Confirm è un protocollo a due fasi che tenta di soddisfare – con la compensazione – la richiesta di atomicità nelle transazioni distribuite di lunga durata che coinvolgono web services.
Una transazione distribuita di lunga durata è un insieme definito di operazioni, da eseguire in un tempo “lungo” finito, che ha effetto su più basi dati; le operazioni che la compongono si possono in generale definire “di business”.
La compensazione è l’insieme delle operazioni “inverse” agli effetti delle operazioni di business; per semplicità si può supporre che ci sia un’operazione “inversa” per ogni operazione di business.
Il Try-Cancel/Confirm prevede che l’insieme delle operazioni di compensazione sia parte della transazione che comprende le operazioni di business. Infatti:
Il Try apporta modifiche persistenti ma non definitive, che devono essere cancellate o confermate dalla fase successiva.
La fase del Try dovrebbe avere una massima durata prefissata, in modo da considerare come negative le risposte non ricevute entro il time-out stabilito.
Il Cancel e il Confirm sono mutuamente esclusivi: un Try può essere seguito da un Cancel o da un Confirm, e insieme costituiscono la transazione di business. La decisione su quale fase eseguire, tra il Cancel e il Confirm, spetta al coordinatore del processo di business, sulla base degli esiti ricevuti – o non ricevuti – durante la fase di Try.
Il Try non seguito da un Cancel o da un Confirm è di solito compensato autonomamente da un meccanismo a tempo, implementato all’interno di ogni sistema che espone una base dati coinvolta nella transazione. Questa compensazione, naturalmente, corrisponde all’implementazione retrostante le interfacce (web services) che la fase di Cancel avrebbe invocato.
A differenza del protocollo di commit a due fasi, tra il Try e il Cancel o tra il Try e il Confirm non c’è il lock dei dati interessati, e questo implica che non vi sia spreco di risorse, ma anche assenza di garanzia all’isolamento delle transazioni: il Try di una transazione, infatti, può essere immediatamente seguito – sugli stessi dati – dal Try di un’altra, prima che sia eseguito il Cancel o il Confirm della precedente. Questo può accadere perché i risultati non definitivi di una transazione sono persistenti, per cui possono essere visti e modificati da altre. Garantire l’isolamento, comunque, non rientra negli obiettivi di questo protocollo. Inoltre la mancanza del lock lascia presupporre che le singole modifiche siano applicate e rese persistenti immediatamente, non scritte su un log di write-ahead in attesa di essere confermate dal coordinatore (localmente sono infatti confermate subito, come fossero in auto-commit).
Non rientrano negli obiettivi del protocollo neanche la Consistenza e la Persistenza: sono semplicemente delegate alla gestione interna dei sistemi coinvolti.
Il Try-Cancel/Confirm tenta di garantire l’atomicità: la proprietà per cui la transazione produca tutti gli effetti previsti o che non ne produca affatto, lasciando le basi dati nello stato in cui erano prima che la transazione fosse eseguita, o in uno equivalente (la compensazione, infatti, si può concretizzare sia in cancellazioni fisiche che logiche).
Per ottenere l’atomicità sembra che il protocollo richieda l’isolamento come precondizione: se non ci fosse, più Try di seguito potrebbero avere effetti sugli stessi dati prima dell’esecuzione del Cancel o del Confirm per una o più delle transazioni precedenti, e sarebbe difficile compensare gli effetti di una transazione incompleta ricoperti da quelli di altre eseguite subito dopo.
L’inaffidabilità della rete, del hardware, o del software, inoltre, possono creare situazioni in cui il Try di una transazione ha esito totalmente positivo, ma non si riesce ad eseguire per intero il relativo Confirm. In questo caso si possono ripetere quelle operazioni di conferma che non riescono – a patto che siano idempotenti – ma si deve riuscire a completarle entro il time-out stabilito, scaduto il quale scatta il meccanismo di compensazione automatica per ciò che non è stato ancora confermato (e neanche cancellato), il quale crea così uno stato di inconsistenza, con parte della transazione confermata e parte compensata. Il problema non sussiste per i Try con esito negativo.
Il Try-Cancel/Confirm è soggetto al problema dei due generali, come ogni altro algoritmo che tenta di coordinare un’azione su un canale di comunicazione inaffidabile: come ciascuno di questi implementa una sua strategia per mitigare gli effetti del problema.
Mi chiamo Andrea Gumina. Sono laureato in Scienze dell'Informazione e lavoro per un'azienda di consulenza IT. Da qualche anno mi occupo di integrazione di sistemi, di SOA (Service Oriented Architecture) da poco meno di cinque.
