WebLogic Integration ソリューションの可用性の維持には、WebLogic Platform ツールと、使用するエンタープライズ情報システム (EIS) に最適なアプリケーションが必要です。クラスタ環境で WebLogic Server の高可用性を維持する方法の概要については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。WebLogic Integration ソリューションの可用性を高めるコンフィグレーションについては、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration の高可用性について」を参照してください。
詳細については、以下のトピックを参照してください。
高可用性コンフィグレーション
Trading Partner Integration の場合、高可用性ソリューションをコンフィグレーションするには、以下の点に注意する必要があります。
- 『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration の高可用性について」にある「Trading Partner Integration」の説明に従って WebLogic Integration Administration Console を使用します。
高可用性コンフィグレーションのデプロイメント前のチェックリストについては、『WLI アプリケーション ライフ サイクルのベスト プラクティス』の「WLI のパフォーマンスに関するヒントとアプリケーションの回復」にある「回復処理のチェックリスト」を参照してください。
重要推奨事項
以下では、WebLogic Integration ソリューションの可用性に関する重要な推奨事項について説明します。
- アプリケーション開発時
- アプリケーションに関連付けられた非同期ディスパッチャ キューで JMS キューの再試行回数および再試行の遅延をコンフィグレーションして、JPD のトランザクション再試行のカウント (再試行回数 * 再試行の遅延) が、管理対象サーバの回復に必要な時間よりも長くなるようにします (アプリケーションに関連付けられた非同期ディスパッチャ キューの再試行回数および再試行の遅延パラメータをコンフィグレーションすると、JPD の再試行回数および再試行の遅延パラメータが上書きされます)。アプリケーションに関連付けられた非同期ディスパッチャ キューのこれらのプロパティをコンフィグレーションすることで、再試行パラメータを持たない特定の非同期コールバック (タイマー コントロール、プロセス コントロール) に関連する回復処理中の問題を防ぐことができます。
- JMS キューの再試行回数および再試行の遅延のコンフィグレーションについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。
- XA 対応エンタープライズ情報システムで障害が発生した場合
- 通常、WebLogic Server TransactionManager から EIS リソース マネージャにトランザクション完了の命令 (コミットまたはロールバック) を出せるようになるまで、トランザクションはアクティブなままになります。
- 以下のトピックも参照してください。
Microsoft SQL Server についての注意
コンフィグレーションに Microsoft SQL Server が含まれている場合 :
- DBMS 障害が発生したときに、DBMS インスタンスが実行中の管理対象サーバの任意の XA トランザクションから使用されていた場合、そのサーバには保留中の XA トランザクションが残されることがあります。管理対象サーバに保留中のトランザクションが存在する場合、完了待ちのトランザクションがあるため正常にシャットダウンできません。Microsoft SQL Server ドライバの回復処理の問題が原因で、これらのトランザクションが正常に完了 (コミットまたはロールバック) されない場合があり、正常にシャットダウンできなくなります。
- 正常な処理に回復させるには、「XA 対応エンタープライズ情報システムで障害が発生した場合」で説明されている推奨手順に従ってください。
- プロセスにコンフィグレーションされている再試行回数が少なすぎる場合に、複数の非同期要求を単一のステートフル プロセスに送信すると、要求がロールバックされることがあります。ロールバックが発生すると、次のような SQL デッドロック メッセージがログに記録されます。
Exception in ejbRemote java.sql.SQLException: [BEA][SQLServer JDBC Driver][SQLServer]Transaction (Process ID 67) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
- 再試行の設定の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。
コンフィグレーションに Oracle が含まれている場合 :
- DBMS 障害が発生したときに、DBMS インスタンスが実行中の管理対象サーバの任意の XA トランザクションから使用されていた場合、そのサーバには保留中の XA トランザクションが残されることがあります。管理対象サーバに保留中のトランザクションが存在する場合、完了待ちのトランザクションがあるため正常にシャットダウンできません。Oracle Thin ドライバの回復処理の問題が原因で、これらのトランザクションが正常に完了 (コミットまたはロールバック) されない場合があり、正常にシャットダウンできなくなります。
- 正常な処理に回復させるには、「XA 対応エンタープライズ情報システムで障害が発生した場合」で説明されている推奨手順に従ってください。
- 管理対象サーバで障害が発生し、Oracle に不明なトランザクションが残された場合、次の問題が発生することがあります。
- [プロセス インスタンス統計] ページまたは [プロセス インスタンス概要] ページにアクセスしようとすると例外が生成されます。管理対象サーバが回復するまでは、プロセス インスタンス情報の要求に対する WebLogic Integration Administration Console の処理能力が制限されます。
- 次の Oracle 例外が送出される場合があります。
ORA-01591: lock held by in-doubt distributed transaction global_tran_id
- 別のレコードを挿入すると、不明なトランザクションが原因でテーブルにエラーが発生することがあります。そのため、新しい Java プロセスを開始できない場合があります。このような場合、障害が発生した JTA サービスを再起動するか、移行します。移行にかかる時間を考慮し、実行中のプロセスに十分な再試行回数が設定されていることを確認します。
- 別のレコードを挿入すると、不明なトランザクションが原因でテーブルにエラーが発生することがあります。そのため、新しい Java プロセスを開始できない場合があります。このような場合、障害が発生した JTA サービスを再起動するか、移行します。移行にかかる時間を考慮し、実行中のプロセスに十分な再試行回数が設定されていることを確認します。
- JTA サービスの再起動および移行については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サーバ全体の移行」を参照してください。
- 再試行の設定の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。
- Oracle から回復サービスにトランザクションが返されるまで数分かかる場合があります。数分待機してから回復を開始します。Oracle の準備が整う前に JTA 回復を開始すると、回復に失敗することがあります。回復に失敗した場合は、再度回復を開始します。
- COMMIT または ROLLBACK のいずれかのコマンドを実行して、Oracle の不明なトランザクション (transaction_id) を管理面から解決することも可能です。以下に例を示します。
COMMIT FORCE 'local_tran_id'
ROLLBACK WORK FORCE 'local_tran_id'
- これを解決する別の管理的手法として、Oracle 認定システム管理者に依頼して、データベースの解析、不明なトランザクションが発生するテーブルの特定、およびそのテーブルのブロックごとの行数の削減を行うこともできます。このようなチューニングは慎重に行う必要があります。それらのブロックでトランザクションの重複が発生する可能性は低くなりますが、データベースのパフォーマンスに影響があるためです。
関連トピック
|