![]() ![]() ![]() ![]() |
この節では、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
テーブルを調べたときに、障害が発生したサーバに関連するレコードがあり、そのタイムスタンプが回復処理の開始時刻よりも前である場合、回復処理は失敗します。サーバを再起動してください。
![]() ![]() ![]() |