Transazioni atomiche

Le orchestrazioni BizTalk possono essere progettate per eseguire parti di lavoro discrete, secondo il classico concetto di transazione "ACID". Queste unità di lavoro discrete o atomiche, quando vengono eseguite spostano il processo di business da uno stato coerente a un nuovo stato coerente e durevole, isolato dalle altre unità di lavoro. Questa operazione viene in genere eseguita usando il costrutto Scope che incapsula le unità di lavoro con la semantica transazionale. L'intera orchestrazione può anche essere definita come una transazione atomica senza l'uso di ambiti. Gli ambiti, tuttavia, non possono essere contrassegnati come transazionali a meno che l'orchestrazione stessa non venga contrassegnata come tipo di transazione a esecuzione prolungata o atomica. Le transazioni atomiche garantiscono il rollback automatico di eventuali aggiornamenti parziali nel caso di un errore durante l'aggiornamento transazionale e la cancellazione degli effetti della transazione (ad eccezione degli effetti di chiamate .NET eseguite nella transazione). Le transazioni atomiche nelle orchestrazioni BizTalk sono simili a transazioni DTC (Distributed Transaction Coordinator) per il fatto di avere in genere breve durata e di essere caratterizzate dai quattro attributi "ACID" (atomicità, consistenza, isolamento e durevolezza):

• Atomicità

  Una transazione rappresenta un'unità di lavoro atomica, termine che fa riferimento al fatto che vengono eseguite tutte le modifiche interne alla transazione o nessuna di esse.

• Coerenza

  Quando viene eseguita, una transazione deve preservare l'integrità dei dati nel sistema. Se una transazione esegue una modifica ai dati in un database che prima dell'avvio della transazione era internamente coerente, il database deve restare internamente coerente al termine della transazione. È quasi esclusiva responsabilità dello sviluppatore dell'applicazione che questa proprietà sia garantita.

• Isolamento

  Le modifiche eseguite da transazioni simultanee devono essere isolate da quelle eseguite da altre transazioni simultanee. Le transazioni isolate eseguite simultaneamente eseguono modifiche che preservano la coerenza interna del database esattamente come accade nel caso di transazioni eseguite in sequenza.

• Durabilità

  Dopo l'esecuzione di una transazione, tutte le modifiche diventano definitive nel sistema per impostazione predefinita. Le modifiche permangono anche in caso di errori del sistema.

  Le transazioni atomiche utilizzate nelle orchestrazioni BizTalk supportato i livelli di isolamento seguenti:

• Read Committed

  La condivisione dei blocchi viene mantenuta durante la lettura dei dati per evitare letture dirty, anche se è possibile modificare i dati prima del termine della transazione, con conseguente produzione di letture non ripetibili o dati fantasma.

• Lettura ripetibile

  I blocchi sono posizionati su tutti i dati utilizzati in una query, impedendo l'aggiornamento dei dati da parte di altri utenti. Questo impedisce le letture non ripetibili, ma è sempre possibile ottenere righe fantasma.

• Serializable

  Viene posizionato un blocco di intervallo, per impedire ad altri utenti di aggiornare o immettere righe nel database fino al termine della transazione.

  BizTalk Server garantisce che le modifiche di stato all'interno di una transazione atomica, ad esempio modifiche a variabili, messaggi e oggetti, siano visibili all'esterno dell'ambito della transazione atomica solo dopo l'impegno della transazione. Le modifiche di stato intermedia vengono isolate dalle altre parti di un'orchestrazione.

Nota

Se una transazione atomica contiene una forma Receive , una forma Send o una forma Start Orchestration , le azioni corrispondenti verranno eseguite solo dopo il commit della transazione.

Se sono necessarie proprietà ACID complete sui dati, ad esempio quando i dati devono essere isolati da altre transazioni, è necessario usare transazioni atomiche esclusivamente.

