Transazioni con esecuzione prolungata

Le transazioni a esecuzione prolungata sono costrutti importanti, utilizzati comunemente nelle orchestrazioni BizTalk. Forniscono funzioni per la compensazione personalizzata basata sull'ambito, la gestione delle eccezioni personalizzata basata sull'ambito e la nidificazione di transazioni, che nel loro insieme assicurano all'utente grande flessibilità per la progettazione di una solida architettura di transazioni.

Si utilizza una transazione a esecuzione prolungata quando la transazione deve essere eseguita per un lungo periodo di tempo e non sono necessarie proprietà ACID complete, ovvero non è necessario garantire l'isolamento dei dati da altre transazioni. Una transazione a esecuzione prolungata può avere lunghi periodi di inattività, spesso dovuti all'attesa di messaggi esterni in arrivo.

Le transazioni a esecuzione prolungata sono caratterizzate da coerenza e durevolezza, ma non da atomicità e isolamento. I dati di una transazione a esecuzione prolungata non vengono bloccati e possono quindi essere modificati da altri processi o applicazioni. La proprietà di isolamento per gli aggiornamenti di stato non viene conservata perché la conservazione di blocchi per un lungo periodo di tempo è impraticabile.

Il commit di una transazione a esecuzione prolungata è diverso da quello di una transazione atomica. Non c'è infatti alcun presupposto implicito di coordinamento distribuito in relazione al risultato (una transazione a esecuzione prolungata esiste solo all'interno di una singola istanza di orchestrazione). Una transazione a esecuzione prolungata viene considerata eseguita quando l'ultima istruzione in essa contenuta è stata completata. In caso di interruzione di una transazione non viene eseguito alcun rollback automatico dello stato. È possibile conseguire questo risultato a livello di codice mediante gestori di eccezioni e compensazione.

Un ambito può definire il proprio stato dichiarando variabili, messaggi e componenti .NET. Una transazione a esecuzione prolungata ha accesso alle informazioni sullo stato del proprio ambito, di qualsiasi altro che la racchiude e globalmente definite all'interno dell'orchestrazione. Non ha accesso alle informazioni sullo stato degli ambiti che non la racchiudono.

Annidamento

Le transazioni a esecuzione prolungata possono contenere transazioni atomiche o altre transazioni a esecuzione prolungata. Possono essere annidati a livelli arbitrari. Una transazione può, ad esempio, contenere due ulteriori transazioni a esecuzione prolungata, ognuna delle quali può contenere transazioni atomiche.

La nidificazione è particolarmente utile quando uno o più componenti della transazione globale devono essere atomici, mentre la transazione globale deve essere a esecuzione prolungata. Si consideri l'esempio di ricezione ed evasione di un ordine di acquisto. L'ordine di acquisto può arrivare in qualsiasi momento e i diversi passaggi per l'evasione dell'ordine possono richiedere tempo, ma si desidera comunque trattare l'intero processo come una transazione. La transazione globale in questo caso deve essere necessariamente a esecuzione prolungata, ma uno dei passaggi, ad esempio il riconoscimento di un pagamento, deve essere atomico.

Nota

Non è possibile nidificare un ambito transazionale in un ambito o un'orchestrazione non transazionale. Un ambito o un'orchestrazione di inclusione non transazionale non gestirà lo stato, poiché deve gestire correttamente la gestione dello stato di tutti gli ambiti al proprio interno.

Nota

Una transazione sincronizzata non può includere altre transazioni o ambiti sincronizzati.

Compensazione

Una transazione a esecuzione prolungata può specificare un blocco di compensazione che verrà chiamato per compensare le attività della transazione, dopo il commit. Il blocco può semplicemente annullare la transazione, nel caso sia fattibile, o eseguire un'altra funzione, come la notifica, che consenta di attenuare in qualche modo gli effetti della transazione. Se non si aggiunge codice di compensazione personalizzato, il motore di runtime chiamerà, per impostazione predefinita, i blocchi di compensazione delle transazioni interne, sia a esecuzione prolungata sia atomiche, in ordine inverso, a partire dall'ultima transazione di cui è stato eseguito il commit per finire con la prima transazione di cui è stato eseguito il commit.

Nota

La compensazione può essere eseguita solo su una transazione di cui è stato correttamente eseguito il commit.

Tolleranza di errore

Le transazioni supportano la tolleranza d'errore per il ripristino da errori interni (come errori hardware e software) ed esterni (come messaggi di annullamento). Degli aggiornamenti parziali all'interno di transazioni a esecuzione prolungata non viene eseguito il rollback automatico quando si verifica un errore di transazione, poiché si trovano in transazioni ACID.

In caso si errore viene chiamato il blocco di codice di eccezione per le transazioni a esecuzione prolungata. Questo blocco di codice contiene una serie di gestori errori scritti per gestire gli errori che possono verificarsi durante l'esecuzione della transazione. Per la gestione dell'errore è possibile basarsi sull'ultimo stato noto dei messaggi, delle variabili e degli oggetti.

È in genere necessario che il gestore eccezioni valuti lo stato dell'orchestrazione quando viene generata l'eccezione, esegua tutte le azioni necessarie in base allo stato in questione e chiami le compensazioni delle transazioni annidate.

In caso di errore, l'esecuzione della transazione a esecuzione prolungata viene interrotta e non può essere ripresa.

Vedere anche

Scenari che usano transazioni a esecuzione prolungata
Transazioni atomiche
Uso delle transazioni e gestione delle eccezioni