CORBAサーバー・アプリケーションの作成

マルチスレッドCORBAサーバー・アプリケーションの作成

ここでは、以下の内容について説明します。

概要

ここでは、以下の内容について説明します。

はじめに

複数の独立したスレッドを使用するようにアプリケーションを設計すると、アプリケーション内に同時実行性がもたらされ、総合的なスループットを改善できます。複数のスレッドを使用すると、各スレッドが複数の独立したタスクを並列に処理する効率的なアプリケーションを構築できます。マルチスレッドは、以下の場合に特に役立ちます。

歴史的に見て、業界レベルのマルチスレッド・アプリケーションの設計と実装は複雑なものでした。Oracle Tuxedoが提供するサポートは、スレッドをCORBAサーバー環境の内部で管理することによって、こうした複雑さを単純化します。

Oracle Tuxedoソフトウェアは、次のマルチスレッド特性を備えたサーバー・アプリケーションをサポートします(図4-1を参照)。

通常、Oracle Tuxedoソフトウェアは、サーバー・アプリケーションのかわりにスレッドを作成および管理します。マルチスレッド・サーバー・アプリケーションをビルドする場合、TPフレームワークの使い方、サーバントの実装方法、および独自のスレッドを作成するオブジェクトの設計方法が変わります。

Oracle Tuxedoソフトウェアを使用すると、リクエストごとのスレッド・モデルとオブジェクトごとのスレッド・モデルのいずれかを実装できます。各モデルについては、「スレッド・モデル」で説明します。

要件、目標、概念

コンピュータ操作の中には、完了するのに長い時間を要するものがあります。マルチスレッド設計では、操作のリクエストと完了の間の待機時間を飛躍的に短縮できます。これは、データベースにアクセスするとき、リモート・オブジェクトの操作を呼び出すとき、マルチ・プロセッサ・マシン上のCPUバウンドなど、操作が大量のI/O操作を実行する環境に当てはまります。サーバー・プロセスでマルチスレッドを実装すると、サーバーが一定時間に処理できるリクエストの数が増加します。

マルチスレッド・サーバー・アプリケーションの主要な要件は、複数のクライアント・リクエストを同時に処理することです。この種のサーバーを開発する目的は次のとおりです。

ただし、マルチスレッド設計にはコストがかかります。通常、マルチスレッド・サーバー・アプリケーションでは、シングル・スレッド・サーバーより複雑な同期手法が必要になります。アプリケーション開発者は、スレッド・セーフなコードを記述する必要があります。また、スレッドを作成してリクエストを処理するオーバーヘッドが並列処理のメリットより大きくなる場合もあります。特定の同時実行性モデルの実際のパフォーマンスは、次の要因によって決まります。

スレッド・ライブラリは同時実行性モデルを作成するためのメカニズムを提供しますが、そのメカニズムを適切に使用する方法を最終的に理解するのは開発者です。デザイン・パターンを学習することによって、アプリケーション開発者は微妙な差異を理解し、様々な状態に応じた設計を選択できるようになります。

スレッド・モデル

サーバー内の同時実行性を設計するために使用できるモデルはいくつか存在します。以降の項では、リクエストごとのスレッド・モデル、オブジェクトごとのスレッド・モデル、スレッド・プール、およびOracle Tuxedoソフトウェアが各モデルを実装する方法について説明します。特定のサーバーは、リクエストごとのスレッド・モデルかオブジェクトごとのスレッド・モデルのいずれかに対応するよう設計されます。

リクエストごとのスレッド・モデル

このモデルでは、クライアントからの各リクエストは別々の制御スレッドで処理されます。このモデルは、サーバーが一般に複数のクライアントから長期のリクエストを受信するときに役立ちます。短期のリクエストの場合、リクエストごとに新しいスレッドを作成するオーバーヘッドが大きくなるので、あまり役立ちません。新しいリクエストが到着するたびに、Oracle Tuxedoはそのリクエストをスレッドに関連付けて、そのリクエストを実行します。マルチスレッド・アプリケーション・サーバー・プロセスは一度に複数のスレッドをホストできるので、一度に複数のクライアント・リクエストを同時に実行できます。Oracle Tuxedoは、リクエストとスレッドの関連付けを制御します。このため、アプリケーションはOracle Tuxedoより強力な制御を必要としない限り、スレッドを明示的に作成する必要がありません。