Quando una transazione atomica ha esito negativo, tutti gli stati vengono reimpostati come se l'istanza dell'orchestrazione non fosse mai entrata nell'ambito. La regola di BizTalk per le transazioni atomiche prevede che tutte le variabili, e non solo quelle locali all'ambito, partecipino alla transazione. Tutte le variabili e i messaggi non serializzabili utilizzati in una transazione atomica devono essere dichiarati localmente all'ambito; altrimenti, il compilatore genererà l'errore "variabile….non contrassegnata come serializzabile". Tutti gli ambiti atomici vengono considerati "sincronizzati" e il compilatore dell'orchestrazione genererà un avviso di utilizzo ridondante se viene utilizzata la parola chiave Synchronized per gli ambiti atomici. Las sincronizzazione relativa ai dati condivisi si estende dall'inizio dell'ambito fino al completamento corretto dell'ambito stesso (inclusa la persistenza dello stato alla fine dell'ambito), oppure fino al completamento del gestore delle eccezioni (in caso di errori). Il dominio di sincronizzazione non si estende al gestore di compensazione.

Le transazioni atomiche possono essere associate a valori di timeout in corrispondenza dei quali l'orchestrazione interromperà la transazione e l'istanza verrà sospesa. Se una transazione atomica contiene una forma Ricezione, Trasmissione o Avvia orchestrazione, le azioni corrispondenti non verranno eseguite fino al completamento della transazione.

Una transazione atomica ritenta quando l'utente genera deliberatamente un'eccezione RetryTransactionException o se viene generata un'eccezione PersistenceException al momento in cui la transazione atomica tenta di eseguire il commit. Quest'ultima situazione può verificarsi se, ad esempio, la transazione atomica fa parte di una transazione DTC distribuita e un altro partecipante a questa transazione la interrompe. Analogamente, se si sono verificati problemi di connettività del database al momento del tentativo di commit della transazione, verrebbe generata anche un'eccezione PersistenceException . Se ciò si verifica per un ambito atomico con Retry=True, verrà eseguito un nuovo tentativo fino a 21 volte. Il ritardo tra ogni tentativo è di due secondi per impostazione predefinita, ma è modificabile. Al termine dei 21 tentativi, se la transazione continua a non poter eseguire il commit, l'intera istanza dell'orchestrazione viene sospesa. Può quindi essere ripresa manualmente e ricominciare, con un nuovo contatore, dall'inizio dell'ambito atomico in cui si è verificato l'errore.

Nota

Solo RetryTransactionException e PersistenceException possono causare la ripetizione di un ambito atomico. Qualsiasi altra eccezione generata in un ambito atomico non può causare un nuovo tentativo, anche se la proprietà Retry è impostata su True. È possibile eseguire l'override del ritardo predefinito di due secondi tra due tentativi consecutivi usando una proprietà pubblica in RetryTransactionException ( se si tratta dell'eccezione usata per causare i tentativi).

Gli ambiti atomici hanno restrizioni sull'annidamento di altre transazioni che non possono annidare altre transazioni o includere blocchi Catch - Exception .

Transazioni DTC

Sebbene le transazioni atomiche si comportino come transazioni DTC, non sono esplicitamente transazioni DTC per impostazione predefinita. È però possibile renderle esplicitamente transazioni DTC, a condizione che gli oggetti utilizzati in esse siano oggetti COM+ derivati da System.EnterpriseServices.ServicedComponents e che i livelli di isolamento tra i componenti delle transazioni siano compatibili.

Nota

Una transazione atomica non può contenere altre transazioni né gestori eccezioni.

Nota

Una transazione atomica non può contenere azioni di invio e ricezione corrispondenti, ovvero una coppia di richieste-risposta o un invio e una ricezione che usano lo stesso set di correlazione.

Oggetti non serializzabili

Se si desidera utilizzare un oggetto non serializzabile in un'orchestrazione, è necessario utilizzarlo solo in una transazione atomica. Qualsiasi utilizzo di un oggetto del genere all'esterno di una transazione atomica potrebbe causare una perdita di dati ogni volta che l'orchestrazione viene resa persistente dal motore.

Attenzione

Ogni ambito atomico rappresenta un punto di persistenza e questo significa che lo stato dell'orchestrazione verrà salvato nel database a ogni punto di persistenza. L'uso estensivo di ambiti atomici aumenta la latenza nell'orchestrazione. Invece di utilizzare un ambito atomico allo scopo di creare oggetti non serializzabili, è possibile utilizzare chiamate a metodi statici che non richiedono ambiti atomici, eliminando così la necessità di punti di persistenza.

Vedere anche

Scenari che usano transazioni atomiche
Transazioni con esecuzione prolungata