WebLogic Integration ソリューションのベストプラクティスに関する FAQ

WebLogic Integration アプリケーションの回復処理

この節では、WebLogic Integration アプリケーションの回復処理のコンフィグレーションに関する質問の回答を示します。内容は以下のとおりです。

回復処理のチェックリスト

回復処理のチェックリスト

この節では、以下の質問に対する答えを示します。

WebLogic Integration アプリケーションの回復処理が正しくコンフィグレーションされていることを確認するには、何を調べればいいですか。

WebLogic Integration アプリケーションが次のようにコンフィグレーションされていることを確認してください。

XA ドライバが cgPool 内にコンフィグレーションされている。
すべての JMS サーバのターゲットが移行可能なターゲットである (移行可能なターゲットには、ターゲット名に「移行可能 (migratable)」という言葉が含まれています)。

注意 : アクティブクラスタ内の 1 つまたは複数の JMS サーバのターゲットを変更する必要がある場合は、ターゲットのコンフィグレーションを変更した後にクラスタを再起動する必要があります。

WLAI_DataSource が cgPool をポイントしていない。ポイントしている場合は、WLAI_DataSource を削除するか、ポイント先を別のプールに変更します。

注意 : cgPool をポイントする WLAI_DataSource は、WebLogic Integration 8.1 SP1 の Configuration Wizard が生成するドメインのデフォルトコンフィグレーションです。これは、WebLogic Integration 8.1 SP2 で生成されるドメインでは問題にはなりません。

WLAI_DataSource のポイント先を別のプールに変更する方法については、『コンフィグレーションウィザードの使い方』の「操作ガイド」に記載されている「XA コンフィグレーションへの変更のガイドライン」を参照してください。

WLI System EJBs の WLI Admin コンポーネントのターゲットがクラスタである。WLI Admin のターゲットを確認するには、WLI System EJBs アプリケーション用の config.xml ファイルに保存されているコンフィグレーションを調べます。

注意 : WLI Admin のターゲットをクラスタに設定できるのは、JMS サーバのターゲットが移行可能ターゲットである場合だけです。

再試行回数と再試行間隔が適切である。再試行回数に再試行間隔を乗算した数値が、JTA の回復処理を実行するためにかかる時間を上回っている必要があります。

再試行回数と再試行間隔を調整する必要がある場合は、次の方法があります。

十分に検討した retry-count と retry-interval を JPD に設定する。
JPD プロジェクト (WebApp) ごとに、非同期キューとエラーキューの retry-count と retry-interval を設定する。

注意 : この方法では JPD の明示的な再試行設定を無視することになりますが、最も簡単な方法なので、この方法をお勧めします。

詳細については、『コンフィグレーションリファレンス』の「JMSQueue」を参照してください。

config.xml ファイルの JTA 属性 TimeoutSeconds の値が、XA 接続プールの JDBCConnectionPool.XA TransactionTimeout 属性の値よりも小さく設定されている。

TimeoutSeconds の詳細については、『コンフィグレーションリファレンス』の「JTA」を参照してください。

config.xml ファイルの JTA 属性である MaxTransactions の値が、回復処理の間にサーバ上で同時に発生するトランザクションの数より十分大きく設定されている。トランザクションが大量に発生するアプリケーションでは、この属性の値をデフォルト設定より大きくする必要があります。

MaxTransactions の詳細については、『WebLogic Server Administration Console オンラインヘルプ』の「[ドメイン] --> [コンフィグレーション] --> [JTA]」を参照してください。

config.xml ファイルの JDBCConnectionPool 属性である MaxCapacity の値が、実行キューの ThreadCount 属性の値よりも大きく設定されている。

MaxCapacity の詳細については、『コンフィグレーションリファレンス』の「JDBCConnectionPool」を参照してください。
Server ThreadCount の詳細については、『WebLogic Server パフォーマンスチューニングガイド』の「WebLogic Server のチューニング」に記載されている「デフォルトの実行キュースレッドのチューニング」を参照してください。

Oracle を使用している場合は、リポジトリテーブル dba_2pc_pending、dba_2pc_neighbors、および dba_pending_transactions を呼び出して回復処理を実行するための適切なパーミッションがある。パーミッションがない場合は、データベースエラーが発生し、回復処理は失敗します。

どのくらいの時間待ってから回復処理を開始すべきですか。

Oracle では、不明なトランザクションの発生が確認されるまで数分かかることがあります。Oracle が TM の消失を検出する前に回復処理を開始した場合、競合が発生する可能性があります。回復処理を開始する (サーバを再起動するか JTA の移行を実行する) 前に、数分間待ってください。

回復処理を開始した後で Oracle dba_2pc_pending テーブルを調べたときに、障害が発生したサーバに関連するレコードがあり、そのタイムスタンプが回復処理の開始時刻よりも前である場合、回復処理は失敗します。サーバを再起動してください。