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

次の項では、WebLogic Serverでのプログラミングに関連する追加情報を示します。

• WebLogic Serverでのスレッドの使い方

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

• 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のような管理対象の環境での使用は適切ではありません。

詳細は、「ワーク・マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

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

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

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

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