リクエストごとのスレッド・モデルでは、アプリケーション・サーバーをスレッド・セーフにする必要があります。つまり、複数のサーバー・オブジェクト間で共有されるデータへのアクセスを制御するための同時実行性メカニズムを実装する必要があります。同時実行性制御メカニズムを使用しなければならない場合、アプリケーション開発プロセスが複雑化します。さらに、多数のクライアントが同時にリクエストを行った場合、この設計ではオペレーティング・システム・リソースが大量に消費される可能性があります。

オブジェクトごとのスレッド・モデル

オブジェクトごとのスレッド・モデルでは、サーバー・プロセス内のアクティブ化された各オブジェクトが常に1つのスレッドに関連付けられます。オブジェクトに対するリクエストごとに、ディスパッチ・スレッドとオブジェクトとの関連付けが確立されます。同じオブジェクトに対する連続するリクエストは、別個のスレッドによって処理できます。特定のスレッドを複数のオブジェクトで共有できます。

スレッド・プール

スレッド・プールは、スレッドを管理するコストを削減するための手段です。起動時に必要に応じてスレッドの作成、割り当て、および解放を行うプール。スレッドは、次のリクエストの処理に必要となるまでプールで待機します。スレッド・プールを使用すると、前述のスレッド・モデルをサポートできます。たとえば、リクエストごとのスレッド・モデルでリクエストに対してスレッドを割り当て、メソッドの実行に使用して、プールに戻すことができます。

スレッドの割当てと割当て解除には、特にリクエストとオブジェクトの有効期間が短い場合、時間とコストがかかるおそれがあります。スレッド・プールは、スレッドを管理するコストを削減するための手段です。起動時に、または必要に応じて、Oracle Tuxedoソフトウェアは利用可能なスレッドのプールにスレッドを作成し、そのプールからスレッドを割り当てて、そのプールにスレッドを戻します。スレッドはプールに存在し、以後のリクエストの処理に必要となるまで待機します。

アプリケーション・サーバー・プロセス用のOracle Tuxedoスレッド・プールの初期サイズと最大サイズは、サーバー構成ファイルの設定値によって制御されます。起動時に、最小プール・サイズが事前に割り当てられます。処理するリクエストが到着すると、Oracle Tuxedoソフトウェアはプールからスレッドを割り当ててそのリクエストを処理します。リクエストの処理に利用可能なスレッドがプールに存在せず、プールに空きがある場合、Oracle Tuxedoソフトウェアは新しいスレッドを作成してそのリクエストを処理します。リクエストが到着したときに利用可能なスレッドがプールに存在せず、新しいスレッドを作成できない場合、そのリクエストはスレッドが利用可能になるまでキューに格納されます。

スレッド・プールは、サーバー・スレッドのために消費されるシステム・リソースの量を制限したい場合に適しています。スレッド・プールを使用すると、同時リクエストの数がプール内のスレッドの数を上回るまでクライアント・リクエストが同時に実行されます。

Oracle Tuxedoスレッド・プールには、次の特性と振る舞いがあります。

リエントラント・サーバント

Oracle Tuxedoソフトウェアは、オブジェクトが自身の操作を再帰的に呼び出すための機能を提供します。この機能を使用するときには、オブジェクトを実装する方法に十分な注意を払う必要があります。アプリケーション・コードは、共有される状態データへのアクセスの制御に必要なオペレーティング・システム同時実行性メカニズムを採用する必要があるからです。ProcessまたはDistribution Adapterデザイン・パターンを実装するオブジェクトを使用するケースなど、オブジェクトの共有状態がほとんどまたはまったく存在せず、リエントラントをサポートするのが比較的簡単な場合があります。

