プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Serverアプリケーションの開発
12c (12.2.1.3.0)
E90359-04
目次へ移動
目次

前
次

16 トピックのスレッド化とクラスタリング

WebLogic Serverでのスレッドの使用方法と、WebLogic Serverクラスタで使用するアプリケーションのプログラミング方法について説明します。

この章の内容は次のとおりです。

WebLogic Serverでのスレッドの使用

WebLogic Serverは高度なマルチスレッド・アプリケーション・サーバーであり、ホストしているモジュールのリソースの割り当て、同時実行性、およびスレッドの同期化を慎重に管理します。WebLogic Serverのアーキテクチャを最大限に活用するには、標準Java EE APIを使用して作成したアプリケーション・モジュールを構築する必要があります。

通常、サーバー側モジュールで新たなスレッドの作成が必要にならないアプリケーション設計をします。

  • 独自のスレッドを作成するアプリケーションはあまり効率がよくありません。JVMのスレッドは、慎重に割り当てる必要のある限られたリソースです。サーバーの負荷が増大すると、アプリケーションは停止するか、WebLogic Serverで障害を引き起こすことがあります。デッドロックやスレッドの不足のような問題は、アプリケーションに重い負荷がかかるまで発生しないことがあります。

  • マルチスレッド・モジュールは複雑なため、デバッグが困難になります。アプリケーションが生成したスレッドとWebLogic Serverスレッドの間の対話の場合、特に予測や分析が難しくなります。

これらの警告にもかかわらず、スレッドの作成が適切な状況もあります。たとえば、複数のリポジトリを検索して、結合された結果セットを返すアプリケーションの場合、メイン・クライアント・スレッドを同期的に使用する代わりに、各リポジトリの新しいスレッドを非同期的に使用して検索を実行すると、より速く結果が返されることがあります。

アプリケーション・コードでのスレッドの使用を決定したら、アプリケーションが作成するスレッドの数を制限できるようにスレッド・プールを作成します。JDBC接続プールのように、指定した数のスレッドをプールに割り当て、実行可能なクラスのプールから利用できるスレッドを取得します。プール内のすべてのスレッドが使用中の場合は、スレッドが戻されるまで待機します。スレッド・プールを使用すると、パフォーマンスの問題を回避し、WebLogic Serverの実行スレッドとアプリケーションの間のスレッドの割当ても最適化できます。

スレッドでデッドロックが発生しそうな場所を把握しておき、デッドロックが発生したら確実に処理します。設計を慎重に見直して、スレッドがセキュリティ・システムを危険にさらすことのないようにしておきます。

WebLogic Serverスレッドとの望ましくない対話を避けるには、WebLogic Serverモジュールの中でスレッドの呼出しを使用しないようにします。たとえば、作成するスレッドからは、エンタープライズBeanやサーブレットを使用しないでください。アプリケーション・スレッドは、TCP/IP接続による外部サービス、またはファイルの適切なロックや読み書きを行う外部サービスとの対話のような、独立していて分離されたタスクに使用するのが最適です。存続期間が短く、1つの目的を実行して終了する(スレッドをプールに戻します)スレッドの方が、他のスレッドと競合しません。

WebLogic Server上にデプロイされているアプリケーションにパッケージ化されるモジュール内に、デーモン・スレッドを作成しないようにしてください。サーブレットなどのアプリケーション・モジュール内にデーモン・スレッドを作成すると、元のデプロイメント内に作成されたデーモンが実行中のままになるので、アプリケーションを再デプロイできなくなります。

障害のポイントにクライアントを追加して、負荷が次第に大きくなるような状況でマルチスレッドのコードをテストします。アプリケーションのパフォーマンスとWebLogic Serverの動作を監視し、本番環境で障害が発生しないことを確認しておきます。

ワーク・マネージャAPIを使用した低レベルなスレッド化

ワーク・マネージャは、作業項目を同時に実行するための簡単なAPIを提供します。これにより、Java EEベースのアプリケーション(サーブレットやEJBを含む)において作業項目の同時実行をスケジューリングでき、スループットとレスポンス時間を向上させることができます。

アプリケーションでは、同時実行する作業項目をワーク・マネージャに送信し、後でその結果を収集できます。ワーク・マネージャが提供する一般的な「結合」演算によって、いずれかの作業項目が完了するのを待機したり、すべての作業項目が完了するのを待機したりできます。アプリケーション・サーバー仕様のワーク・マネージャでは、アプリケーション・サーバーでサポートされる低レベル・スレッド化APIを使用することもできますが、ほとんどのアプリケーションでは使用が難しく、サーブレットやEJBのような管理対象の環境での使用は適切ではありません。

『Oracle WebLogic Serverサーバー環境の管理』ワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください

WebLogic Serverクラスタのアプリケーションのプログラミング

JSPとサーブレット、およびEJBをWebLogic Serverクラスタにデプロイする場合、特定の要件および制限があります。また、クラスタでEJBまたはカスタムRMIオブジェクトを開発する場合、クラスタ・オブジェクトをJNDIツリーにバインドすることによる影響を理解しておく必要もあります。

WebLogic ServerのクラスタにデプロイされるJSPおよびサーブレットは、セッション・データを保持するために特定の要件に従う必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』HTTPセッション状態のレプリケーションに関する条件に関する項 を参照してください。

WebLogic ServerクラスタでデプロイされるEJBには、EJBのタイプによって制約があります。クラスタ内の様々なEJBタイプの機能については、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』WebLogic Enterprise JavaBeansの理解に関する項 を参照してください。EJBは、EJBデプロイメント記述子でプロパティを設定することでクラスタにデプロイできます。

クラスタ内でデプロイメント用にEJBまたはカスタムRMIオブジェクトを開発する場合は、『Oracle WebLogic Server JNDIアプリケーションの開発』クラスタ環境でのWebLogic JNDIの使用に関する項 を参照して、クラスタリングされたオブジェクトをJNDIツリーにバインドする影響について理解してください。