Scenari che utilizzano transazioni atomiche
Negli scenari seguenti viene illustrato l'utilizzo delle transazioni atomiche.
Scenario 1: transazione atomica con COM+ ServicedComponent
L'orchestrazione seguente illustra come usare RetryTransactionException con transazioni atomiche. Sebbene i gestori di eccezioni non possano essere inclusi direttamente per un singolo ambito, l'ambito può includere un ambito non transazionale che può includere un gestore di eccezioni. ServicedComponent inserisce nella stessa transazione DTC e qualsiasi eccezione generata dal componente viene rilevata e generata nuovamente come RetryTransactionException. Si presuppone che la proprietà Retry sia impostata su True per l'ambito atomico.
Si noti che l'orchestrazione sarebbe stata sospesa e l'azione nella forma MessageAssignment sarebbe stata eseguito il rollback anche se retryTransactionException non viene generata. Questo modello consente tuttavia la generazione di resilienza nell'applicazione in cui i tentativi vengono eseguiti automaticamente.
Transazione atomica con ServicedComponent COM+
Scenario 2: Uso di adattatori Transacted con transazioni atomiche
L'orchestrazione seguente mostra come utilizzare le transazioni atomiche con l'adapter SQL. L'intera orchestrazione è contrassegnata a lungo con singole transazioni atomiche per le due operazioni logiche: inserimento di un nuovo cliente e inserimento dei dettagli dell'ordine per il cliente.
Se, per qualunque motivo, l'inserimento dell'ordine non riesce, è necessario eseguire il rollback dell'inserimento del cliente (Customer Insert). Per eseguire il lavoro del database, nell'esempio viene utilizzato l'adapter SQL. Come accennato in precedenza, l'ambito associato a una transazione atomica viene completato quando il messaggio viene inviato al database MessageBox. Ciò implica che, quando il motore ha eseguito correttamente l'invio dei messaggi negli ambiti Scope_InsertCustomer e Scope_InsertOrder, viene eseguito il commit di ognuno degli ambiti. L'adapter SQL crea una nuova transazione per l'inserimento corrente del cliente o dell'ordine.
Le porte hanno una proprietà denominata "Notifica di recapito" che viene utilizzata per notificare che il messaggio è stato inviato correttamente mediante la porta di trasmissione. Quando questa proprietà è impostata su "Trasmesso", prima del punto di commit transazionale dell'operazione di trasmissione viene inserita una sottoscrizione di ricezione. Nel caso di singoli ambiti la sottoscrizione di ricezione viene invece inserita nel relativo ambito padre.
Nello scenario in cui la transazione InsertOrder SQL non viene eseguita, verrà restituito un NACK e verrà eseguito il commit di "Scope_InsertOrder". Una volta esaurito il numero di tentativi configurato per la porta di trasmissione, verrà generata un'eccezione DeliveryFailureException. Questa eccezione verrà rilevata dal gestore di eccezioni predefinito, che eseguirà il processo di compensazione predefinito. Verranno quindi richiamati i gestori di compensazioni associati agli ambiti Scope_InsertCustomer e Scope_InsertOrde, causando l'annullamento dell'operazione di inserimento delle informazioni sul cliente.
Nota
Se i due ambiti vengono nidificati in un ambito a esecuzione prolungata e si richiama la forma Compensazione (avente come destinazione la transazione a esecuzione prolungata) dal gestore di eccezioni per l'ambito a esecuzione prolungata, il comportamento risulterà uguale a quello descritto sopra. L'intera orchestrazione potrebbe non essere contrassegnata come atomica in quanto le transazioni atomiche non consentono le transazioni nidificate.
Adapter sottoposti a transazione con transazioni atomiche
