![]() |
![]() |
|
|
マルチスレッド CORBA サーバ・アプリケーションの作成
ここでは、次の内容について説明します。
概要
ここでは、次の内容について説明します。
はじめに
複数の独立したスレッドを使用するアプリケーションを設計すると、アプリケーション内の並行性が実現され、全体的なスループットが向上します。複数のスレッドを使用すると、各スレッドが複数の独立したタスクを並列に処理する効率的なアプリケーションを構築できます。マルチスレッドは、次の場合に特に役立ちます。
歴史的に見て、業界レベルのマルチスレッド・アプリケーションの設計とインプリメントは複雑なものでした。BEA Tuxedo が提供するサポートは、スレッドを CORBA サーバ環境の内部で管理することによって、こうした複雑さを単純化します。
BEA Tuxedo ソフトウェアは、次のマルチスレッド特性を備えたサーバ・アプリケーションをサポートします (図 4-1 を参照)。
図4-1 マルチスレッド CORBA サーバ・アプリケーション
通常、BEA Tuxedo ソフトウェアは、サーバ・アプリケーションの代わりにスレッドを作成および管理します。マルチスレッド・サーバ・アプリケーションをビルドする場合、TP フレームワークの使い方、サーバントのインプリメント方法、および独自のスレッドを作成するオブジェクトの設計方法が変わります。
BEA Tuxedo ソフトウェアを使用すると、要求ごとのスレッド・モデルか、オブジェクトごとのスレッド・モデルのいずれかをインプリメントできます。各モデルについては、「スレッド・モデル」で説明します。
要件、目標、概念
コンピュータ・オペレーションの中には、完了するのに長い時間を要するものがあります。マルチスレッド設計では、オペレーションの要求と完了の間の待機時間を飛躍的に短縮できます。これは、オペレーションが数多くの I/O オペレーションを実行する環境に当てはまります。たとえば、データベースにアクセスするとき、リモート・オブジェクトのオペレーションを呼び出すとき、マルチ・プロセッサ・マシン上の CPU バウンドなどです。サーバ・プロセスでマルチスレッドをインプリメントすると、サーバが一定時間に処理できる要求の数が増加します。
マルチスレッド・サーバ・アプリケーションの主要な要件は、複数のクライアント要求を同時に処理することです。この種のサーバを開発する目的は次のとおりです。
これは、既存のプログラミング抽象化を使用して複数のサーバ・タスクを独立して実行することにより達成されます。
これは、マルチプロセッサ・ハードウェア・プラットフォームの並列処理のメリットを活用し、計算処理と通信をオーバーラップさせることによって達成されます。
独立したスレッドを異なるサーバ・タスクに関連付けることによって、クライアントは長時間にわたって互いをブロックすることがなくなります。
独立したスレッドを使用して異なるリモート・プロシージャ・コール (RPC) と会話とのやり取りを実現すると、一部のアプリケーションのコーディングが簡単になります。
レガシー・アプリケーションまたはレガシー・データベースを CORBA サーバ内でラップすると、インプリメンテーションは一度に複数のレガシー・アプリケーションとやり取りできます。
1 つのサーバで複数のサービス・スレッドをディスパッチできるので、アプリケーションで必要なサーバの数を減らすことができます。
ただし、マルチスレッド設計にはコストがかかります。通常、マルチスレッド・サーバ・アプリケーションでは、シングル・スレッド・サーバより複雑な同期手法が必要になります。アプリケーション開発者は、スレッド・セーフなコードを記述する必要があります。また、スレッドを作成して要求を処理するオーバーヘッドが並列処理のメリットより大きくなる場合もあります。特定の同時実行モデルの実際の性能は、次の要因によって決まります。
要求の期間は長いですか、それとも短いですか。
スレッドはオペレーティング・システム・カーネル、ユーザ領域のライブラリ、両方の組み合わせのいずれで管理されますか。
接続を繰り返しセットアップおよび切断することによって発生するオーバーヘッドはどのくらいですか。
複製、動的ロード・バランシング、またはほかの要因が性能に影響を与えますか。
スレッド・ライブラリは同時実行モデルを作成するためのメカニズムを提供しますが、そのメカニズムを適切に使用する方法を最終的に理解するのは開発者です。デザイン・パターンを学習することによって、アプリケーション開発者は微妙な差異を理解し、さまざまな状態に応じた設計を選択できるようになります。
スレッド・モデル
サーバ内の並行性を設計するために使用できるモデルはいくつか存在します。以降の節では、要求ごとのスレッド・モデル、オブジェクトごとのスレッド・モデル、スレッド・プール、および BEA Tuxedo ソフトウェアが各モデルをインプリメントする方法について説明します。特定のサーバは、要求ごとのスレッド・モデルかオブジェクトごとのスレッド・モデルのいずれかに対応するよう設計されます。
要求ごとのスレッド・モデル
このモデルでは、クライアントからの各要求は別々の制御スレッドで処理されます。このモデルは、サーバが一般に複数のクライアントから長期の要求を受信するときに役立ちます。短期の要求の場合、要求ごとに新しいスレッドを作成するオーバーヘッドが大きくなるので、あまり役立ちません。新しい要求が到着するたびに、BEA Tuxedo はその要求をスレッドに関連付けて、その要求を実行します。マルチスレッド・アプリケーション・サーバ・プロセスは一度に複数のスレッドをホストできるので、一度に複数のクライアント要求を同時に実行できます。BEA Tuxedo は、要求とスレッドの関連付けを制御します。このため、アプリケーションは BEA Tuxedo より強力な制御を必要としない限り、スレッドを明示的に作成する必要がありません。
要求ごとのスレッド・モデルでは、アプリケーション・サーバをスレッド・セーフにする必要があります。つまり、複数のサーバ・オブジェクト間で共有されるデータへのアクセスを制御するための同時実行メカニズムをインプリメントする必要があります。同時実行制御メカニズムを使用しなければならない場合、アプリケーション開発プロセスが複雑化します。さらに、多数のクライアントが同時に要求を行った場合、この設計ではオペレーティング・システム・リソースが大量に消費される可能性があります。
オブジェクトごとのスレッド・モデル
オブジェクトごとのスレッド・モデルでは、サーバ・プロセス内の活性化された各オブジェクトが常に 1 つのスレッドに関連付けられます。オブジェクトに対する要求ごとに、ディスパッチ・スレッドとオブジェクトとの関連付けが確立されます。同じオブジェクトに対する連続する要求は、別個のスレッドによって処理できます。特定のスレッドを複数のオブジェクトで共有できます。
スレッド・プール
スレッド・プールは、スレッドを管理するコストを削減するための手段です。起動時に、および必要に応じて、利用可能なスレッドのプールにスレッドが作成され、プールからスレッドが割り当てられ、プールにスレッドが戻されます。プール内のスレッドは、以後の要求の処理に必要となるまで待機します。スレッド・プールを使用すると、前述のスレッド・モデルをサポートできます。たとえば、要求ごとのスレッド・モデルで要求に対してスレッドを割り当て、メソッドの実行に使用して、プールに戻すことができます。
スレッドの割り当てと割り当て解除には、特に要求とオブジェクトの存続期間が短い場合、時間とコストがかかるおそれがあります。スレッド・プールは、スレッドを管理するコストを削減するための手段です。起動時に、または必要に応じて、BEA Tuxedo ソフトウェアは利用可能なスレッドのプールにスレッドを作成し、そのプールからスレッドを割り当てて、そのプールにスレッドを戻します。スレッドはプールに存在し、以後の要求の処理に必要となるまで待機します。
アプリケーション・サーバ・プロセス用の BEA Tuxedo スレッド・プールの初期サイズと最大サイズは、サーバ・コンフィギュレーション・ファイルの設定値によって制御されます。起動時に、最小プール・サイズが事前に割り当てられます。処理する要求が到着すると、BEA Tuxedo ソフトウェアはプールからスレッドを割り当ててその要求を処理します。要求の処理に利用可能なスレッドがプールに存在せず、プールに空きがある場合、BEA Tuxedo ソフトウェアは新しいスレッドを作成してその要求を処理します。要求が到着したときに利用可能なスレッドがプールに存在せず、新しいスレッドを作成できない場合、その要求はスレッドが利用可能になるまでキューに格納されます。
スレッド・プールは、サーバ・スレッドのために消費されるシステム・リソースの量を制限したい場合に適しています。スレッド・プールを使用すると、同時要求の数がプール内のスレッドの数を上回るまでクライアント要求が同時に実行されます。
BEA Tuxedo スレッド・プールには、次の特性と振る舞いがあります。
リエントラント・サーバント
BEA Tuxedo ソフトウェアは、オブジェクトが自身のオペレーションを再帰的に呼び出すための機能を提供します。この機能を使用するときには、オブジェクトをインプリメントする方法に十分な注意を払う必要があります。アプリケーション・コードは、共有される状態データへのアクセスの制御に必要なオペレーティング・システム同時実行メカニズムを採用する必要があるからです。Process または Distribution Adapter デザイン・パターンをインプリメントするオブジェクトを使用するケースなど、オブジェクトの共有状態がほとんどまたはまったく存在せず、リエントラントをサポートするのが比較的簡単な場合があります。
また、BEA Tuxedo ソフトウェアを使用すると、活性化されたオブジェクトのメソッド呼び出しのリエントラントを有効化または禁止することができます。リエントラントはデフォルトによって無効化されています。活性化されたオブジェクトに対する要求が到着したときに、そのオブジェクトが異なるスレッドで別の要求を実行している場合、次の規則が適用されます。
_is_reentrant
メソッドが TRUE
を返した場合、新しいスレッドがプールから割り当てられ、同じサーバント・インスタンスを使用して適切なメソッドに要求がディスパッチされます。複数のスレッドがオブジェクトと対話する場合にオブジェクトの状態の整合性を保証するのは、サーバント・インプリメンテーション・コードの責任です。_is_reentrant
メソッドが FALSE
を返した場合、サーバントの新しいインスタンスが作成され、メソッドが新しいインスタンスにディスパッチされます。このインスタンスは自動的に削除されません。以後のリエントラント要求はいずれかのインスタンスにディスパッチされます。注記 リエントラント・サーバント・メカニズムは、PER_REQUEST
同時実行手法が指定された状態でサーバが起動した場合にのみ利用可能です。
このメソッドの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。
Current オブジェクト
マルチスレッド CORBA サーバ・アプリケーション環境の最も重要な属性の 1 つは、Current オブジェクトを適切に使用および管理できることです。このため、次のような振る舞いが保証されます。
BEA Tuxedo 製品は、OMG 発行の ORB Portability 仕様によって定義されているマルチスレッド・モデルに準拠しています。この仕様は、OMG CORBA 仕様に組み込まれています。BEA Tuxedo 製品では、CORBA::Current
から継承されたインターフェイスのオペレーションは、Current オブジェクトが取得されたスレッドに関連付けられている状態ではなく、オペレーションが呼び出されるスレッドに関連付けられている状態にアクセスできます。この振る舞いの理由は次の 2 つです。
マルチスレッド環境で使用する場合、次のオブジェクトの振る舞いは ORB Portability 仕様に合致します。
CosTransactions::Current
SecurityLevel1::Current
SecurityLevel2::Current
PortableServer::Current
たとえば、アプリケーションがあるスレッドから別のスレッドにトランザクションを受け渡す場合、そのアプリケーションは CosTransactions::Current
オブジェクトを使用してはなりません。代わりに、アプリケーションはほかのスレッドに CosTransactions::Control
オブジェクトを受け渡します。CosTransctions::Current
オブジェクトを受け渡すと、受信側のスレッドはそのスレッドに関連付けられているトランザクション状態だけにアクセスできます。
マルチスレッド CORBA サーバをサポートするためのメカニズム
この節では、BEA Tuxedo CORBA に用意されているマルチスレッド・サーバ・アプリケーションをサポートする以下のツール、API、および管理機能の概要について説明します。
コンテキスト・サービス
オブジェクト・インプリメンテーションに独自のスレッドを作成して管理することを選択できます。ほかのスレッドは、BEA Tuxedo CORBA ソフトウェアによって自動的に管理されます。BEA Tuxedo CORBA ソフトウェアは、作成および管理する各スレッドのコンテキスト情報を内部に保持します。この必須コンテキスト情報は、CORBA 要求の処理中に使用されます。BEA Tuxedo CORBA は、アプリケーションがいつ独自のスレッドを作成して削除するかに関する知識を持ちません。このため、プログラマはコンテキスト・サービス・メカニズムを使用して、BEA Tuxedo サービスの呼び出し前に独自のスレッドを適切に初期化し、スレッドの削除時に不要になったコンテキスト・リソースを解放できます。
次の ORB メソッド・セットは、スレッド管理の要件を満たします。これらのメソッドを、まとめてコンテキスト・サービスと呼びます。
ORB::get_ctx()
オブジェクトがスレッドを作成するときに、オブジェクトは ORB のこのオペレーションを呼び出して、オブジェクトがスレッドに受け渡すことができるシステム・コンテキスト情報を取得します。このオペレーションは、既にコンテキストを持っているスレッドから呼び出される必要があります。たとえば、メソッドがディスパッチされたスレッドはコンテキストを持っています。このオペレーションの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「ORB::get_ctx()
」を参照してください。
ORB::set_ctx()
オブジェクトがスレッドを作成すると、そのスレッドは通常 get_ctx
メソッドを呼び出したスレッドからコンテキスト情報を取得します。作成されたスレッドは、ORB::set_ctx
を呼び出してそのスレッドが動作する必要があるシステム・コンテキストを設定するときに、そのコンテキストを使用します。このオペレーションの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「ORB::set_ctx()
」を参照してください。
ORB::clear_ctx()
作成されたスレッドは、自己の仕事を完了するとこのメソッドを呼び出して自身とシステム・コンテキストとの関連付けを解除します。このオペレーションの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「ORB::clear_ctx()
」を参照してください。
ORB::inform_thread_exit()
スレッドは、自己の仕事が完了するとこのメソッドを呼び出して、BEA Tuxedo システムにアプリケーション管理スレッドに関連付けられているリソースを解放できることを通知します。このオペレーションの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「ORB::inform_thread_exit()
」を参照してください。
TP フレームワークのクラスとメソッド
BEA Tuxedo TP フレームワークの次のクラスとメソッドは、マルチスレッド・サーバ・アプリケーションをサポートします。
ServerBase
クラスServerBase
クラスのデフォルト・インプリメンテーションを上書きするために、アプリケーション開発者は ServerBase
から継承されたクラスを作成できます。既にサポートされている ServerBase
メソッドのほかにも、次のメソッドがマルチスレッド・サーバ・アプリケーションをサポートします。
create_servant_with_id()
thread_initialize()
thread_release()
これらのメソッドを使用すると、アプリケーションのマルチスレッド特性を細かく制御できます。これらのメソッドの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「ServerBase
インターフェイス」を参照してください。
Tobj_ServantBase
クラスこのクラスは、マルチスレッド・サーバ・アプリケーションをサポートする次のメソッドを提供します。
Tobj_ServantBase::_is_reentrant()
Tobj_ServantBase::_add_ref()
Tobj_ServantBase::_remove_ref()
これらのメソッドの詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「Tobj_ServantBase
インターフェイス」を参照してください。
build コマンドの機能
buildobjserver
コマンドと buildobjclient
コマンドには、次のスレッド管理機能が組み込まれています。
buildobjserver
コマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、サーバ・アプリケーションは BEA Tuxedo ソフトウェアのマルチスレッド・サポートとの互換性を保持します。buildobjserver
コマンドには、マルチスレッド・サーバ・アプリケーションまたはシングル・スレッド・サーバ・アプリケーションをビルドするためのコマンド行オプションが組み込まれています。
buildobjclient
コマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、クライアント・アプリケーションは BEA Tuxedo ソフトウェアのマルチスレッド・サポートとの互換性を保持します。管理用ツール
BEA Tuxedo システムは、アプリケーションを開発および実行するためのコンフィギュレーション・ファイルを使用します。通常、アプリケーション開発者がこれらのファイルを作成し、BEA Tuxedo システム管理者が必要に応じてその内容を修正し、アプリケーションとシステムの要件を満たします。
スレッドのサポートに関連する制御パラメータでは、次のことを指定します。
UBBCONFIG
ファイルのスレッド・パラメータの詳細については、「UBBCONFIG ファイルの例」を参照してください。
マルチスレッド・システムでのシングル・スレッド・サーバ・アプリケーションの実行
BEA Tuxedo CORBA のスレッド・サポートのデフォルトの振る舞いは、シングル・スレッド・サーバ・サポート環境をエミュレートすることです。マルチスレッド環境でシングル・スレッド CORBA アプリケーションを実行する場合は、サーバ・アプリケーション・コードとコンフィギュレーション・ファイルを変更する必要がありません。ただし、既存のシングル・スレッド・アプリケーションを実行する前に、buildobjserver
コマンドと buildobjclient
コマンドを使用してそのアプリケーションを再ビルドする必要があります。サーバ・アプリケーションのマルチスレッドを有効化しなかった場合、そのアプリケーションはシングル・スレッド・サーバとして動作します。
マルチスレッド CORBA サーバ・アプリケーションの開発とビルド
ここでは、次の内容について説明します。
buildobjserver コマンドの使い方
buildobjserver
コマンドは、次の機能を通じて CORBA サーバ・アプリケーションをサポートします。
プラットフォーム固有のスレッド・ライブラリ
buildobjserver
コマンドによって生成されるサーバ・アプリケーションは、適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、適切なプラットフォーム固有のスレッド・サポート・ライブラリを使用してリンクされます。これにより、BEA Tuxedo ソフトウェアが提供する共有ライブラリとの互換性が保証されます。
マルチスレッド・サポートの指定
マルチスレッドをサポートする CORBA サーバ・アプリケーションを作成する場合、アプリケーションをビルドするときに buildobjserver
コマンドで -t
オプションを指定する必要があります。実行時に、BEA Tuxedo システムは、実行可能プログラムと、CORBA サーバ・アプリケーションのコンフィギュレーション・ファイル UBBCONFIG
で選択されたスレッド・モデルとの互換性を検証します。UBBCONFIG
ファイルでスレッド・モデルを設定する方法については、「UBBCONFIG ファイルの例」を参照してください。
注記 CORBA サーバ・アプリケーションのビルド時に -t
を指定する場合、UBBCONFIG
ファイルの MAXDISPATCHTHREADS
パラメータを 1 より大きい値に設定する必要があります。それ以外の値を設定すると、CORBA サーバ・アプリケーションはシングル・スレッド・サーバとして動作することになります。
注記 マルチスレッド共同クライアント/サーバ・インプリメンテーションはサポートされていません。
コンフィギュレーション・ファイルに互換性のないスレッド・モデルを指定してシングル・スレッドの実行可能プログラムを起動しようとすると、次のイベントが発生します。
代替サーバ・クラスの指定
ServerBase
クラスから継承された独自の Server
クラスを実装する場合、buildobjserver
コマンドで -b
オプションを使用してその代替 Server
クラスを指定する必要があります。buildobjserver
コマンドは、次の構文で -b
オプションをサポートしています。
buildobjserver [-v] [-o
outfile
] [-f {firstfiles
|@def-file
}]
[-l {lastfiles
|@def-file
}] [-rrmname
] [-bbootserverclass
] [-t]
上の構文中、bootserverclass
の値は、CORBA サーバ・アプリケーションの起動時に使用される C++ クラスを指定します。-b
オプションを指定しない場合、BEA Tuxedo システムは Server
. という名前でクラスのインスタンスを作成します。
-b
オプションを指定する場合、Tuxedo システムは代替サーバ・クラスのメイン関数を作成し、プロジェクトは -b
オプションで指定した bootserverclass
の名前を持つヘッダ・ファイルを提供する必要があります。ヘッダ・ファイルには、代替 C++ クラスの定義が含まれます。代替 Server
クラスは、ServerBase
クラスから継承されなければなりません。
たとえば、コマンド行で -b AslanServer
と指定した場合、アプリケーション・プロジェクトは AslanServer.h
ファイルを提供する必要があります。AslanServer.h
ファイルは、bootserverclass
.h
ファイルの例です。bootserverclass
ファイルは、このコード例と同じようなロジックを提供します。
リスト 4-1 bootserverclass.h ファイルの例
// ファイル名: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
コマンドを使用してクライアント・アプリケーションの実行可能プログラムを作成する場合、アプリケーションは適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、使用するオペレーティング・システム用の適切なスレッド・サポート・ライブラリを使用してリンクされます。これにより、BEA Tuxedo ソフトウェアが提供する共有ライブラリとクライアントの互換性が保証されます。
非リエントラント・サーバントの作成
BEA Tuxedo CORBA 環境で CORBA サーバ・アプリケーションを実行するには、buildobjserver
コマンドでそのアプリケーションをビルドしておく必要があります。
buildobjserver
-t
オプションを使用すると、BEA Tuxedo システムに CORBA サーバ・アプリケーションがスレッド・セーフであることを通知できます。-t
オプションは、アプリケーションが共有コンテキスト・データ、およびスレッド・セーフではないほかのプログラミング構造を使用しないことを示します。スレッド・セーフではないシングル・スレッド・アプリケーションをマルチスレッド環境で実行する場合、データが破損するおそれがあります。
アプリケーションのコンフィギュレーション・ファイルを更新してマルチスレッド・サポートを有効化したにもかかわらず、サーバ・インプリメンテーションがリエントラントをサポートできることをアプリケーション・コードに指定していない場合、次のことに注意してください。
activate_object
メソッドまたは deactivate_object
メソッドが当初呼び出された要求と同じスレッドで実行されるとは仮定しないでください。注記 プロセスを終了するための SIGKILL
シグナルがサポートされています。シングル・スレッドまたはマルチスレッド・アプリケーションに対する SIGIO
の使用は、BEA Tuxedo CORBA ではサポートされていません。
リエントラント・サーバントの作成
マルチスレッド・リエントラント・サーバントは、次の手順で作成します。
buildobjserver
コマンドと -t
オプションを使用して CORBA サーバ・アプリケーションをビルドし、そのアプリケーションの UBBCONFIG
サーバ・コンフィギュレーション・ファイルを修正します。TobjServantBase::_is_reentrant
メソッドを使用してリエントラントを有効化することによって、CORBA サーバ・アプリケーション・コードを更新します。UBBCONFIG
ファイルに CONCURR_STRATEGY = PER_REQUEST
指定することによって、要求ごとのスレッド・モデルを使用してサーバを起動します。マルチスレッド・リエントラント・サーバントを作成する場合、そのオブジェクトのインプリメンテーション・コードはそのオブジェクトの状態を保護して、複数のスレッドがそのオブジェクトと対話している間その整合性を保証する必要があります。
クライアント・アプリケーションに関する考慮事項
次に、BEA Tuxedo 環境で実行される CORBA クライアント・アプリケーションに関する考慮事項を挙げます。
マルチスレッド simpapp サンプル・アプリケーションのビルドと実行
ここでは、次の内容について説明します。
simpapp マルチスレッド・サンプルについて
BEA Tuxedo ソフトウェアには、クライアント・プログラムと CORBA サーバ・プログラムで構成されるマルチスレッド CORBA サンプル・アプリケーションが用意されています。サーバは、クライアントからアルファベットの文字列を受信し、大文字と小文字の文字列を返します。simpapp_mt のマルチスレッド機能は、並列処理を提供します。この並列処理により、単一のサーバ・プロセスは、複数のオブジェクトまたは単一のオブジェクトに対する複数のクライアントの同時要求を処理できます。
注記 simpapp_mt サンプルのクライアント・アプリケーションは、マルチスレッド・クライアント・アプリケーションではありません。
サンプル・アプリケーションの機能
マルチスレッド・サーバの目的は、1 つまたは複数のクライアントからの要求を並列に処理することです。simpapp_mt サンプル・アプリケーションは、buildobjserver -t
コマンド行オプションを使用し、UBBCONFIG
ファイルを使用して同時実行手法を指定することによってマルチスレッド機能を例示する CORBA アプリケーションです。
simpapp_mt サンプルは、最初に SimplePerObject
というサーバ・プロセスを作成し、次に SimplePerRequest
というサーバ・プロセスを作成します。クライアントは、最初に SimplePerRequest
サーバと通信し、次に SimplePerObject
サーバと通信します。
SimplePerRequest
の要求ごとのスレッド・サーバ・インプリメンテーションは、スレッド初期化メソッドをインプリメントするユーザ定義のサーバ・クラスの使い方を例示します。SimplePerRequest
サーバ・プロセスは、クライアントからの各要求を独立した制御スレッドで処理します。新しい要求が到着するたびに、その要求を処理するためにスレッド・プールからスレッドが割り当てられます。要求が処理され、応答が送信されると、そのスレッドはプールに戻されます。このモデルは、複数のクライアントからの長期の要求を処理するサーバに適しています。
simpapp_mt サンプル・アプリケーションは、次のメソッドを持つ CORBA オブジェクトのインプリメンテーションを提供します。
to_upper
メソッドは、クライアント・アプリケーションからの文字列を受け付けて大文字に変換します。to_lower
メソッドは、クライアント・アプリケーションからの文字列を受け付けて小文字に変換します。forward_upper
メソッドは、サーバの別のインスタンスへのアプリケーション管理スレッドを作成し、クライアントから受信した要求をその新しいサーバ・インスタンスに転送して文字列を大文字に変換します。forward_lower
メソッドは、Simple
オブジェクトの別のインスタンスを作成し、クライアントから受信した要求をその新しいインスタンスに転送して文字列を小文字に変換します。図 4-2 に、オブジェクトごとのスレッド・モデルと要求ごとのスレッド・モデルの両方を使用する simpapp_mt サンプル・アプリケーションのオペレーションを示します。
図4-2 simpapp_mt サンプル・アプリケーション
simpapp マルチスレッド・サンプル・アプリケーションの OMG IDL コード
この章で説明する simpapp マルチスレッド・サンプル・アプリケーションは、次の表に示す CORBA インターフェイスをインプリメントします。
リスト 4-2 に、simpapp_mt サンプル・アプリケーションの CORBA インターフェイスを定義した simple.idl
ファイルの内容を示します。
リスト 4-2 simpapp_mt サンプル・アプリケーション用の OMG IDL コード
#pragma prefix
"beasys.com"
interface Simple
{
//文字列を小文字に変換 (新しい文字列を返す)
string to_lower(in string val);
//文字列を大文字に変換 (置換)
string to_upper(in string val);
//ほかのサーバを使用して文字列を小文字に変換
string forward_lower(in string val);
//ほかのサーバを使用して文字列を大文字に変換
string forward_upper(in string val);
};
interface SimplePerRequestFactory
{
Simple find_simple();
};
interface SimplePerObjectFactory
{
Simple find_simple();
};
サンプル・アプリケーションのビルドと実行の方法
この節では、simpapp_mt サンプル・アプリケーションをビルドおよび実行するプロセスをステップごとに説明します。次のフローチャートに、このプロセスの要約を示します。以降の節では、これらのタスクを実行する方法について説明します。
図4-3 simpapp_mt のビルドおよび実行プロセス
TUXDIR 環境変数の設定
simpapp_mt サンプル・アプリケーションをビルドおよび実行する前に、TUXDIR
環境変数がシステムで設定されていることを確認してください。通常、この環境変数はインストール・プロセス中に設定されます。この環境変数に適切なディレクトリが定義されていることを確認する必要があります。
TUXDIR
環境変数は、BEA Tuxedo ソフトウェアがインストールされているディレクトリ・パスに設定されている必要があります。次に例を示します。
Windows
TUXDIR=D:
\TUXDIR
UNIX
TUXDIR=/usr/local/TUXDIR
TUXDIR 環境変数の検証
アプリケーションを実行する前に、次の手順を実行してこの環境変数に正確な情報が定義されているかどうかを確認してください。
Windows
echo
コマンドを実行して TUXDIR
の設定を表示します。
prompt> echo %TUXDIR%
UNIX
ksh
コマンドを実行して、Korn シェルを起動します。
printenv
コマンドを実行して TUXDIR
の設定を表示します。
ksh prompt> printenv TUXDIR
環境変数の設定の変更
環境変数の設定を変更するには、次の手順を実行します。
Windows
set
コマンドを実行して、TUXDIR
の新しい値を設定します。
prompt> set TUXDIR=
directorypath
UNIX
ksh
コマンドを実行して、Korn シェルを起動
します。
ksh
プロンプトに対して、export
コマンドを入力して TUXDIR
環境変数の値
を設定します。
ksh prompt> export TUXDIR=
directorypath
サンプル・アプリケーションの作業ディレクトリの作成
注記 simpapp マルチスレッド・サンプルを実行するときにどのようなファイルが新しく作成されるかを確認できるよう、作業ディレクトリを使用することをお勧めします。runme
コマンドを実行したら、インストール・ディレクトリ内のファイル・セットと作業ディレクトリ内のファイル・セットを比較してください。
simpapp マルチスレッド・サンプル・アプリケーションの必須ファイルは、次のディレクトリに格納されています。
Windows
%TUXDIR%
\samples
\corba
\simpapp_mt
UNIX
$TUXDIR/samples/corba/simpapp_mt
simpapp マルチスレッド・ファイルをすべて格納する作業ディレクトリを作成します。
Windows
Windows エクスプローラを使用して simpapp_mt ディレクトリをコピーするか、次のようにコマンド・プロンプトを使用します。
>
mkdir
work_directory
simpapp_mt
ファイルを作業ディレクトリにコピーします。
>
copy %TUXDIR%
\samples
\corba
\simpapp_mt
\*
work_directory
cd
work_directory
prompt> dir
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
UNIX
ユーザ・インターフェイス・ツールを使用して simpapp_mt ディレクトリのコピーを作成するか、次のようにコマンド・プロンプトを使用します。
simpapp_mt
ファイルのコピー先となる作業ディレクトリを作成します。
>
mkdir
work_directory
simpapp_mt
ファイルを作業ディレクトリにコピーします。
>
cp $TUXDIR/samples/corba/simpapp_mt/*
work_directory
cd
work_directory
$ ls
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
表 4-1 に、アプリケーションをビルドおよび実行するための simpapp_mt ファイルとその説明を示します。
すべてのファイルのパーミッションのチェック
simpapp_mt サンプル・アプリケーションをビルドおよび実行するには、作業ディレクトリにコピーしたすべてのファイルに対するユーザ・パーミッションと読み取りパーミッションがなければなりません。パーミッションをチェックし、必要な場合はそれらを変更します。
注記 make
ユーティリティがパスに存在することを確認してください。
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
コマンドでは、以下の手順が自動的に実行されます。
TUXDIR
環境変数をチェックします。
bin
ディレクトリが PATH
にあることを確認します。
setenv.ksh
ファイル (UNIX) または setenv.bat
ファイル (Windows) を作
成し、このサンプルをステップ・バイ・ステップ・モードでビルドおよび実
行できるようにします。
ubb
コンフィギュレーション・ファイルを作成します。
simpapp_mt サンプル・アプリケーションは、runme
コマンドの実行中に次のメッセージを出力します。
Testing simpapp_mt
cleaned up
prepared
built
loaded ubb
booted
ran
shutdown
saved results
PASSED
simpapp_mt サンプル・アプリケーションのすべての実行時出力は、作業ディレクトリ内の results ディレクトリに格納されます。実行時に作成された出力を見るには、次のファイルを参照します。
log
− コンパイル、サーバ起動、またはサーバ・シャットダウンのエラーoutput
− クライアント・アプリケーションの出力と例外ULOG.
date
− サーバ・アプリケーションのエラーと例外表 4-2 と表 4-3 に、runme
コマンドの実行によって作成されるファイルとその説明を示します。
サンプル・アプリケーションのステップ・バイ・ステップ実行
この節では、simpapp_mt サンプル・アプリケーションをステップ・バイ・ステップ・モードで実行する方法について説明します。simpapp_mt をステップ・バイ・ステップ・モードで実行するには、あらかじめ runme
コマンドを実行しておく必要があります。
次の手順に従って、simpapp_mt アプリケーションを実行します。
Windows
> ..\results\setenv
UNIX
> ../results/setenv.ksh
tmboot -y
を実行してアプリケーションを起動します。次のような情報が表
示されます。
>tmboot -y
Booting all admin and server processes in /work_directory
/results/tuxconfig
Booting admin processes ...
exec BBL -A : process id=212 ... Started.
Booting server processes ...
exec TMSYSEVT -A : process id=289 ... Started.
exec TMFFNAME -A -- -N -M : process id=297 ... Started.
exec TMFFNAME -A -- -N : process id=233 ... Started.
exec TMFFNAME -A -- -F : process id=265 ... Started.
exec simple_per_object_server -A : process id=116 ... Started.
exec simple_per_request_server -A : process id=127 ... Started.
exec ISL -A -- -n //MrBeaver:2468 : process id=270 ... Started.
7 processes started.
>
表 4-4 に、tmboot
によって起動するサーバ・プロセスを示します。
プロセス |
説明 |
---|---|
|
システム EventBroker。 |
|
|
|
オブジェクトごとのスレッド・サーバとして起動します。 |
|
リエントラントな要求ごとのスレッド・サーバとして起動します。 |
|
IIOP リスナ・プロセス。 |
Windows
> .\simple_client
UNIX
> ./simple_client
クライアント・アプリケーションを実行すると、次のようなメッセージが表示されます。
リスト 4-3 simpapp_mt クライアントの実行時に表示されるメッセージ
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 サンプル・アプリケーションをシャットダウンして、不要なファイルを作業ディレクトリからすべて削除する必要があります。
tmshutdown -y
コマンドを実行します。
次のような情報が表示されます。
>tmshutdown -y
Shutting down all admin and server processes in /work_directory
/
results/tuxconfig
Shutting down server processes ...
Server Id = 5 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = APP_GRP2 Machine = SITE1: shutdown succeeded.
Server Id = 4 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 3 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 1 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Shutting down admin processes ...
Server Id = 0 Group Id = SITE1 Machine = SITE1: shutdown succeeded.
7 processes stopped.
Windows
> ..\results\setenv
> make -f clean
UNIX
> ../results/setenv.ksh
> make -f makefile.mk clean
マルチスレッド CORBA サーバ・アプリケーションの管理
ここでは、次の内容について説明します。
スレッド・プール・サイズの指定
スレッド・プールの最小サイズと最大サイズを指定するための MAXDISPATCHTHREADS
パラメータと MINDISPATCHTHREADS
パラメータは、UBBCONFIG
ファイルの SERVERS
セクションに存在します。これらのパラメータの指定例については、リスト 4-4 を参照してください。マルチスレッド CORBA アプリケーションは、これらの値を使用してスレッド・プールを作成および管理します。
MAXDISPATCHTHREADS
MAXDISPATCHTHREADS
パラメータは、各サーバ・プロセスで生成される、同時に実行できるディスパッチ・スレッドの最大数です。このパラメータを指定する際には、以下のことに留意してください。
MAXDISPATCHTHREADS
の値によって、受信する要求を格納するために拡大できる最大サイズが決定されます。MAXDISPATCHTHREADS
のデフォルト値は 1 です。1 より大きい値を指定した場合、特別なディスパッチ・スレッドが作成および使用されます。このディスパッチ・スレッドは、スレッド・プールの最大サイズを決定するスレッド数には含まれません。注記 MAXDISPATCHTHREADS
に 1 より大きい値を指定し、CONCURR_STRATEGY
スレッド・モデル・パラメータの値を指定しなかった場合、アプリケーションのスレッド・モデルはデフォルトによってオブジェクトごとのスレッドに設定されます。CONCURR_STRATEGY
スレッド・モデル・パラメータについては、「スレッド・モデルの指定」を参照してください。
MAXDISPATCHTHREADS
パラメータの値を 1 に設定した場合、CORBA サーバ・アプリケーションをシングル・スレッド・サーバとして構成する必要があります。注記 buildobjserver
-t
を指定してマルチスレッド CORBA サーバ・アプリケーションをビルドした場合、そのサーバはマルチスレッド・モードで動作できます。マルチスレッド CORBA サーバ・アプリケーションとして実行するには、UBBCONFIG
ファイルの MAXDISPATCHTHREADS
パラメータを 1 より大きい値に設定する必要があります。それ以外の値を設定した場合、サーバ・アプリケーションはシングル・スレッド・モードで動作します。
MAXDISPATCHTHREADS
パラメータに指定する値は、MINDISPATCHTHREADS
パラメータの値より小さくしてはなりません。 MAXDISPATCHTHREADS
は、この制限からアプリケーションで必要なアプリケーション管理スレッドの数を差し引いた数より小さくする必要があります。MAXDISPATCHTHREADS
パラメータの値は、ほかのパラメータに影響を与えます。たとえば、MAXACCESSORS
パラメータは BEA Tuxedo システムへの同時アクセスの数を制御し、各スレッドは 1 つのアクセサとしてカウントされます。マルチスレッド・サーバ・アプリケーションでは、各サーバが実行するシステム管理スレッドの数を考慮する必要があります。システム管理スレッドとは、アプリケーションによって開始および管理されるスレッドに対して、BEA Tuxedo ソフトウェアによって開始および管理されるスレッドです。内部的には、BEA Tuxedo は利用可能なシステム管理スレッドのプールを管理します。クライアント要求を受信すると、スレッド・プールから利用できるシステム管理スレッドがその要求を実行するようスケジューリングされます。要求が完了すると、システム管理スレッドは利用可能なスレッド・プールに戻されます。
たとえば、システムに 4 つのマルチスレッド・サーバが存在し、各サーバが 50 のシステム管理スレッドを実行するよう構成されている場合、これらのサーバのアクセサ要件は、次の計算によって得られるアクセサの合計です。
50 + 50 + 50 + 50 = 200 accessors
MINDISPATCHTHREADS
MINDISPATCHTHREADS
パラメータは、サーバが最初に起動したときに開始されるサーバ・ディスパッチ・スレッドの数を指定するために使用します。このパラメータを指定する際には、次のことに留意してください。
MINDISPATCHTHREADS
の値によって、スレッド・プール内のスレッドの初期割り当てが決定されます。MAXDISPATCHTHREADS
が 1 より大きい場合に作成された別個のディスパッチ・スレッドは、MINDISPATCHTHREADS
制限の一部としてカウントされません。MINDISPATCHTHREADS
に指定する値は、MAXDISPATCHTHREADS
に指定する値より大きくしてはなりません。MINDISPATCHTHREADS
のデフォルト値は 0 です。 スレッド・モデルの指定
スレッド・モデルを指定するには、UBBCONFIG
ファイルの SERVERS
セクションに定義されている CONCURR_STRATEGY
パラメータを設定します。
CONCURR_STRATEGY
パラメータを使用して、マルチスレッド CORBA サーバ・アプリケーションが使用するスレッド・モデルを指定します。CONCURR_STRATEGY
パラメータは、次のいずれかの値を受け付けます。
CONCURR_STRATEGY = PER_REQUEST
CONCURR_STRATEGY = PER_OBJECT
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
MAXOBJECTSnumber
特定のマシンのシステム全体にわたる設定を上書きするには、次のように指定します。
*MACHINES
MAXOBJECTS =number
number
の値は、オペレーティング・システムのリソースによってのみ制限されます。
UBBCONFIG ファイルの例
リスト 4-4 に、BEA Tuxedo Threads サンプル・アプリケーション用の UBBCONFIG
ファイルを示します。スレッドに関連するパラメータは、太字で示してあります。
注記 MAXOBJECTS
パラメータの値は、マルチスレッド・サーバのオペレーションに影響を与えます。ただし、このパラメータはマルチスレッド・サーバに固有のものではありません。この値は、シングル・スレッド・サーバのオペレーションにも影響を与えます。MAXOBJECTS
の値を大きくすると、サーバで消費されるシステム・リソースが増加します。
リスト 4-4 Threads サンプル・アプリケーションの UBBCONFIG ファイル
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MAXOBJECTS 100
MASTER SITE1
MAXACCESSERS = 200
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
*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_OBJECTRESTART = N
simple_per_request_server
SRVGRP = APP_GRP2
SRVID = 2
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_REQUESTRESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //sunbstar:2468 -d /dev/tcp"
*SERVICES
![]() |
![]() |
![]() |
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|