|
|
この節では、WebLogic Integration アプリケーションの回復処理のコンフィグレーションに関する質問の回答を示します。内容は以下のとおりです。
WebLogic Integration アプリケーションが次のようにコンフィグレーションされていることを確認してください。
cgPool にコンフィグレーションされています。| 注意 : | アクティブ クラスタ内の 1 つまたは複数の JMS サーバのターゲットを変更する必要がある場合は、ターゲットのコンフィグレーションを変更した後にクラスタを再起動する必要があります。 |
WLI System EJBs の WLI Admin コンポーネントのターゲットがクラスタである。WLI Admin のターゲットを確認するには、WLI System EJBs アプリケーション用の config.xml ファイルに保存されているコンフィグレーションを調べます。| 注意 : | WLI Admin のターゲットをクラスタに設定できるのは、JMS サーバのターゲットが移行可能ターゲットである場合だけです。 |
再試行回数と再試行間隔を調整する必要がある場合は、次の方法があります。
retry-count と retry-interval を JPD に設定する。retry-count と retry-interval を設定する。 | 注意 : | この方法では JPD の明示的な再試行設定を無視することになりますが、最も簡単な方法なので、この方法をお勧めします。 |
詳細については、『WebLogic Server コンフィグレーション リファレンス』の「JMSQueue」を参照してください。
config.xml ファイルの JTA 属性 TimeoutSeconds の値が、XA 接続プールの JDBCConnectionPool.XA TransactionTimeout 属性の値よりも小さく設定されている。
TimeoutSeconds の詳細については、『WebLogic Server コンフィグレーション リファレンス』の「JTA」を参照してください。
config.xml ファイルの JTA 属性である MaxTransactions の値が、 回復処理の間にサーバ上で同時に発生するトランザクションの数より十分大きく設定されている。トランザクションが大量に発生するアプリケーションでは、この属性の値をデフォルト設定より大きくする必要があります。
MaxTransactions の詳細については、『WebLogic Server Administration Console オンライン ヘルプ』の「ドメイン : コンフィグレーション : JTA」を参照してください。
config.xml ファイルの JDBCConnectionPool 属性である MaxCapacity の値が、実行キューの ThreadCount 属性の値よりも大きく設定されている。
MaxCapacity の詳細については、『WebLogic Server コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
Server ThreadCount の詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の｢WebLogic Server のチューニング｣にある「デフォルトの実行キュー スレッドのチューニング」を参照してください。
dba_2pc_pending、dba_2pc_neighbors、および dba_pending_transactions を呼び出して回復処理を実行するための適切なパーミッションがある。パーミッションがない場合は、データベース エラーが発生し、回復処理は失敗します。
Oracle では、不明なトランザクションの発生が確認されるまで数分かかることがあります。Oracle が TM の消失を検出する前に回復処理を開始した場合、競合が発生する可能性があります。回復処理を開始する (サーバを再起動するか JTA の移行を実行する) 前に、数分間待ってください。
回復処理を開始した後で Oracle dba_2pc_pending テーブルを調べたときに、障害が発生したサーバに関連するレコードがあり、そのタイムスタンプが回復処理の開始時刻よりも前である場合、回復処理は失敗します。サーバを再起動してください。
  
|
