bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0
e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > マルチスレッド CORBA サーバ・アプリケーションの作成

Tuxedo CORBA サーバ・アプリケーションの開発方法

 Previous Next Contents Index View as PDF  

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

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

 

概要

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

はじめに

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

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

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

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

BEA Tuxedo ソフトウェアを使用すると、要求ごとのスレッド・モデルか、オブジェクトごとのスレッド・モデルのいずれかをインプリメントできます。各モデルについては、「第 4 章の 6 ページ「スレッド・モデル」」で説明します。

要件、目標、概念

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

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

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

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

スレッド・モデル

サーバ内の並行性を設計するために使用できるモデルはいくつか存在します。以降の節では、要求ごとのスレッド・モデル、オブジェクトごとのスレッド・モデル、スレッド・プール、および 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 ソフトウェアを使用すると、活性化されたオブジェクトのメソッド呼び出しのリエントラントを有効化または禁止することができます。リエントラントはデフォルトによって無効化されています。活性化されたオブジェクトに対する要求が到着したときに、そのオブジェクトが異なるスレッドで別の要求を実行している場合、次の規則が適用されます。

注記 リエントラント・サーバント・メカニズムは、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 オブジェクトを使用してはなりません。代わりに、アプリケーションはほかのスレッドに CosTransactions::Control オブジェクトを受け渡します。CosTransctions::Current オブジェクトを受け渡すと、受信側のスレッドはそのスレッドに関連付けられているトランザクション状態だけにアクセスできます。

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

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

コンテキスト・サービス

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

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

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

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

build コマンドの機能

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

管理用ツール

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

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

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

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

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

 

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

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

buildobjserver コマンドの使い方

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

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

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

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