また、Oracle Tuxedoソフトウェアを使用すると、アクティブ化されたオブジェクトのメソッド呼出しのリエントラントを有効化または禁止することができます。リエントラントはデフォルトによって無効化されています。アクティブ化されたオブジェクトに対するリクエストが到着したときに、そのオブジェクトが異なるスレッドで別のリクエストを実行している場合、次の規則が適用されます。

このメソッドの使い方については、『CORBAプログラミング・リファレンス』を参照してください。

Currentオブジェクト

マルチスレッドCORBAサーバー・アプリケーション環境の最も重要な属性の1つは、Currentオブジェクトを適切に使用および管理できることです。このため、次のような振る舞いが保証されます。

Oracle Tuxedo製品は、OMG発行のORB Portability仕様によって定義されているマルチスレッド・モデルに準拠しています。この仕様は、OMG CORBA仕様に組み込まれています。Oracle Tuxedo製品では、CORBA::Currentから継承されたインタフェースの操作は、Currentオブジェクトが取得されたスレッドに関連付けられている状態ではなく、操作が呼び出されるスレッドに関連付けられている状態にアクセスできます。この振る舞いの理由は次の2つです。

マルチスレッド環境で使用する場合、次のオブジェクトの振る舞いはORB Portability仕様に合致します。

たとえば、アプリケーションがあるスレッドから別のスレッドにトランザクションを受け渡す場合、そのアプリケーションはCosTransactions::Currentオブジェクトを使用してはなりません。かわりに、アプリケーションはほかのスレッドにCosTransactions::Controlオブジェクトを受け渡します。CosTransctions::Currentオブジェクトを受け渡すと、受信側のスレッドはそのスレッドに関連付けられているトランザクション状態だけにアクセスできます。

マルチスレッドCORBAサーバーをサポートするためのメカニズム

この項では、Oracle Tuxedo CORBAに用意されているマルチスレッド・サーバー・アプリケーションをサポートする以下のツール、API、および管理機能の概要について説明します。

コンテキスト・サービス

オブジェクト実装に独自のスレッドを作成して管理することを選択できます。ほかのスレッドは、Oracle Tuxedo CORBAソフトウェアによって自動的に管理されます。Oracle Tuxedo CORBAソフトウェアは、作成および管理する各スレッドのコンテキスト情報を内部に保持します。この必須コンテキスト情報は、CORBAリクエストの処理中に使用されます。Oracle Tuxedo CORBAは、アプリケーションがいつ独自のスレッドを作成して削除するかに関する知識を持ちません。このため、プログラマはコンテキスト・サービス・メカニズムを使用して、Oracle Tuxedoサービスの呼出し前に独自のスレッドを適切に初期化し、スレッドの削除時に不要になったコンテキスト・リソースを解放できます。

次のORBメソッド・セットは、スレッド管理の要件を満たします。これらのメソッドを、まとめてコンテキスト・サービスと呼びます。

TPフレームワークのクラスとメソッド

Oracle Tuxedo TPフレームワークの次のクラスとメソッドは、マルチスレッド・サーバー・アプリケーションをサポートします。

buildコマンドの機能

buildobjserverコマンドとbuildobjclientコマンドには、次のスレッド管理機能が組み込まれています。

管理用ツール

Oracle Tuxedoシステムは、アプリケーションを開発および実行するための構成ファイルを使用します。通常、アプリケーション開発者がこれらのファイルを作成し、Oracle Tuxedoシステム管理者が必要に応じてその内容を修正し、アプリケーションとシステムの要件を満たします。

スレッドのサポートに関連する制御パラメータでは、次のことを指定します。

UBBCONFIGファイルのスレッド・パラメータの詳細は、「UBBCONFIGファイルの例」を参照してください。

マルチスレッド・システムでのシングル・スレッド・サーバー・アプリケーションの実行

