13 BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス

この章では、Oracle BPEL Process Managerでのトランザクションおよびフォルト伝播のセマンティクスについて説明します。ここでは、コールを開始するBPELインスタンスのトランザクション動作の構成および一方向の起動の実行方法について説明します。

この章には次の項が含まれます:

• 第13.1項「トランザクション・セマンティクスの概要」

• 第13.2項「一方向起動の実行の概要」

13.1 トランザクション・セマンティクスの概要

リリース11gのトランザクション・セマンティクスでは、コンポーネントの実行に使用される基礎となるJava Transaction API(JTA)インフラストラクチャを使用できます。この項では、BPEL Process Managerのトランザクション・セマンティクスについて説明します。

13.1.1 Oracle BPEL Process Managerのトランザクション・セマンティクス

以前のリリースと同様に、Oracle BPEL Process Managerでは、デフォルトの場合、リクエストに基づいて新規のトランザクションが作成されます。つまり、トランザクションが存在する場合は、そのトランザクションが一時停止され、新規のトランザクションが作成されます。子(新規)トランザクションが完了すると、マスター(一時停止された)トランザクションが再開します。

ただし、リクエストが非同期(一方向)の場合、トランザクションには次のいずれかの処理が適用されます。

• デハイドレーション・ストア(dlv_message表)に挿入するために継承されます。

• トランザクションに透過的に登録されます(トランザクションがある場合)。

メッセージの損失はありません。起動メッセージは、処理のためにデハイドレーション・ストアに挿入されるか、フォルトを介して顧客に通知されます。

リリース10.1.3.xでは、消費側プロセス(つまり、パートナ・リンク)と提供側プロセスに、複数のプロパティを設定していました。これらのプロパティを使用することで、実行を単一のグローバル・トランザクションにチェーンできました。消費側では、bpel.xmlファイルのパートナ・リンク・バインディングにtransaction=participateを設定しました。提供側では、bpel.xmlの<configurations>セクションにtransaction=participateを設定しました。

リリース11gでは、コールされるBPELコンポーネント(コール先プロセス)にのみtransactionという新しいプロパティを設定する必要があります。次のようにbpel.config.transactionを追加します。

• 新規BPELプロセスのための「BPELプロセスの作成」ダイアログ内。

• 既存のBPELプロセスのcomposite.xmlファイル内のBPELプロセス・サービス・コンポーネント・セクション内(bpel.config.の必須接頭辞に注意)。

このプロパティは、コールを開始するBPELインスタンスのトランザクション動作を構成します。

例13-1に詳細を示します。

例13-1 新規トランザクションの設定

<component name="InternalWarehouseService">
    <implementation.bpel src="InternalWarehouseService.bpel"/>
    <property name="bpel.config.transaction" 
         many="false" type="xs:string">required | requiresNew</property>
  </component>

使用可能な値は、requiredとrequiresNewの2つです。表13-1は、これらの値とその設定に基づいたBPELインスタンスの動作の要約を示しています。

表13-1 bpel.config.transactionプロパティの動作

対象	bpel.config.transactionがrequiredに設定されている場合	bpel.config.transactionがrequiresNewに設定されている場合
リクエスト/レスポンス(開始)起動	トランザクションがある場合はコール元トランザクションが結合され、トランザクションがない場合は新規トランザクションが作成されます。	常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。
bpel.config.oneWayDeliveryPolicyがsyncに設定されている一方向開始起動	起動されたメッセージは、同じトランザクションの同一スレッドを使用して処理されます。	常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。

注意: bpel.config.transactionプロパティは、中間プロセスのreceiveアクティビティには適用されません。この場合は、別のトランザクションの別のスレッドを使用してメッセージが処理されます。これは、相関が必要で常に非同期で処理されるためです。

bpel.config.transactionプロパティの設定方法の詳細は、第4.1.1項「BPELプロセス・サービス・コンポーネントの追加方法」およびC.1.1項「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

次の各項では、bpel.config.transactionをrequiredまたはrequiresNewに設定した場合のトランザクションおよびフォルト動作について説明します。

13.1.1.1 bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

表13-2では、BPELCallerプロセスがBPELCalleeプロセスをコールします。BPELCalleeプロセスでは、bpel.config.transactionプロパティがrequiresNewに設定されています。表13-2は、bpel.config.transactionがこの値に設定されている場合のフォルト伝播とトランザクション動作を示しています。

表13-2 bpel.config.transactionがrequiresNewに設定されているBPELCalleeへのBPELCallerによるコール

BPELCalleeの状態	BPELCalleeトランザクションの処理	BPELCallerの動作
フォルトでリプライ(<reply>を使用)した場合	保存されます。	フォルトを取得して捕捉します。
処理されないフォルトをスロー(<throw>を使用)した場合	ロールバックされます。	フォルトを取得して捕捉します。
フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合	ロールバックされます。	FaultTwoを取得します。
bpelx:rollbackフォルトをスロー(<throw>を使用)した場合	ロールバックされます。	リモート・フォルトを取得します。

13.1.1.2 bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる

表13-3では、BPELCallerプロセスがBPELCalleeプロセスをコールします。BPELCalleeプロセスでは、bpel.config.transactionプロパティがrequiredに設定されています。表13-3は、bpel.config.transactionがこの値に設定されている場合のフォルト伝播とトランザクション動作を示しています。

表13-3 bpel.config.transactionがrequiredに設定されているBPELCalleeへのBPELCallerによるコール

