![]() ![]() ![]() ![]() ![]() ![]() ![]() |
複数の独立したスレッドを使用するようにアプリケーションを設計すると、アプリケーション内に同時実行性がもたらされ、総合的なスループットを改善できます。複数のスレッドを使用すると、各スレッドが複数の独立したタスクを並列に処理する効率的なアプリケーションを構築できます。マルチスレッドは、以下の場合に特に役立ちます。
歴史的に見て、業界レベルのマルチスレッド・アプリケーションの設計と実装は複雑なものでした。Oracle Tuxedoが提供するサポートは、スレッドをCORBAサーバー環境の内部で管理することによって、こうした複雑さを単純化します。
Oracle Tuxedoソフトウェアは、次のマルチスレッド特性を備えたサーバー・アプリケーションをサポートします(図4-1を参照)。
通常、Oracle Tuxedoソフトウェアは、サーバー・アプリケーションのかわりにスレッドを作成および管理します。マルチスレッド・サーバー・アプリケーションをビルドする場合、TPフレームワークの使い方、サーバントの実装方法、および独自のスレッドを作成するオブジェクトの設計方法が変わります。
Oracle Tuxedoソフトウェアを使用すると、リクエストごとのスレッド・モデルとオブジェクトごとのスレッド・モデルのいずれかを実装できます。各モデルについては、「スレッド・モデル」で説明します。
コンピュータ操作の中には、完了するのに長い時間を要するものがあります。マルチスレッド設計では、オペレーションのリクエストと完了の間の待機時間を飛躍的に短縮できます。これは、データベースにアクセスするとき、リモート・オブジェクトの操作を呼び出すとき、マルチ・プロセッサ・マシン上のCPUバウンドなど、操作が大量のI/O操作を実行する環境に当てはまります。サーバー・プロセスでマルチスレッドを実装すると、サーバーが一定時間に処理できるリクエストの数が増加します。
マルチスレッド・サーバー・アプリケーションの主要な要件は、複数のクライアント・リクエストを同時に処理することです。この種のサーバーを開発する目的は次のとおりです。
これは、既存のプログラミング抽象化を使用して複数のサーバー・タスクを独立して実行することにより達成されます。
これは、マルチプロセッサ・ハードウェア・プラットフォームの並列処理のメリットを活用し、計算処理と通信をオーバーラップさせることによって達成されます。
独立したスレッドを異なるサーバー・タスクに関連付けることによって、クライアントは長時間にわたって互いをブロックすることがなくなります。
独立したスレッドを使用して異なるリモート・プロシージャ・コール(RPC)と会話とのやり取りを実現すると、一部のアプリケーションのコーディングが簡単になります。
レガシー・アプリケーションまたはレガシー・データベースをCORBAサーバー内でラップすると、実装は一度に複数のレガシー・アプリケーションとやり取りできます。
1つのサーバーで複数のサービス・スレッドをディスパッチできるので、アプリケーションで必要なサーバーの数を減らすことができます。
ただし、マルチスレッド設計にはコストがかかります。通常、マルチスレッド・サーバー・アプリケーションでは、シングル・スレッド・サーバーより複雑な同期手法が必要になります。アプリケーション開発者は、スレッド・セーフなコードを記述する必要があります。また、スレッドを作成してリクエストを処理するオーバーヘッドが並列処理のメリットより大きくなる場合もあります。特定の同時実行性モデルの実際の性能は、次の要因によって決まります。
スレッド・ライブラリは同時実行性モデルを作成するためのメカニズムを提供しますが、そのメカニズムを適切に使用する方法を最終的に理解するのは開発者です。デザイン・パターンを学習することによって、アプリケーション開発者は微妙な差異を理解し、様々な状態に応じた設計を選択できるようになります。
サーバー内の同時実行性を設計するために使用できるモデルはいくつか存在します。以降の項では、リクエストごとのスレッド・モデル、オブジェクトごとのスレッド・モデル、スレッド・プール、および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ソフトウェアを使用すると、アクティブ化されたオブジェクトのメソッド呼出しのリエントラントを有効化または禁止することができます。リエントラントはデフォルトによって無効化されています。アクティブ化されたオブジェクトに対するリクエストが到着したときに、そのオブジェクトが異なるスレッドで別のリクエストを実行している場合、次の規則が適用されます。
注意: | リエントラント・サーバント・メカニズムは、PER_REQUEST 同時実行性手法が指定された状態でサーバーが起動した場合にのみ利用可能です。 |
このメソッドの使い方については、『CORBAプログラミング・リファレンス』を参照してください。
マルチスレッドCORBAサーバー・アプリケーション環境の最も重要な属性の1つは、Currentオブジェクトを適切に使用および管理できることです。このため、次のような振る舞いが保証されます。
Oracle Tuxedo製品は、OMG発行のORB Portability仕様によって定義されているマルチスレッド・モデルに準拠しています。この仕様は、OMG CORBA仕様に組み込まれています。Oracle Tuxedo製品では、CORBA::Current
から継承されたインタフェースのオペレーションは、Currentオブジェクトが取得されたスレッドに関連付けられている状態ではなく、オペレーションが呼び出されるスレッドに関連付けられている状態にアクセスできます。この振る舞いの理由は次の2つです。
マルチスレッド環境で使用する場合、次のオブジェクトの振る舞いはORB Portability仕様に合致します。
たとえば、アプリケーションがあるスレッドから別のスレッドにトランザクションを受け渡す場合、そのアプリケーションはCosTransactions::Current
オブジェクトを使用してはなりません。かわりに、アプリケーションはほかのスレッドにCosTransactions::Control
オブジェクトを受け渡します。CosTransctions::Current
オブジェクトを受け渡すと、受信側のスレッドはそのスレッドに関連付けられているトランザクション状態だけにアクセスできます。
この項では、Oracle Tuxedo CORBAに用意されているマルチスレッド・サーバー・アプリケーションをサポートする以下のツール、API、および管理機能の概要について説明します。
オブジェクト実装に独自のスレッドを作成して管理することを選択できます。ほかのスレッドは、Oracle Tuxedo CORBAソフトウェアによって自動的に管理されます。Oracle Tuxedo CORBAソフトウェアは、作成および管理する各スレッドのコンテキスト情報を内部に保持します。この必須コンテキスト情報は、CORBAリクエストの処理中に使用されます。Oracle Tuxedo CORBAは、アプリケーションがいつ独自のスレッドを作成して削除するかに関する知識を持ちません。このため、プログラマはコンテキスト・サービス・メカニズムを使用して、Oracle Tuxedoサービスの呼出し前に独自のスレッドを適切に初期化し、スレッドの削除時に不要になったコンテキスト・リソースを解放できます。
次のORBメソッド・セットは、スレッド管理の要件を満たします。これらのメソッドを、まとめてコンテキスト・サービスと呼びます。
ORB::get_ctx()
オブジェクトがスレッドを作成するときに、オブジェクトはORBのこのオペレーションを呼び出して、オブジェクトがスレッドに受け渡すことができるシステム・コンテキスト情報を取得します。このオペレーションは、すでにコンテキストを持っているスレッドから呼び出される必要があります。たとえば、メソッドがディスパッチされたスレッドはコンテキストを持っています。このオペレーションの使い方については、『CORBAプログラミング・リファレンス』の「ORB::get_ctx()」
を参照してください。
ORB::set_ctx()
オブジェクトがスレッドを作成すると、そのスレッドは通常get_ctx
メソッドを呼び出したスレッドからコンテキスト情報を取得します。作成されたスレッドは、ORB::set_ctx
を呼び出してそのスレッドが動作する必要があるシステム・コンテキストを設定するときに、そのコンテキスト情報を使用します。このオペレーションの使い方については、CORBAプログラミング・リファレンスのORB::set_ctx()
に関する項を参照してください。
ORB::clear_ctx()
作成されたスレッドは、自己の仕事を完了するとこのメソッドを呼び出して自身とシステム・コンテキストとの関連付けを解除します。このオペレーションの使い方については、『CORBAプログラミング・リファレンス』の「ORB::clear_ctx()」
を参照してください。
ORB::inform_thread_exit()
スレッドは、自己の仕事が完了するとこのメソッドを呼び出して、Oracle Tuxedoシステムにアプリケーション管理スレッドに関連付けられているリソースを解放できることを通知します。このオペレーションの使い方については、『CORBAプログラミング・リファレンス』の「ORB::inform_thread_exit()」
を参照してください。
Oracle Tuxedo TPフレームワークの次のクラスとメソッドは、マルチスレッド・サーバー・アプリケーションをサポートします。
ServerBase
クラス ServerBase
クラスのデフォルト実装をオーバーライドするために、アプリケーション開発者はServerBase
から導出したクラスを作成できます。すでにサポートされているServerBase
メソッドの他にも、次のメソッドがマルチスレッド・サーバー・アプリケーションの実装をサポートします。
create_servant_with_id()
thread_initialize()
thread_release()
これらのメソッドを使用すると、アプリケーションのマルチスレッド特性を細かく制御できます。これらのメソッドの使い方については、『CORBAプログラミング・リファレンス』の「ServerBase
インタフェース」を参照してください。
Tobj_ServantBase
クラスこのクラスは、マルチスレッド・サーバー・アプリケーションをサポートする次のメソッドを提供します。
Tobj_ServantBase::_is_reentrant()
Tobj_ServantBase::_add_ref()
Tobj_ServantBase::_remove_ref()
これらのメソッドの詳細は、『CORBAプログラミング・リファレンス』の「Tobj_ServantBase
インタフェース」を参照してください。
buildobjserver
コマンドとbuildobjclient
コマンドには、次のスレッド管理機能が組み込まれています。
buildobjserver
コマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、サーバー・アプリケーションはOracle Tuxedoソフトウェアのマルチスレッド・サポートとの互換性を保持します。 buildobjserver
コマンドには、マルチスレッド・サーバー・アプリケーションまたはシングル・スレッド・サーバー・アプリケーションをビルドするためのコマンドライン・オプションが組み込まれています。
buildobjclient
コマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、クライアント・アプリケーションはOracle Tuxedoソフトウェアのマルチスレッド・サポートとの互換性を保持します。Oracle Tuxedoシステムは、アプリケーションを開発および実行するための構成ファイルを使用します。通常、アプリケーション開発者がこれらのファイルを作成し、Oracle Tuxedoシステム管理者が必要に応じてその内容を修正し、アプリケーションとシステムの要件を満たします。
スレッドのサポートに関連する制御パラメータでは、次のことを指定します。
UBBCONFIG
ファイルのスレッド・パラメータの詳細は、「UBBCONFIGファイルの例」を参照してください。
Oracle Tuxedo CORBAのスレッド・サポートのデフォルトの振る舞いは、シングル・スレッド・サーバー・サポート環境をエミュレートすることです。マルチスレッド環境でシングル・スレッドCORBAアプリケーションを実行する場合は、サーバー・アプリケーション・コードと構成ファイルを変更する必要がありません。ただし、既存のシングル・スレッド・アプリケーションを実行する前に、buildobjserver
コマンドとbuildobjclient
コマンドを使用してそのアプリケーションを再ビルドする必要があります。サーバー・アプリケーションのマルチスレッドを有効化しなかった場合、そのアプリケーションはシングル・スレッド・サーバーとして動作します。
buildobjserver
コマンドは、次の機能を通じてCORBAサーバー・アプリケーションをサポートします。
buildobjserver
コマンドによって生成されるサーバー・アプリケーションは、適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、適切なプラットフォーム固有のスレッド・サポート・ライブラリを使用してリンクされます。これにより、Oracle Tuxedoソフトウェアが提供する共有ライブラリとの互換性が保証されます。
マルチスレッドをサポートするCORBAサーバー・アプリケーションを作成する場合は、アプリケーションをビルドするときにbuildobjserver
コマンドで-t
オプションを指定する必要があります。実行時に、Oracle Tuxedoシステムは、実行可能プログラムと、CORBAサーバー・アプリケーションの構成ファイルUBBCONFIG
で選択されたスレッド・モデルとの互換性を検証します。UBBCONFIG
ファイルでスレッド・モデルを設定する方法は、「UBBCONFIGファイルの例」を参照してください。
注意: | CORBAサーバー・アプリケーションのビルド時に-t を指定する場合、UBBCONFIG ファイルのMAXDISPATCHTHREADS パラメータを1より大きい値に設定する必要があります。それ以外の値を設定すると、CORBAサーバー・アプリケーションはシングル・スレッド・サーバーとして動作することになります。 |
注意: | マルチスレッド共同クライアント/サーバー実装はサポートされていません。 |
構成ファイルに互換性のないスレッド・モデルを指定してシングル・スレッドの実行可能プログラムを起動しようとすると、次のイベントが発生します。
ServerBase
クラスから継承された独自のServer
クラスを実装する場合は、buildobjserver
コマンドで-b
オプションを使用してその代替Server
クラスを指定する必要があります。buildobjserver
コマンドは、次の構文で-b
オプションをサポートしています。
buildobjserver [-v] [-ooutfile
] [-f {firstfiles
|@def-file
}]
[-l {lastfiles
|@def-file
}] [-rrmname
] [-bbootserverclass
] [-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
コマンドを使用してクライアント・アプリケーションの実行可能プログラムを作成する場合、アプリケーションは適切なプラットフォーム固有のコンパイラ設定を使用してコンパイルされ、使用するオペレーティング・システム用の適切なスレッド・サポート・ライブラリを使用してリンクされます。これにより、Oracle Tuxedoソフトウェアが提供する共有ライブラリとクライアントの互換性が保証されます。
Oracle Tuxedo CORBA環境でCORBAサーバー・アプリケーションを実行するには、buildobjserver
コマンドでそのアプリケーションをビルドしておく必要があります。
buildobjserver
-t
オプションを使用すると、Oracle TuxedoシステムにCORBAサーバー・アプリケーションがスレッド・セーフであることを通知できます。-t
オプションは、アプリケーションが共有コンテキスト・データ、およびスレッド・セーフではない他のプログラミング構造を使用しないことを示します。スレッド・セーフではないシングル・スレッド・アプリケーションをマルチスレッド環境で実行すると、データが破損するおそれがあります。
アプリケーションの構成ファイルを更新してマルチスレッド・サポートを有効化したにもかかわらず、サーバー実装がリエントラントをサポートできることをアプリケーション・コードに指定していない場合、次のことに注意してください。
activate_object
メソッドまたはdeactivate_object
メソッドが当初呼び出されたリクエストと同じスレッドで実行されるとは仮定しないこと。注意: | プロセスを終了するためのSIGKILL シグナルがサポートされています。シングル・スレッドまたはマルチスレッド・アプリケーションに対するSIGIO の使用は、Oracle Tuxedo CORBAではサポートされていません。 |
マルチスレッド・リエントラント・サーバントは、次の手順で作成します。
マルチスレッド・リエントラント・サーバントを作成する場合、そのオブジェクトの実装コードはそのオブジェクトの状態を保護して、複数のスレッドがそのオブジェクトと対話している間その整合性を保証する必要があります。
次に、Oracle Tuxedo環境で実行されるCORBAクライアント・アプリケーションに関する考慮事項を挙げます。
Oracle 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サンプル・アプリケーションのオペレーションを示します。
この章で説明する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に、このプロセスの要約を示します。以降の項では、これらのタスクを実行する方法について説明します。
simpapp_mtサンプル・アプリケーションをビルドおよび実行する前に、TUXDIR
環境変数がシステムで設定されていることを確認してください。通常、この環境変数はインストール・プロセス中に設定されます。この環境変数に適切なディレクトリが定義されていることを確認する必要があります。
TUXDIR
環境変数は、Oracle Tuxedoソフトウェアがインストールされているディレクトリ・パスに設定されている必要があります。例:
アプリケーションを実行する前に、次の手順を実行してこの環境変数に正確な情報が定義されているかどうかを確認してください。
set
コマンドを実行して、TUXDIR
の新しい値を設定します。
prompt> set TUXDIR=
directorypath
注意: | simpappマルチスレッド・サンプルを実行するときにどのようなファイルが新しく作成されるかを確認できるよう、作業ディレクトリを使用することをお薦めします。runme コマンドの実行後に、インストール・ディレクトリ内のファイル・セットと作業ディレクトリ内のファイル・セットを比較してください。 |
simpappマルチスレッド・サンプル・アプリケーションの必須ファイルは、次のディレクトリに格納されています。
%TUXDIR%\samples\corba\simpapp_mt
$TUXDIR/samples/corba/simpapp_mt
simpappマルチスレッド・ファイルをすべて格納する作業ディレクトリを作成します。
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
ユーザー・インタフェース・ツールを使用して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 ユーティリティがパスに存在することを確認してください。 |
> attrib -R /S *.*
> /bin/ksh
> chmod u+r work_directory/*.*
この項では、アプリケーションの実行に必要な手順について説明します。次のようにrunme
コマンドを入力します。
> cd work_directory
> ./runme
> /bin/ksh
> cd work_directory
> ./runme.ksh
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ディレクトリに格納されます。実行時に作成された出力を見るには、次のファイルを参照します。
表4-2と表4-3に、runme
コマンドの実行によって作成されるファイルとその説明を示します。
この項では、simpapp_mtサンプル・アプリケーションをステップ・バイ・ステップ・モードで実行する方法について説明します。simpapp_mtをステップ・バイ・ステップ・モードで実行するには、あらかじめrunme
コマンドを実行しておく必要があります。
次の手順に従って、simpapp_mtアプリケーションを実行します。
> ..\results\setenv
> ../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
によって起動するサーバー・プロセスを示します。
クライアント・アプリケーションを実行すると、リスト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サンプル・アプリケーションを停止して、不要なファイルを作業ディレクトリからすべて削除する必要があります。
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.
> ..\results\setenv
> make -f clean
> ../results/setenv.ksh
> make -f makefile.mk clean
スレッド・プールの最小サイズと最大サイズを指定するためのMAXDISPATCHTHREADS
パラメータとMINDISPATCHTHREADS
パラメータは、UBBCONFIG
ファイルのSERVERS
セクションに存在します。これらのパラメータの指定例については、リスト4-4を参照してください。マルチスレッドCORBAアプリケーションは、これらの値を使用してスレッド・プールを作成および管理します。
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
パラメータはOracle Tuxedoシステムへの同時アクセス数を制御し、各スレッドは、1つのアクセサとしてカウントされます。マルチスレッド・サーバーのアプリケーションの場合、各サーバーの実行が構成されているシステム管理のスレッドの数を考慮しておく必要があります。システム管理のスレッドとは、アプリケーションで開始され管理されるスレッドとは対照的に、Oracle Tuxedoソフトウェアで開始され管理されるスレッドです。内部ではOracle Tuxedoが、利用可能なシステム管理のスレッドのプールを管理しています。クライアント・リクエストが受信されると、スレッド・プールから利用可能なシステム管理のスレッドがそのリクエストを実行するようにスケジューリングされます。リクエストが完了すると、システム管理のスレッドは利用可能なスレッドのプールに戻されます。
たとえば、システム内に4つのマルチスレッド・サーバーがあり、各サーバーが50個のシステム管理のスレッドを実行するように構成されている場合、これらのサーバーにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。
サーバーが最初にブートされたときに開始されるサーバー・ディスパッチ・スレッドの数を指定するには、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
を使用します。
特定のマシンのシステム全体にわたる設定をオーバーライドするには、次のように指定します。
number
の値は、オペレーティング・システムのリソースによってのみ制限されます。
リスト4-4に、Oracle Tuxedo Threadsサンプル・アプリケーション用のUBBCONFIG
ファイルを示します。スレッドに関連するパラメータは、太字で示してあります。
注意: | MAXOBJECTS パラメータの値は、マルチスレッド・サーバーのオペレーションに影響を与えます。ただし、このパラメータは、シングル・スレッド・サーバーのオペレーションにも影響を与えるため、マルチスレッド・サーバーに固有のものではありません。MAXOBJECTS の値を大きくすると、サーバーで消費されるシステム・リソースが増加します。 |
*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_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
![]() ![]() ![]() |