Oracle Tuxedo CORBAのスレッド・サポートのデフォルトの振る舞いは、シングル・スレッド・サーバー・サポート環境をエミュレートすることです。マルチスレッド環境でシングル・スレッドCORBAアプリケーションを実行する場合は、サーバー・アプリケーション・コードと構成ファイルを変更する必要がありません。ただし、既存のシングル・スレッド・アプリケーションを実行する前に、buildobjserverコマンドとbuildobjclientコマンドを使用してそのアプリケーションを再ビルドする必要があります。サーバー・アプリケーションのマルチスレッドを有効化しなかった場合、そのアプリケーションはシングル・スレッド・サーバーとして動作します。

マルチスレッドCORBAサーバー・アプリケーションの開発とビルド

ここでは、以下の内容について説明します。

buildobjserverコマンドの使い方

buildobjserverコマンドは、次の機能を通じてCORBAサーバー・アプリケーションをサポートします。

プラットフォーム固有のスレッド・ライブラリ

buildobjserverコマンドによって生成されるサーバー・アプリケーションは、適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、適切なプラットフォーム固有のスレッド・サポート・ライブラリを使用してリンクされます。これにより、Oracle Tuxedoソフトウェアが提供する共有ライブラリとの互換性が保証されます。

マルチスレッド・サポートの指定

マルチスレッドをサポートするCORBAサーバー・アプリケーションを作成する場合は、アプリケーションをビルドするときにbuildobjserverコマンドで-tオプションを指定する必要があります。実行時に、Oracle Tuxedoシステムは、実行可能プログラムと、CORBAサーバー・アプリケーションの構成ファイルUBBCONFIGで選択されたスレッド・モデルとの互換性を検証します。UBBCONFIGファイルでスレッド・モデルを設定する方法は、「UBBCONFIGファイルの例」を参照してください。

構成ファイルに互換性のないスレッド・モデルを指定してシングル・スレッドの実行可能プログラムを起動しようとすると、次のイベントが発生します。

代替サーバー・クラスの指定

ServerBaseクラスから継承された独自のServerクラスを実装する場合は、buildobjserverコマンドで-bオプションを使用してその代替Serverクラスを指定する必要があります。buildobjserverコマンドは、次の構文で-bオプションをサポートしています。

buildobjserver [-v] [-o outfile] [-f {firstfiles|@def-file}] 
[-l {lastfiles|@def-file}] [-r rmname] [-b bootserverclass] [-t] 

上の構文で、bootserverclassの値は、CORBAサーバー・アプリケーションの起動時に使用されるC++クラスを指定します。-bオプションを指定しない場合、Oracle TuxedoシステムはServerという名前でクラスのインスタンスを作成します。

-bオプションを指定する場合、Tuxedoシステムは代替サーバー・クラスのメイン関数を作成し、プロジェクトは-bオプションで指定したbootserverclassの名前を持つヘッダー・ファイルを提供する必要があります。ヘッダー・ファイルには、代替C++クラスの定義が含まれます。この代替Serverクラスは、ServerBaseクラスから継承される必要があります。

たとえば、コマンドラインで-b AslanServerと指定した場合、アプリケーション・プロジェクトはAslanServer.hファイルを提供する必要があります。AslanServer.hファイルは、bootserverclass.hファイルの例です。bootserverclassファイルは、このサンプル・コードと同じようなロジックを提供します。

// File name: AslanServer.h
#include <Server.h> 
class AslanServer : public ServerBase {
    public:
     CORBA::Boolean initialize(int argc, char** argv);
     void release();
     Tobj_Servant create_servant(const char* interfaceName);
      Tobj_Servant create_servant_with_id(const char* interfaceName,
                                          const char* stroid);
     CORBA::Boolean thread_initialize(int argc, char** argv);
     void thread_release();
}; 

buildobjclientコマンドの使い方