マルチスレッドをサポートする CORBA サーバ・アプリケーションを作成する場合、アプリケーションをビルドするときに buildobjserver コマンドで -t オプションを指定する必要があります。実行時に、BEA Tuxedo システムは、実行可能プログラムと、CORBA サーバ・アプリケーションのコンフィギュレーション・ファイル UBBCONFIG で選択されたスレッド・モデルとの互換性を検証します。UBBCONFIG ファイルでスレッド・モデルを設定する方法については、第 4 章の 45 ページ「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}] [-r rmname] [-b bootserverclass] [-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 オプションは、アプリケーションが共有コンテキスト・データ、およびスレッド・セーフではないほかのプログラミング構造を使用しないことを示します。スレッド・セーフではないシングル・スレッド・アプリケーションをマルチスレッド環境で実行する場合、データが破損するおそれがあります。

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

注記 プロセスを終了するための SIGKILL シグナルがサポートされています。シングル・スレッドまたはマルチスレッド・アプリケーションに対する SIGIO の使用は、BEA Tuxedo CORBA ではサポートされていません。

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

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

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

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

次に、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 オブジェクトのインプリメンテーションを提供します。

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

図 4-2 simpapp_mt サンプル・アプリケーション


 


 


 

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

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

インターフェイス

説明

アクション

SimplePerRequestFactory

Simple オブジェクトのオブジェクト・リファレンスを作成します。

find_simple()

SimplePerObjectFactory

Simple オブジェクトのオブジェクト・リファレンスを作成します。

find_simple()

Simple

文字列の大文字と小文字を変換します。

to_upper()

to_lower()

forward_upper()

forward_lower()

リスト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

  1. プロンプトに対して ksh コマンドを実行して、Korn シェルを起動します。

  2. printenv コマンドを実行して TUXDIRの設定を表示します。 
    ksh prompt> printenv TUXDIR

環境変数の設定の変更

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

Windows

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

prompt> set TUXDIR=directorypath

UNIX

  1. システム・プロンプトに対して ksh コマンドを実行して、Korn シェルを起動します。

  2. 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 ディレクトリをコピーするか、次のようにコマンド・プロンプトを使用します。

  1. simpapp_mt ファイルのコピー先となる作業ディレクトリを作成します。 
    > mkdir work_directory

  2. simpapp_mt ファイルを作業ディレクトリにコピーします。 
    > copy %TUXDIR%¥samples¥corba¥simpapp_mt¥* work_directory

  3. 作業ディレクトリに移動します。 
    cd work_directory

  4. 作業ディレクトリ内のすべてのファイルを表示します。 
    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 ディレクトリのコピーを作成するか、次のようにコマンド・プロンプトを使用します。

  1. simpapp_mt ファイルのコピー先となる作業ディレクトリを作成します。 
    > mkdir work_directory

  2. すべての simpapp_mt ファイルを作業ディレクトリにコピーします。 
    > cp $TUXDIR/samples/corba/simpapp_mt/* work_directory

  3. 作業ディレクトリに移動します。 
    cd work_directory

  4. 作業ディレクトリ内のすべてのファイルを表示します。 
    $ 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 ファイルとその説明を示します。

表 4-1 simpapp_mt ファイル

ファイル

説明

makefile.mk

(UNIX) simpapp_mt サンプル・アプリケーション用の Makefile。このファイルを使用してアプリケーションをビルドします。

makefile.nt

(Windows) simpapp_mt サンプル・アプリケーション用の Makefile。このファイルを使用してアプリケーションをビルドします。

Readme.txt

simpapp_mt サンプル・アプリケーションのビルドと実行に関する情報を提供する Readme ファイル。

runme.cmd

(Windows) simpapp_mt サンプル・アプリケーションをビルドおよび実行するためのコマンド・ファイル。

runme.ksh

(UNIX) simpapp_mt サンプル・アプリケーションをビルドおよび実行するための Korn シェル・スクリプト。

simple.idl

SimplePerRequestFactory、SimplePerObjectFactory、および Simple インターフェイスを宣言する Object Management Group (OMG) インターフェイス定義言語 (IDL) のコード。

simple_client.cpp

simpapp_mt サンプル・アプリケーション用の CORBA クライアント・プログラム・ソース・コード。

simple_per_object_i.cpp

サーバに組み込まれる Simple サーバントと SimplePerObjectFactory サーバントのインプリメンテーションが含まれるソース・コード。CORBA サーバは、オブジェクトごとのスレッド同時実行手法を使用して起動します。

simple_per_object_i.h

サーバに組み込まれる Simple サーバントと SimplePerObjectFactory サーバントを宣言するためのソース・コード。

simple_per_object_server.cpp

simpapp_mt サンプル・アプリケーション、オブジェクトごとのスレッド同時実行手法用の CORBA サーバ・プログラム・ソース・コード。UBBCONFIG ファイルに CONCURR_STRATEGY = PER_OBJECT を設定します。

simple_per_request_i.cpp

リエントラント・サーバに組み込まれる Simple サーバントと SimplePerRequestFactory サーバントのインプリメンテーションが含まれるソース・コード。リエントラント CORBA サーバは、要求ごとのスレッド同時実行手法を使用して起動します。

simple_per_request_i.h

サーバに組み込まれる Simple サーバントと SimplePerRequestFactory サーバントを宣言するためのソース・コード。

simple_per_request_server.cpp

simpapp_mt サンプル・アプリケーション、要求ごとのスレッド同時実行手法用の CORBA サーバ・プログラム・ソース・コード。UBBCONFIG ファイルに CONCURR_STRATEGY = PER_REQUEST を設定します。

simple_per_request_server.h

simpapp_mt サンプル・アプリケーションのユーザ定義 Server クラスに対して必要な宣言が含まれる bootserverclass.h ファイルの例。

thread_macros.cpp

simpapp_mt サンプル・アプリケーションをサポートするプラットフォーム非依存のスレッド・コンビニエンス・マクロ。

thread_macros.h

スレッド・コンビニエンス・マクロ用のすべてのクラスと変数を宣言するためのソース・コード・ファイル。

すべてのファイルのパーミッションのチェック

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

注記 make ユーティリティがパスに存在することを確認してください。

Windows

 
> attrib -R /S *.*

UNIX

 
> /bin/ksh
 
> chmod u+r work_directory/*.*

Executing the runme Command

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

Windows

 
> cd work_directory
 
> ./runme

UNIX

 
> /bin/ksh
 
> cd work_directory
 
> ./runme.ksh

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

  1. TUXDIR 環境変数をチェックします。

  2. このアプリケーションで使用される環境変数を設定します。

  3. 適切な bin ディレクトリが PATH にあることを確認します。

  4. このスクリプトが実行されるのが初めてではない場合、 不要なファイルをディレクトリから削除します。

  5. このスクリプトを実行することによって得られる結果を格納するためのディレクトリを作成します。

  6. setenv.ksh ファイル (UNIX) または setenv.bat ファイル (Windows) を作成し、このサンプルをステップ・バイ・ステップ・モードでビルドおよび実行できるようにします。

  7. このサンプル用の ubb コンフィギュレーション・ファイルを作成します。

  8. クライアントのユーザ入力を格納するファイルを作成します。

  9. クライアントからの期待される出力を格納するファイルを作成します。

  10. サンプルをビルドします。

  11. コンフィギュレーション・ファイルをロードします。

  12. オブジェクトごとのスレッド・サーバを起動します。

  13. 要求ごとのスレッド・サーバを起動します。

  14. クライアントを実行し、出力を取得します。

  15. その出力と期待された出力を比較します。

  16. サーバ・アプリケーションをシャットダウンします。

  17. サンプルの実行時に生成されるログを取得します。

  18. 結果を保存します。

  19. サンプルが正常に実行されたかどうかをユーザに通知します。

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 コマンドの実行によって作成されるファイルとその説明を示します。

表 4-2 作業ディレクトリに作成されるファイル

ファイル

説明

simple_c.cpp

simple.idl ファイルに対する idl コマンドによって作成されます。このモジュールには、Simple および SimplePerRequestFactory インターフェイス用のクライアント・スタブ機能が含まれます。

simple_c.h

simple.idl ファイルに対する idl コマンドによって作成されます。このモジュールには、Simple および SimplePerRequestFactory インターフェイスの定義とプロトタイプが含まれます。

simple_s.cpp

simple.idl ファイルに対する idl コマンドによって作成されます。このモジュールには、Simple_i および SimplePerRequestFactory_i インプリメンテーション用のスケルトン機能が含まれます。

simple_s.h

simple.idl ファイルに対する idl コマンドによって作成されます。このモジュールには、Simple_i および SimplePerRequestFactory_i インターフェイスの定義とプロトタイプが含まれます。

simple_client

simple_c.cpp および simple_client.cpp ファイルに対する buildobjclient コマンドによって作成されます。

simple_per_object_server

simple_c.cpp、simple_s.cpp、simple_per_object_i.cpp、simple_per_object_server.cpp、および thread_macros.cpp ファイルに対する buildobjserver コマンドによって作成されます。

simple_per_request_server

simple_c.cpp、simple_s.cpp、simple_per_request_i.cpp、simple_per_request_server.cpp、および thread_macros.cpp ファイルに対する buildobjserver コマンドによって作成されます。

results directory

このスクリプトの実行結果を取得するために runme コマンドによって作成されます。

adm directory

セキュリティ暗号化キー・データベース・ファイルを格納するために runme コマンドによって作成されます。

表 4-3 results ディレクトリに作成されるファイル

ファイル

説明

input

runme コマンドが C++ クライアント・アプリケーションに提供する入力を格納するために runme コマンドによって作成されます。

output

runme コマンドが C++ クライアント・アプリケーションを実行するときの出力を格納するために runme コマンドによって作成されます。

expected_output

runme コマンドが実行されるときに期待される出力を格納するために runme コマンドによって作成されます。この出力ファイルを比較して、テストに合格したかどうかを決定します。

log

runme コマンドによって生成される出力を格納するために runme コマンドによって作成されます。このコマンドが失敗した場合、このファイルと ULOG ファイルでエラーをチェックします。

setenv.cmd

(Windows) simpapp_mt サンプル・アプリケーションをステップ・バイ・ステップ・モードでビルドおよび実行するために必要な環境変数を設定するためのコマンド・ファイル。

setenv.ksh

(UNIX) simpapp_mt サンプル・アプリケーションをステップ・バイ・ステップ・モードでビルドおよび実行するために必要な環境変数を設定するためのコマンド・ファイル。

stderr

tmboot によって生成されるメッセージが含まれます。-noredirect サーバ・オプションが UBBCONFIG ファイルに指定されている場合、fprintf メソッドは出力をこのファイルに送信します。

stdout

tmboot によって生成されるメッセージが含まれます。-noredirect サーバ・オプションが UBBCONFIG ファイルに指定されている場合、fprintf メソッドは出力をこのファイルに送信します。

tmsysevt.dat

runme コマンドの tmboot コマンドによって生成されます。このファイルには、TMSYSEVT プロセスで使用されるフィルタ規則と通知規則が含まれます。

tuxconfig

コンフィギュレーション・ファイルのバイナリ・バージョン。

ubb

simpapp_mt サンプル・アプリケーション用の UBBCONFIG ファイル。

ULOG.date

実行時エラーを格納するための ULOG ファイル。

 

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

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

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

  1. 環境変数を設定します。

    Windows

     
    > ..¥results¥setenv

    UNIX

     
    > ../results/setenv.ksh

  2. 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-4 tmboot によって起動するサーバ・プロセス

プロセス

説明

TMSYSEVT

システム EventBroker。

TMFFNAME

TMFFNAME サーバ・プロセス。

simple_per_object_server

オブジェクトごとのスレッド・サーバとして起動します。

simple_per_request_server

リエントラントな要求ごとのスレッド・サーバとして起動します。

ISL

IIOP リスナ・プロセス。

  1. クライアント・アプリケーションを実行します。

    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 サンプル・アプリケーションをシャットダウンして、不要なファイルを作業ディレクトリからすべて削除する必要があります。

  1. アプリケーションを終了するには、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.

  1. 作業ディレクトリを元の状態に戻します。

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

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

50 + 50 + 50 + 50 = 200 accessors

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 に設定されます。

スレッド・モデルの特性については、「第 4 章の 6 ページ「スレッド・モデル」」を参照してください。

活性化されたオブジェクトの数の指定

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

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

*RESOURCES
MAXOBJECTS number

特定のマシンのシステム全体にわたる設定を上書きするには、次のように指定します。

*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
     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

 

Back to Top Previous Next
dev2devesupportedocs.bea.compartner net
Contact e-docsContact BEAwebmasterprivacy