アトミック トランザクションの使用シナリオ

次のシナリオでは、アトミック トランザクションの使用方法について説明します。

シナリオ 1: COM+ ServicedComponent を使用したアトミック トランザクション

次のオーケストレーションは、 RetryTransactionException をアトミック トランザクションと共に使用する方法を示しています。 例外ハンドラーはアトミックのスコープに直接含めることはできませんが、例外ハンドラーを持つ非トランザクション スコープはアトミックのスコープに含めることができます。 ServiceComponent は、同じ DTC トランザクションに参加し、コンポーネントによって発生した例外が検出され、RetryTransactionException として再スローされます。 (これは、アトミック スコープの Retry プロパティが True に設定されていることを前提としています)。

RetryTransactionException がスローされない場合でも、オーケストレーションが中断され、MessageAssignment 図形のアクションがロールバックされることに注意してください。 ただし、このパターンは、再試行が自動的に行われるアプリケーションでは回復性を高めることができます。

アトミック トランザクションと COM+ ServicedComponent

シナリオ 2: アトミック トランザクションでトランザクション アダプターを使用する

次のオーケストレーションでは、SQL アダプターをアトミック トランザクションと共に使用する方法について説明します。 オーケストレーション全体は、新しい顧客の挿入とその顧客の注文明細の挿入という 2 つの論理的な作業に対応する個別のアトミック トランザクションを含む長時間のオーケストレーションとしてマークされています。

注文の挿入が失敗した場合は、理由にかかわらず、顧客の挿入をロールバックする必要があります。 この例では、データベース操作を行う SQL アダプターを使用します。 前述したように、アトミック トランザクションに関連付けられたスコープは、メッセージがメッセージ ボックス データベースに送信された時点で完了します。 これは、エンジンが Scope_InsertCustomer スコープと Scope_InsertOrder スコープのメッセージを正常に送信した後で、各スコープがコミットすることを意味しています。 SQL アダプターは、顧客または注文の実際の挿入に対して新しいトランザクションを作成します。

ポートには、メッセージが送信ポートから正常に送信されたことを確認するための “配信通知” プロパティがあります。 “配信通知” プロパティが “送信済み” に設定されている場合、受信サブスクリプションは送信操作のトランザクション コミット ポイントの前に配置されます。 ただし、アトミック スコープの場合、受信サブスクリプションはそれを含んでいる親スコープ内に配置されます。

InsertOrder SQL トランザクションが失敗するシナリオでは、"NACK" が返信され、"Scope_InsertOrder" はコミットします。 送信ポートが構成された回数の再試行を終えると、DeliveryFailureException が発生します。 この例外は既定の例外ハンドラーによってキャッチされ、既定の補正プロセスが実行されます。 これにより、Scope_InsertCustomer および Scope_InsertOrder に関連付けられた補正ハンドラーが呼び出され、顧客情報の挿入を元に戻す操作が行われます。

Note

長時間スコープ内に 2 つのスコープを入れ子にし、長時間スコープの例外ハンドラーから長時間トランザクションをターゲットとする補正図形を呼び出すと、前述したものと同じ動作が行われます。 アトミック トランザクションでは入れ子になったトランザクションを許可していないため、オーケストレーション全体をアトミックとしてマークすることはできません。

トランザクション対象のアダプターとアトミック トランザクション