buildobjclientコマンドを使用してクライアント・アプリケーションの実行可能プログラムを作成する場合、アプリケーションは適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、使用するオペレーティング・システム用の適切なスレッド・サポート・ライブラリを使用してリンクされます。これにより、Oracle Tuxedoソフトウェアが提供する共有ライブラリとクライアントの互換性が保証されます。

非リエントラント・サーバントの作成

Oracle Tuxedo CORBA環境でCORBAサーバー・アプリケーションを実行するには、buildobjserverコマンドでそのアプリケーションをビルドしておく必要があります。

buildobjserver -tオプションを使用すると、Oracle TuxedoシステムにCORBAサーバー・アプリケーションがスレッド・セーフであることを通知できます。-tオプションは、アプリケーションが共有コンテキスト・データ、およびスレッド・セーフではない他のプログラミング構造を使用しないことを示します。スレッド・セーフではないシングル・スレッド・アプリケーションをマルチスレッド環境で実行すると、データが破損するおそれがあります。

アプリケーションの構成ファイルを更新してマルチスレッド・サポートを有効化したにもかかわらず、サーバー実装がリエントラントをサポートできることをアプリケーション・コードに指定していない場合、次のことに注意してください。

リエントラント・サーバントの作成

マルチスレッド・リエントラント・サーバントは、次の手順で作成します。

マルチスレッド・リエントラント・サーバントを作成する場合、そのオブジェクトの実装コードはそのオブジェクトの状態を保護して、複数のスレッドがそのオブジェクトと対話している間その整合性を保証する必要があります。

クライアント・アプリケーションに関する考慮事項

次に、Oracle Tuxedo環境で実行されるCORBAクライアント・アプリケーションに関する考慮事項を挙げます。

マルチスレッドsimpappサンプル・アプリケーションのビルドと実行

ここでは、以下の内容について説明します。

simpappマルチスレッド・サンプルについて

Oracle Tuxedoソフトウェアには、クライアント・プログラムとCORBAサーバー・プログラムで構成されるマルチスレッドCORBAサンプル・アプリケーションが用意されています。サーバーは、クライアントからアルファベットの文字列を受信し、大文字と小文字の文字列を返します。simpapp_mtのマルチスレッド機能は、並列処理を提供します。この並列処理により、単一のサーバー・プロセスは、複数のオブジェクトまたは単一のオブジェクトに対する複数のクライアントの同時リクエストを処理できます。

サンプル・アプリケーションの機能

マルチスレッド・サーバーの目的は、1つまたは複数のクライアントからの複数のリクエストを並列に処理することです。simpapp_mtサンプル・アプリケーションは、buildobjserver -tコマンドライン・オプションを使用し、UBBCONFIGファイルを使用して同時実行性手法を指定することによってマルチスレッド機能を例示するCORBAアプリケーションです。

simpapp_mtサンプルは、最初にSimplePerObjectというサーバー・プロセスを作成し、次にSimplePerRequestというサーバー・プロセスを作成します。クライアントは、最初にSimplePerRequestサーバーと通信し、次にSimplePerObjectサーバーと通信します。

SimplePerRequestのリクエストごとのスレッド・サーバー実装は、スレッド初期化メソッドを実装するユーザー定義のサーバー・クラスの使い方を例示します。SimplePerRequestサーバー・プロセスは、クライアントからの各リクエストを独立した制御スレッドで処理します。新しいリクエストが到着するたびに、そのリクエストを処理するためにスレッド・プールからスレッドが割り当てられます。リクエストが処理され、応答が送信されると、そのスレッドはプールに戻されます。このモデルは、複数のクライアントからの長期のリクエストを処理するサーバーに適しています。

simpapp_mtサンプル・アプリケーションは、次のメソッドを持つCORBAオブジェクトの実装を提供します。

図4-2に、オブジェクトごとのスレッド・モデルとリクエストごとのスレッド・モデルの両方を使用するsimpapp_mtサンプル・アプリケーションの操作を示します。

simpappマルチスレッド・サンプル・アプリケーションのOMG IDLコード

