13 BPELプロセスでのトランザクションおよびフォルト伝播のセマンティクス
この章の内容は次のとおりです。
13.1 トランザクション・セマンティクスの概要
リリース12cのトランザクション・セマンティクスでは、コンポーネントの実行に使用される基礎となるJava Transaction API (JTA)インフラストラクチャを使用できます。この項では、Oracle 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および12cでは、コールされるBPELコンポーネント(コール先プロセスと呼ばれます)にのみ、新しいtransactionプロパティを設定する必要があります。次のようにbpel.config.transactionを追加します。
-
新規BPELプロセスのための「BPELプロセスの作成」ダイアログ内。
-
既存のBPELプロセスの
composite.xmlファイル内のBPELプロセス・サービス・コンポーネント・セクション内(bpel.config.の必須接頭辞に注意)。
このプロパティは、コールを開始するBPELインスタンスのトランザクション動作を構成します。この設定を後で変更する必要がある場合は、プロパティ・インスペクタを使用できます。
次の例に詳細を示します。
<component name="InternalWareHouseService" version="2.0">
<implementation.bpel src="BPEL/InternalWareHouseService.bpel"/>
<property name="bpel.config.transaction" type="xs:string"
many="false">required | requiresNew | notSupported " </property>
</component>
表13-1は、required値(デフォルト値)およびrequiresNew値について説明し、設定に基づいたBPELインスタンスの動作の要約を示しています。
表13-1 bpel.config.transactionプロパティの動作
| 説明 | bpel.config.transactionがrequiredに設定されている場合 | bpel.config.transactionがrequiresNewに設定されている場合 |
|---|---|---|
|
リクエスト/レスポンス(開始)起動 |
トランザクションがある場合はコール元トランザクションが結合され、トランザクションがない場合は新規トランザクションが作成されます。 |
常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。 |
|
|
起動されたメッセージは、同じトランザクションの同一スレッドを使用して処理されます。 |
常に新規トランザクションが作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。 |
ノート:
bpel.config.transactionプロパティは、中間プロセスのreceiveアクティビティには適用されません。この場合は、別のトランザクションの別のスレッドを使用してメッセージが処理されます。これは、相関が必要で常に非同期で処理されるためです。
bpel.config.transactionプロパティの設定方法の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。
次の各項では、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の動作 |
|---|---|---|
|
フォルトでリプライ( |
保存されます。 |
フォルトを取得して捕捉します。 |
|
処理されないフォルトをスロー( |
ロールバックされます。 |
フォルトを取得して捕捉します。 |
|
フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合 |
ロールバックされます。 |
FaultTwoを取得します。 |
|
|
ロールバックされます。 |
リモート・フォルトを取得します。 |
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の動作 |
|---|---|
|
フォルトでリプライ( |
フォルトを取得して捕捉します。BPELCallerがトランザクションを所有します。したがって、トランザクションを捕捉した場合、トランザクションはコミットされます。BPELCallerが処理しない場合は、グローバル・ロールバックが発生します。 |
|
フォルトをスロー( |
フォルトを取得して捕捉します。 |
|
フォルト(FaultOne)でリプライ後、フォルト(FaultTwo)をスローした場合 |
FaultTwoを取得します。 |
|
|
そのトランザクション・ロールバックを取得します。そのロールバックを捕捉する方法はありません。このフォルトは処理されません。 |
たとえば、2つの同期プロセス(BPELMasterとBPELChild)を作成し、同じレコードを挿入する際にそれぞれが同じデータベース・アダプタ参照を使用するとします(したがって、権限キー(PK)違反が発生します)。双方にxADatasourceNameが設定されます。
bpel.config.transaction設定がないと、発生したフォルトは処理されず、BPELChildはロールバックされます。BPELMasterにcatchブロックがある場合、そのトランザクションはコミットされます。したがって、データベースのBPELMasterからのレコードで終了します。
BPELMasterでのフォルトも捕捉しなかった場合は、(2つの異なるトランザクションで)第2のロールバックを取得します。
同じテスト・ケースで、bpel.config.transactionがrequiredに設定され、フォルト・ハンドラが適切でない場合は、BPELMasterの未処理のフォルトに基づいてトランザクション全体がロールバックされます。
BPELChildからフォルトを捕捉してロールバック・フォルトをスローするように、BPELMasterにフォルト・ハンドラを追加すると、トランザクションはグローバルにロールバックされます。
この機能を使用して、トランザクション境界を管理し、エンドツーエンド・トランザクション・フローをモデル化できます(ソースおよびターゲットがトランザクションの場合)。
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に対しては、サーバーのフェイルオーバーはサポートされていません。 -
sync: 同じスレッドで直接起動が発生します。呼出しキューのメッセージのスケジューリングはバイパスされ、BPELインスタンスが同期的に呼び出されます。この設定は、データベースのパフォーマンスに影響を与えることがあります。
bpel.config.oneWayDeliveryPolicyプロパティの設定方法の詳細は、「BPELプロセス・サービス・コンポーネントの追加方法」および「プロパティ・インスペクタでデプロイメント・ディスクリプタのプロパティを定義する方法」を参照してください。
表13-4は、メイン・プロセスがサブプロセスを非同期でコールする場合の動作を示しています。表13-4は、「bpel.config.transactionがrequiresNewに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」および「bpel.config.transactionがrequiredに設定されているBPELCalleeプロセスがBPELCallerプロセスによってコールされる」に記載されているユースケースに基づいています。
表13-4 メイン・プロセスによる非同期でのサブプロセスのコール
| If | サブプロセスがフォルトをスローした場合 | サブプロセスがbpelx:rollbackをスローした場合 |
|---|---|---|
|
(BPELCalleeプロセスが別のスレッド/別のトランザクションで実行) |
メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。 |
メッセージは配信サービスに保存されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeインスタンスがロールバックされます。 |
|
および
(BPELCalleeが同じスレッド/別のトランザクションで実行) |
BPELCallerは |
BPELCallerは |
|
および
(BPELCalleeが同じスレッド/同じトランザクションで実行) |
BPELCalleeがフォルト状態になります。BPELCallerは |
トランザクション全体がロールバックされます。 |
|
および
または
|
リクエストが処理される前にコール元のスレッドが戻されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。メッセージは、データベースに保存されていないため、失われます。 |
リクエストが処理される前にコール元のスレッドが戻されるため、BPELCallerはレスポンスを取得しません。フォルトが処理されない場合は、BPELCalleeトランザクションがロールバックされます。メッセージは、データベースに保存されていないため、失われます。 |
13.3 トランザクションなしのビジネス・プロセスの実行
トランザクションを必要とせずにビジネス・プロセスを実行できます。トランザクションは、プロセス実行の次の場合にのみ使用されます。
-
内部の処理状態をバックエンド・データ・ストアに格納する必要がある場合のデハイドレーション・ポイント。
-
プロセスの実行中に監査証跡やインスタンスのトラッキング関連データを格納する場合。
13.3.1 トランザクションなしでBPELプロセスを使用するタイミング
トランザクションなしでビジネス・プロセスを実行することは、次のようなシナリオで役立ちます。
-
たとえば、flowNアクティビティが2000個のブランチを生成するBPELプロセスがあると仮定します。各ブランチでは、応答時間が500msであるリモート同期Webサービスが起動されます。BPELプロセス・サービス・エンジンではflowNブランチを単一スレッドで個別に実行するため、2000個のブランチすべてを処理し、それぞれで同期Webサービスを起動すると、所要時間は1000秒近くかかり、この処理中にインスタンスはデハイドレーション・ポイントにアクセスしません。トランザクションの時間は1000秒に及ぶ可能性があり、タイムアウトが発生する場合があります(デフォルトのトランザクション・タイムアウトの設定は300秒です)。すべてを直接メモリーで実行できます。その際、トランザクションは不要です。
-
トランザクション期間は、ビジネス・プロセス実行のライフ・サイクルと結び付きます。たとえば、非同期BPELプロセスにreceiveアクティビティが含まれ、その後にassignアクティビティが続き、そこでは複雑なXSLトランスフォーメーションが大規模ドキュメントで実行され、所要時間が30秒になると仮定します。この後、クライアントへのコールバックが続きます。トランザクションで実行される場合、BPELプロセス・サービス・エンジンがトランザクションをreceiveアクティビティで起動し、インスタンス実行中にインスタンスのデータベース内部でロックを保持します。
別の方法として、すべてのアクティビティはメモリーで実行でき、エラーが発生すると廃棄できます。インスタンス実行中にデータベースの更新が発生しないため、トランザクションは必要ありません。インスタンス実行でBPELプロセス・サービス・エンジンでインスタンス状態などを更新するデハイドレーション・ポイントに達した場合にのみ、トランザクションが必要です。
-
BPELプロセスが、同期していて、BPELプロセス・サービス・エンジンのJTAトランザクションに参加している別のサービスまたはパートナ・リンクを起動すると仮定します(たとえば、BPELプロセスで、
TransactionAttribute=REQUIREDが設定されているTaskServiceBeanを起動する場合に、TaskServiceBeanタイムアウトがあり、トランザクションがロールバックされるなど)。BPELプロセス・サービス・エンジンのJTAトランザクションがロールバックされても、BPELプロセスではTaskServiceBeanのエラーを処理できません。 -
ビジネス・プロセスが同期サービスを起動した場合、そのサービスが複雑な処理を長時間実行すると、BPELプロセス・サービス・エンジンのトランザクションがタイムアウトする場合があります。同期サービスが適切に実行されても、ビジネス・プロセスでリモート・サービスからレスポンスを取得すると、BPELプロセス・サービス・エンジンはロールバックされます。
13.3.2 トランザクションなしの実行に関するガイドライン
トランザクションなしでビジネス・プロセスを実行するには、「BPELプロセスの作成」ダイアログでBPELプロセスを作成するときに、「トランザクション」リストから「notSupported」を選択します。
設定すると、次の動作が発生します。
-
XA分散トランザクションの利点がすべて無効になります。
ビジネス・プロセスが非トランザクション・モードで実行されるよう構成されている場合、インスタンス実行はXAトランザクションにおいてラップされず、その結果、インスタンスが重複する可能性がありますが、メッセージの損失はありません。トランザクションのオーバーヘッドがないため、非トランザクション・モードではパフォーマンスが向上します。重複インスタンスを許容可能な場所で、非トランザクション・オプションを使用できます。
-
トランザクションに参加することを期待されているパートナ(つまり、パートナは
TransactionAttributeがMANDATORYに設定されている)をビジネス・プロセスで起動できません。 -
ビジネス・プロセスからの起動はfire-and-forgetです。(つまり、起動が終了すると、パートナに配信されます。起動元のトランザクションが後でロール・バックされる場合でも、起動メッセージはロール・バックされません)。
bpel.config.transactionがnotSupportedに設定されていても、デハイドレーション・ポイントは、内部BPELプロセス・エンジンの状態をバック・エンドに保存するためにトランザクションを開始します。これは、デハイドレーションの概念が引き続きビジネス・プロセスに適用されることを意味します。この機能では、assign、invokeやその他のアクティビティがトランザクションなしで実行されることのみが保証されます。
このプロパティは、コールを開始する場合にBPELインスタンスのトランザクション動作を構成します。表13-5に、bpel.config.transactionのプロパティ設定に基づいたBPELインスタンスの動作を説明します。
表13-5 トランザクションのプロパティ設定に基づくBPELプロセス・インスタンス動作
| トランザクション・タイプ | トランザクション設定が「requiresNew」 | トランザクション設定が「required」 | トランザクション設定が「notSupported」 |
|---|---|---|---|
|
リクエスト/レスポンス(開始) |
新しいトランザクションが実行用に作成されます。既存のトランザクションがある場合はそのトランザクションが一時停止されます。 |
プロセスがコール元トランザクション(存在する場合)に参加するか、新規トランザクション(トランザクションがない場合)を作成します。 |
ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。 |
|
一方向(開始、 |
新規トランザクションが実行のために作成され、既存のトランザクションがある場合はそのトランザクションが一時停止されます。 |
起動メッセージは、同じトランザクションの同一スレッドを使用して処理されます。 |
ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。 |
|
一方向非同期 |
適用不可。 |
適用不可。 |
ビジネス・トランザクションのアクティビティはトランザクションなしで実行されます。トランザクションは、内部サービス・エンジンおよびインスタンスの状態や監査の詳細を保存するためにのみ使用されます。 |
13.3.3 トランザクションなしの同期BPELプロセスの作成方法
「BPELプロセスの作成」ダイアログで、トランザクションなしの同期BPELプロセスを作成できます。
トランザクションなしの同期BPELプロセスを作成するには:
- 「トランザクション」リストから、「notSupported」を選択します。図13-1に詳細を示します。
13.3.4 トランザクションなしの非同期BPELプロセスの作成方法
「BPELプロセスの作成」ダイアログで、トランザクションなしの非同期BPELプロセスを作成できます。
トランザクションなしの非同期BPELプロセスを作成するには:
- 「トランザクション」リストから、「notSupported」を選択します。図13-2に詳細を示します。
13.4 システム・パフォーマンスの向上のためのメモリー内SOAの使用
WebLogic Serverに関連付けられたCoherenceキャッシュを利用して、メモリー内の非トランザクションのビジネス・プロセスを実行できます。これにより、読取りおよび書込み操作がキャッシュから実行されるため、これらのビジネス・プロセスのパフォーマンスとスケーラビリティが向上します。また、連続したディスク読取りおよび書込みに関連するコストが大幅に削減されるため、データベース・パフォーマンスと管理も改善されます。
ノート:
このSOA Suite機能は、Oracle Integration Continuous Availabilityの一部です。Oracle SOA Suite for Middlewareのオプションの詳細は、Oracle Fusion Middlewareライセンス情報を参照してください。メモリー内SOAにより、短時間実行プロセスをメモリーに保持できます。フォルトが発生した場合のみ、またはwrite-behindスレッドを使用して一定の遅延間隔で、プロセスの状態がデータベースに書き込まれます。BPEL状態情報は、Coherenceキャッシュに/からデハイドレーションおよびリハイドレーションされます。
メモリー内SOAの有効化
メモリー内SOAは、「SOA管理」 > 「共通プロパティ」 > 「inMemoryEnvironment」の順に選択して有効化します。
/net/slc07yxw/scratch/share/wlst/enableInMemory.pyです(サーバーがデフォルトのポート7001で実行されていると仮定しています。ユーザーID: weblogic、パスワード: weblogic1。コピーを作成し、使用している環境用に更新してください)。connect('weblogic', 'weblogic1') custom() cd('oracle.as.soainfra.config/oracle.as.soainfra.config:name=soa-infra,type=SoaInfraConfig,Application=soa-infra')
set('InMemoryEnvironment', true)
exit()13.4.1 インメモリー・フロー・インスタンスに対する永続性の設定
ビジネス・フローを構成するコンポーネントの永続性の設定により、フロー、状態および監査データがキャッシュまたはデータベースにいつ保持されるかが決まります。このことは、Enterprise Manager Fusion Middleware Controlに表示されるフロー・インスタンス・データにも影響します。
表13-6に、様々な永続性の設定と、フロー、状態、監査およびセンサー・データにそれが及ぼす影響を示します。
表13-6 インメモリー・フロー・インスタンスに対する永続性の設定
| 完了永続ポリシー | 説明 | Enterprise Managerでのビジネス・フロー・インスタンス |
|---|---|---|
| 即時 | フロー・トレース、BPEL監査トレースおよびフロー・インスタンス状態データは、常にデータベースに保持されます。 | この動作は、メモリー内SOAが有効でない場合と同じです。 |
| 遅延 | フロー、監査および状態のすべてのデータは、最初にCoherenceキャッシュに保持されます。個別のwrite-behindスレッドが、データベースへのキャッシュの遅延書込みを実行します。write-behindスレッドは定期的にウェイクアップします(デフォルトは5分)。
データベース・ラウンドトリップ数が削減され、write-behindスレッドがウェイクアップするたびに、融合されたデータのみがデータベースに書き込まれます。 |
Enterprise Manager Fusion Middleware Controlですべてのフロー・インスタンスが表示されます。
ただし、write-behindスレッドによるデータベースへの書込みは遅延間隔ごとであるため、フロー・データの更新はwrite-behindスレッドで決定された間隔で発生します。Enterprise Managerは、データベースからそのデータを読み取ります。 |
| フォルト | 正常な実行の場合、フロー・トレース、BPEL監査トレースおよびフロー・インスタンス状態データは保持されません。フローにフォルトが発生した場合は、すべてのデータがデータベースに保持されます。フローがリカバリされると、フロー・データはすべてパージされます。
コンポーネントがデハイドレーション・ポイントに到達した場合は、状態データがCoherenceキャッシュに保持されます。 書込み遅延間隔をまたぐ長時間実行フローの場合、write-behindスレッドでは実行中インスタンスの状態をデータベースに一時的に保持します。インスタンスの実行が完了すると、これらはパージされます。 |
faulted完了永続ポリシーを使用するフローの場合、フォルト・フロー・インスタンスを除いて、Enterprise Manager Fusion Middleware Controlにフロー・インスタンスは表示されません。
長時間実行フロー・インスタンスがwrite-behindスレッドによってデータベースに保持されている場合は、Enterprise Managerに一時的に表示される可能性があることに注意してください。ただし、フロー・インスタンスが完了すると、このデータはパージされます。 |
文字列値 immediate、deferredおよびfaultedは、大/小文字の区別はありません。
ビジネス・フローはコンポジットおよびコンポーネントをまたぐことができるため、異なる永続性の設定を持つコンポーネントを含むフローの永続性は、保持するコンポーネントによって決まります。そのため、1つのコンポーネントがデータベースに保持されるように構成されている場合でも、フローのすべてのコンポーネントがデータベースに保持されます。
たとえば、あるBPELコンポーネントは永続性がdeferredに設定されていて、同じフロー内の別のBPELコンポーネントは永続性がimmediateに設定されている場合、immediate設定はdeferred設定をオーバーライドし、すべてのフロー・インスタンス状態およびフロー監査トレース・データはただちにデータベースに保持されます。同様に、1つのコンポーネントがdeferredに設定されていると、それ以外のすべてのコンポーネントがfaultedに設定されていても、永続性の設定のデフォルトはdeferredとなり、フロー、状態および監査データが保持されます。
ノート:
-
コンポーネントの状態およびコンポーネントの監査トレースは、コンポーネントに適用されている永続ポリシーに基づいて保持されます。フロー・インスタンス状態およびフロー監査トレースは、オーバーライド・ルールによって決定されます。このため、
immediateはdeferredをオーバーライドし、deferredはfaultedをオーバーライドします。 -
センサー・データはフロー・データごとに保持されます。フローがデータベースに保持される場合は、センサー・データもデータベースに保持されます。
インメモリー・フローに対する書込み遅延
write-delayスレッドで使用されるデフォルトの間隔は5分です。これは、5分ごとにキャッシュからデータベースにデータがコピーされることを意味します。
たとえば、ほとんどのBPELプロセスが5分ではなく6分で完了し、かつ、データベースの書込みを減らすためにwrite-delayを調整することが求められるなどの理由で、これを変更する場合は、次のサーバー起動引数をSOAサーバーに設定できます。
-Dsoa.cache.writebehindDelay=6mWebLogic Server管理コンソールを使用して、サーバー起動引数を設定できます。
13.4.2 メモリー内SOAを有効にするステップ
メモリー内SOAを有効にするには、Enterprise Managerでメモリー内SOAフラグを設定する必要があります。また、非トランザクション・ビジネス・プロセスを設計し、適切な完了永続ポリシー(faultedまたはdeferred)を使用する必要があります。
13.4.2.1 メモリー内SOAフラグの有効化
メモリー内で実行するように設計した1つ以上のビジネス・フローがある場合は、Enterprise Manager Fusion Middleware ControlでInMemoryEnvironmentフラグを設定する必要があります。InMemoryEnvironmentフラグをtrueに設定すると(デフォルトはfalse)、この機能を使用するように設計されているコンポーネント、コンポジットおよびフローに対して、メモリー内でSOA実行が行われます。
- 「SOAインフラストラクチャ」メニューから、「SOA管理」→「共通プロパティ」の順に選択します。
または、コンポジット・ページの「SOAコンポジット」メニューから、「SOAインフラストラクチャの共通プロパティ」を選択することもできます。
「SOAインフラストラクチャの共通プロパティ」ページが表示されます。 - 「InMemoryEnvironment」属性までスクロールします。「値」フィールドをtrueに設定します。
13.4.2.2 メモリー内で実行するビジネス・プロセスの設計
メモリー内で実行するビジネス・フローを構成するには、すべての構成BPELコンポーネントを非トランザクションとして設計する必要があります。この時点では、Coherenceキャッシュはトランザクション動作をサポートしていないため、非トランザクション・ビジネス・プロセスにのみメモリー内SOAを使用できます。また、すべてのBPELプロセスの完了永続ポリシーをdeferredまたはfaultedに設定する必要があります。
- 「BPELプロセスの作成」ダイアログの「一般」タブで、「トランザクション」に「notSupported」を選択します。
- 「メモリー内SOA」タブを選択し、完了永続ポリシーを指定します。
13.4.2.2.1 非トランザクションとしての既存のビジネス・プロセスの設定
ビジネス・プロセスがメモリー内SOAを使用できるようにするには、プロセスを非トランザクションとして設定する必要があります。
- 「値」にnotSupportedと入力します。
bpel.config.transactionプロパティが表示されます。「値」列にnotSupportedと表示されていることを確認します。13.4.2.2.2 既存のBPELプロセスの完了永続ポリシーの設定
ビジネス・プロセスがメモリー内SOAを使用できるようにするには、完了永続ポリシーをdeferredまたはfaultedに設定する必要があります。BPELプロセスがデハイドレーション・ポイントを検出すると、状態情報がデータベースではなくメモリーにキャッシュされます。
- 「値」にdeferredまたはfaultedと入力します。
bpel.config.completionPersistPolicyプロパティが表示されます。「値」列にdeferredまたはfaultedと表示されていることを確認します。