BPELCalleeの状態	BPELCallerの動作
フォルトでリプライ(<reply>を使用)した場合	フォルトを取得して捕捉します。BPELCallerがトランザクションを所有します。したがって、トランザクションを捕捉した場合、トランザクションはコミットされます。BPELCallerが処理しない場合は、グローバル・ロールバックが発生します。
フォルトをスロー(<throw>を使用)した場合	フォルトを取得して捕捉します。
フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合	FaultTwoを取得します。
bpelx:rollbackフォルトをスロー(<throw>を使用)した場合	そのトランザクション・ロールバックを取得します。そのロールバックを捕捉する方法はありません。このフォルトは処理されません。

たとえば、2つの同期プロセス(BPELMasterとBPELChild)を作成し、同じレコードを挿入する際にそれぞれが同じデータベース・アダプタ参照を使用するとします(したがって、権限キー(PK)違反が発生します)。双方にxADatasourceNameが設定されます。

bpel.config.transaction設定がないと、発生したフォルトは処理されず、BPELChildはロールバックされます。BPELMasterにcatchブロックがある場合、そのトランザクションはコミットされます。したがって、データベースのBPELMasterからのレコードで終了します。

BPELMasterでのフォルトも捕捉しなかった場合は、(2つの異なるトランザクションで)第2のロールバックを取得します。

同じテスト・ケースで、bpel.config.transactionがrequiredに設定され、フォルト・ハンドラが適切でない場合は、BPELMasterの未処理のフォルトに基づいてトランザクション全体がロールバックされます。

BPELChildからフォルトを捕捉してロールバック・フォルトをスローするように、BPELMasterにフォルト・ハンドラを追加すると、トランザクションはグローバルにロールバックされます。

この機能を使用して、トランザクション境界を管理し、エンドツーエンド・トランザクション・フローをモデル化できます(ソースおよびターゲットがトランザクションの場合)。

13.2 一方向起動の実行の概要

例13-2に示すように、一方向起動(および可能性のあるコールバック)は、一般的にWSDLファイルで公開されます。

例13-2 WSDLファイルの公開

<wsdl:operation name="process">
        <wsdl:input message="client:OrderProcessorRequestMessage"/>
    </wsdl:operation>

これにより、BPELプロセス・サービス・エンジンでは実行が2つの部分に分割されます。

• 第1の部分(常にコール元トランザクション内)では、デハイドレーション・ストアのdlv_message表への挿入が行われます(リリース10.1.3.xでは、inv_message表に挿入されていました)。

• 第2の部分では、トランザクションおよび新規スレッドで作業アイテムが実行され、新規インスタンスが作成されます。

スレッドが使用可能な場合はサービス・エンジンのスレッド・プール(インボーカ・スレッド)で実行されるため、スケーラビリティの点で様々なメリットがあります。一方で、即時に実行される保証がないというデメリットがあります。

一方向の操作に基づく同期タイプのコールが必要な場合は、onewayDeliveryPolicyプロパティを使用できます。これは、リリース10.1.3.xのdeliveryPersistPolicyプロパティと同じです。

bpel.config.oneWayDeliveryPolicyを次のように指定します。

• 新規BPELプロセスのための「BPELプロセスの作成」ダイアログ内。

• 既存のBPELプロセスのcomposite.xmlファイルのBPELプロセス・サービス・コンポーネント・セクション内。

この値がcomposite.xmlに設定されていない場合は、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザのoneWayDeliveryPolicyの値が使用されます。使用可能な値は、次のとおりです。

• async.persist: メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。

• async.cache: 受信した配信メッセージはメモリー内キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。async.cacheに設定すると、一方向メッセージの到着頻度が配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。

  高可用性環境でoneWayDeliveryPolicyをasync.cacheに設定すると、サーバー・クラッシュ発生時に実行途中の起動メッセージおよびコールバック・メッセージが失われたり、重複したりすることがあります。async.cacheに対しては、サーバーのフェイルオーバーはサポートされていません。詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

• sync: 同じスレッドで直接起動が発生します。呼出しキューのメッセージのスケジューリングはバイパスされ、BPELインスタンスが同期的に呼び出されます。この設定は、データベースのパフォーマンスに影響を与えることがあります。

bpel.config.oneWayDeliveryPolicyプロパティの設定方法の詳細は、第4.1.1項「BPELプロセス・サービス・コンポーネントの追加方法」およびC.1.1項「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。

表13-4は、メイン・プロセスがサブプロセスを非同期でコールする場合の動作を示しています。表13-4は、第13.1.1.1項「bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」および第13.1.1.2項「bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」に記載されているユースケースに基づいています。

表13-4 メイン・プロセスによる非同期でのサブプロセスのコール

条件	サブプロセスがフォルトをスローした場合	サブプロセスがbpelx:rollbackをスローした場合
onewayDeliveryPolicy=async.persist (BPELCalleeプロセスが別のスレッド/別のトランザクションで実行)	メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。	メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeインスタンスがロールバックされます。
onewayDeliveryPolicy=sync および transaction=requiresNew (BPELCalleeが同じスレッド/別のトランザクションで実行)	BPELCallerはFabricInvocationExceptionを受信します。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。	BPELCallerはFabricInvocationExceptionを受信します。BPELCalleeトランザクションがロールバックされます。
onewayDeliveryPolicy=sync および transaction=required (BPELCalleeが同じスレッド/同じトランザクションで実行)	BPELCalleeがフォルト状態になります。BPELCallerはFabricInvocationExceptionを受信します。BPELCallerにはフォルトを処理する機会があります。	トランザクション全体がロールバックされます。