この章で説明するsimpappマルチスレッド・サンプル・アプリケーションは、次の表に示すCORBAインタフェースを実装します。

リスト4-2に、simpapp_mtサンプル・アプリケーションのCORBAインタフェースを定義したsimple.idlファイルの内容を示します。

#pragma prefix "beasys.com"

interface Simple
{
     //Convert a string to lower case (return a new string)
     string to_lower(in string val);

     //Convert a string to upper case (in place)
     string to_upper(in string val);

     //Use other server to convert string to lower case
     string forward_lower(in string val);

     //Use other server to convert string to upper case
     string forward_upper(in string val);
};

interface SimplePerRequestFactory
{
     Simple find_simple();
};
interface SimplePerObjectFactory
{
     Simple find_simple();
};

サンプル・アプリケーションのビルドと実行の方法

この節では、simpapp_mtサンプル・アプリケーションをビルドおよび実行するプロセスをステップごとに説明します。図 4-3に、このプロセスの要約を示します。以降の項では、これらのタスクを実行する方法について説明します。

TUXDIR環境変数の設定

simpapp_mtサンプル・アプリケーションをビルドおよび実行する前に、TUXDIR環境変数がシステムで設定されていることを確認してください。通常、この環境変数はインストール・プロセス中に設定されます。この環境変数に適切なディレクトリが定義されていることを確認する必要があります。

TUXDIR環境変数は、Oracle Tuxedoソフトウェアがインストールされているディレクトリ・パスに設定されている必要があります。例:

Windows

TUXDIR=D:¥TUXDIR

UNIX

TUXDIR=/usr/local/TUXDIR

TUXDIR環境変数の検証

アプリケーションを実行する前に、次の手順を実行してこの環境変数に正確な情報が定義されているかどうかを確認してください。

Windows

echoコマンドを実行してTUXDIRの設定を表示します。

prompt> echo %TUXDIR%

UNIX

環境変数の設定の変更

環境変数の設定を変更するには、次の手順を実行します。

Windows

setコマンドを実行して、TUXDIRの新しい値を設定します。

prompt> set TUXDIR=directorypath

UNIX

サンプル・アプリケーションの作業ディレクトリの作成

simpappマルチスレッド・サンプル・アプリケーションの必須ファイルは、次のディレクトリに格納されています。

Windows

%TUXDIR%\samples\corba\simpapp_mt

UNIX

$TUXDIR/samples/corba/simpapp_mt

simpappマルチスレッド・ファイルをすべて格納する作業ディレクトリを作成します。

Windows

Windowsエクスプローラを使用してsimpapp_mtディレクトリをコピーするか、次のようにコマンド・プロンプトを使用します。

UNIX

ユーザー・インタフェース・ツールを使用してsimpapp_mtディレクトリのコピーを作成するか、次のようにコマンド・プロンプトを使用します。

表4-1に、アプリケーションをビルドおよび実行するためのsimpapp_mtファイルとその説明を示します。

すべてのファイルの権限のチェック

simpapp_mtサンプル・アプリケーションをビルドおよび実行するには、作業ディレクトリにコピーしたすべてのファイルに対するユーザー権限と読取り権限がなければなりません。権限をチェックし、必要な場合はそれらを変更します。

Windows

> attrib -R /S *.*

UNIX

> /bin/ksh

