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

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

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

概要

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

はじめに

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

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

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

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

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

要件、目標、概念

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

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

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

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

スレッド モデル

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

このメソッドの使い方については、『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 ファイルは、このサンプル コードと同じようなロジックを提供します。

// ファイル名  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
{
     // 文字列を小文字に変換 (新しい文字列を返す)
     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 サンプル アプリケーションをビルドおよび実行するプロセスをステップごとに説明します。次のフローチャートに、このプロセスの要約を示します。以降の節では、これらのタスクを実行する方法について説明します。

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 によって起動するサーバ プロセスを示します。

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

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