> chmod u+r work_directory/*.*

runmeコマンドを実行する

この項では、アプリケーションの実行に必要な手順について説明します。次のようにrunmeコマンドを入力します。

Windows

> cd work_directory

> ./runme

UNIX

> /bin/ksh

> cd work_directory

> ./runme.ksh

runmeコマンドは、以下の手順を自動化します。

simpapp_mtサンプル・アプリケーションは、runmeコマンドの実行中に次のメッセージを出力します。

Testing simpapp_mt
    cleaned up 
    prepared
    built
    loaded ubb
    booted
    ran
    shutdown
    saved results
  PASSED

simpapp_mtサンプル・アプリケーションのすべての実行時出力は、作業ディレクトリ内のresultsディレクトリに格納されます。実行時に作成された出力を見るには、次のファイルを参照します。

表4-2と表4-3に、runmeコマンドの実行によって作成されるファイルとその説明を示します。

サンプル・アプリケーションのステップ・バイ・ステップ実行

この項では、simpapp_mtサンプル・アプリケーションをステップ・バイ・ステップ・モードで実行する方法について説明します。simpapp_mtをステップ・バイ・ステップ・モードで実行するには、あらかじめrunmeコマンドを実行しておく必要があります。

次の手順に従って、simpapp_mtアプリケーションを実行します。

表4-4に、tmbootによって起動するサーバー・プロセスを示します。

クライアント・アプリケーションを実行すると、リスト4-3のようなメッセージが表示されます。

Number of simultaneous requests to post (1-50)?
String to convert using thread-per-request server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
String to convert using thread-per-object server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ

forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ

サンプル・アプリケーションの停止

別のサンプル・アプリケーションを実行する前に、simpapp_mtサンプル・アプリケーションを停止して、不要なファイルを作業ディレクトリからすべて削除する必要があります。

マルチスレッドCORBAサーバー・アプリケーションの管理

ここでは、以下の内容について説明します。

スレッド・プール・サイズの指定

スレッド・プールの最小サイズと最大サイズを指定するためのMAXDISPATCHTHREADSパラメータとMINDISPATCHTHREADSパラメータは、UBBCONFIGファイルのSERVERSセクションに存在します。これらのパラメータの指定例については、リスト4-4を参照してください。マルチスレッドCORBAアプリケーションは、これらの値を使用してスレッド・プールを作成および管理します。

MAXDISPATCHTHREADS

MAXDISPATCHTHREADSパラメータは、各サーバー・プロセスで生成される、同時に実行できるディスパッチ・スレッドの最大数を決定します。このパラメータを指定する際には、次の事項を考慮してください。

MAXDISPATCHTHREADSパラメータの値は、他のパラメータにも影響を与えます。たとえば、MAXACCESSORSパラメータはOracle Tuxedoシステムへの同時アクセス数を制御し、各スレッドは、1つのアクセサとしてカウントされます。マルチスレッド・サーバーのアプリケーションの場合、各サーバーの実行が構成されているシステム管理のスレッドの数を考慮しておく必要があります。システム管理のスレッドとは、アプリケーションで開始され管理されるスレッドとは対照的に、Oracle Tuxedoソフトウェアで開始され管理されるスレッドです。内部ではOracle Tuxedoが、利用可能なシステム管理のスレッドのプールを管理しています。クライアント・リクエストが受信されると、スレッド・プールから利用可能なシステム管理のスレッドがそのリクエストを実行するようにスケジューリングされます。リクエストが完了すると、システム管理のスレッドは利用可能なスレッドのプールに戻されます。

たとえば、システム内に4つのマルチスレッド・サーバーがあり、各サーバーが50個のシステム管理のスレッドを実行するように構成されている場合、これらのサーバーにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。

50 + 50 + 50 + 50 = 200アクセサ

MINDISPATCHTHREADS

サーバーが最初にブートされたときに開始されるサーバー・ディスパッチ・スレッドの数を指定するには、MINDISPATCHTHREADSパラメータを使用します。このパラメータを指定する際には、次の事項を考慮してください。

スレッド・モデルの指定

スレッド・モデルを指定するには、UBBCONFIGファイルのSERVERSセクションに定義されているCONCURR_STRATEGYパラメータを設定します。

CONCURR_STRATEGYパラメータを使用して、マルチスレッドCORBAサーバー・アプリケーションが使用するスレッド・モデルを指定します。CONCURR_STRATEGYパラメータは、次のいずれかの値を受け付けます。

CONCURR_STRATEGY = PER_REQUEST を指定してリクエストごとのスレッド・モデルを採用した場合、CORBAサーバー・アプリケーションの各呼出しはスレッド・プール内の任意のスレッドに割り当てられます。

CONCURR_STRATEGY = PER_OBJECTを指定してオブジェクトごとのスレッド・モデルを採用した場合、アクティブ化された各オブジェクトは常に1つのスレッドに関連付けられます。オブジェクトに対するリクエストごとに、ディスパッチ・スレッドとオブジェクトとの関連付けが確立されます。

MAXDISPATCHTHREADSの値が1より大きく、CONCURR_STRATEGYの値を指定しなかった場合、スレッド・モデルはPER_OBJECTに設定されます。

スレッド・モデルの特性の詳細は、「スレッド・モデル」を参照してください。

アクティブ化されたオブジェクトの数の指定

掲示板のアクティブ・オブジェクト・マップ表に格納されるマシンごとのオブジェクトの最大数を指定するには、MAXOBJECTSパラメータを使用します。この値は、構成ファイルのRESOURCESセクションとMACHINESセクションのいずれかで設定できます。RESOURCESセクションのMAXOBJECTS numberは、システム全体にわたる設定です。システム全体にわたる設定をマシンごとにオーバーライドするには、MACHINESセクションのMAXOBJECTS numberを使用します。

システム全体にわたる設定の場合、次のように指定します。

*RESOURCES
MAXOBJECTS number

特定のマシンのシステム全体にわたる設定をオーバーライドするには、次のように指定します。

*MACHINES
MAXOBJECTS = number

numberの値は、オペレーティング・システムのリソースによってのみ制限されます。

UBBCONFIGファイルの例

リスト4-4に、Oracle Tuxedo Threadsサンプル・アプリケーション用のUBBCONFIGファイルを示します。スレッドに関連するパラメータは、太字で示してあります。

*RESOURCES
     IPCKEY     55432
     DOMAINID   simpapp
     MAXOBJECTS 100
     MASTER     SITE1
     MODEL      SHM
     LDBAL      N

*MACHINES
     "sunstar"
     LMID         = SITE1
     APPDIR       = "/rusers1/lyon/samples/corba/simpapp_mt"
     TUXCONFIG    = "/rusers1/lyon/samples/corba/simpapp_mt/results/tuxconfig"
     TUXDIR       = "/usr/local/TUXDIR"
     MAXWSCLIENTS = 10
     MAXACCESSERS = 200

*GROUPS
     SYS_GRP
        LMID    = SITE1
        GRPNO   = 1
     APP_GRP1
        LMID    = SITE1
        GRPNO   = 2
     APP_GRP2
        LMID    = SITE1
        GRPNO   = 3

*SERVERS
     DEFAULT:
        RESTART = Y
        MAXGEN  = 5
     TMSYSEVT
        SRVGRP  = SYS_GRP
        SRVID   = 1
     TMFFNAME
        SRVGRP  = SYS_GRP
        SRVID   = 2
        CLOPT   = "-A -- -N -M"
     TMFFNAME
        SRVGRP  = SYS_GRP
        SRVID   = 3
        CLOPT   = "-A -- -N"
     TMFFNAME
        SRVGRP  = SYS_GRP
        SRVID   = 4
        CLOPT   = "-A -- -F"
     simple_per_object_server
        SRVGRP  = APP_GRP1
        SRVID   = 1
        MINDISPATCHTHREADS = 10
        MAXDISPATCHTHREADS = 100
        CONCURR_STRATEGY = PER_OBJECT
        RESTART = N
     simple_per_request_server
        SRVGRP  = APP_GRP2
        SRVID   = 2
        MINDISPATCHTHREADS = 10
        MAXDISPATCHTHREADS = 100
        CONCURR_STRATEGY = PER_REQUEST
        RESTART = N
     ISL
        SRVGRP  = SYS_GRP
        SRVID   = 5
     CLOPT   = "-A -- -n //sunbstar:2468 -d /dev/tcp"

*SERVICES