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

このトピックには次の項が含まれます:

•

概要

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

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

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

概要

このトピックには次の項が含まれます:

•

はじめに

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

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

はじめに

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

•	ほかの処理に必ずしも依存しない一連の長い操作が存在します。

•	共有されるデータの量が少なく、識別可能です。

•	並列に実行できる複数のアクティビティにタスクを分割できます。

•	オブジェクトがリエントラントでなければならないときが存在します。

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

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

•	サーバー・オブジェクトのインスタンスが複数のクライアント・リクエストを同時に処理できます。

•	サーバー・オブジェクトが自身に対する再帰的呼出しを行うことができます。

•	サーバー・オブジェクトが独自のスレッドを作成およびモニターして、サーバント・メソッドの中で並列処理を実装できます。

図4-1 マルチスレッドCORBAサーバー・アプリケーション

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

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

要件、目標、概念

コンピュータ操作の中には、完了までに長い時間を要するものがあります。マルチスレッド設計では、操作がリクエストされてから完了するまでの間の待機時間を大幅に短縮できます。これは、データベースにアクセスするとき、リモート・オブジェクトの操作を呼び出すとき、マルチプロセッサ・マシン上の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管理機能として設定できます。アプリケーション自体に変更を加えずにプールのサイズを調節できます。

•	Oracle Tuxedoソフトウェアは、必要に応じてプールからスレッドを割り当てます。スレッドはリクエストが処理される間使用され、その後プールに戻されます。

•	スレッドは、複数のリクエストとオブジェクトを処理するために連続的に再利用できます。

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

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

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

•	_is_reentrantメソッドがTRUEを返した場合、新しいスレッドがプールから割り当てられ、同じサーバント・インスタンスを使用して適切なメソッドにリクエストがディスパッチされます。複数のスレッドがオブジェクトと対話する場合にオブジェクトの状態の整合性を保証するのは、サーバント実装コードの責任となります。

•	_is_reentrantメソッドがFALSEを返した場合、サーバントの新しいインスタンスが作成され、メソッドが新しいインスタンスにディスパッチされます。このインスタンスは自動的に削除されません。以後のリエントラント・リクエストはいずれかのインスタンスにディスパッチされます。

注意:	リエントラント・サーバント・メカニズムは、PER_REQUEST同時実行性戦略が指定された状態でサーバーが起動した場合にのみ使用可能です。

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

Currentオブジェクト

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

•	個々のスレッドは、適切なトランザクション・コンテキストとセキュリティ・コンテキストの中で機能します。

•	Currentオブジェクトは、異なるスレッドからアクセスされたときに適切に振る舞います。

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

•	あるスレッドが別のスレッドの状態を操作するのを防ぐため

•	メソッドごとにスレッド・コンテキスト内で新しいCurrentオブジェクトを取得してナロー変換する必要性をなくすため

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

•	CosTransactions::Current

•	SecurityLevel1::Current

•	SecurityLevel2::Current

•	PortableServer::Current

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

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

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

•	コンテキスト・サービス

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

•	buildコマンドの機能

•

管理用ツール

コンテキスト・サービス

オブジェクト実装に独自のスレッドを作成して管理することを選択できます。他のスレッドは、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()に関する項を参照してください。

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

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クラスに関する項を参照してください。

buildコマンドの機能

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

•	buildobjserverコマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、サーバー・アプリケーションはOracle Tuxedoソフトウェアのマルチスレッド・サポートとの互換性を保持します。

buildobjserverコマンドには、マルチスレッド・サーバー・アプリケーションまたはシングル・スレッド・サーバー・アプリケーションをビルドするためのコマンド行オプションが組み込まれています。

•	buildobjclientコマンドには、プラットフォーム固有のスレッド・ライブラリ・サポートが組み込まれています。このため、クライアント・アプリケーションはOracle Tuxedoソフトウェアのマルチスレッド・サポートとの互換性を保持します。

管理用ツール

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

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

•	サーバーをシングル・スレッドにするか、マルチスレッドにするか

•	オブジェクトのメソッドをディスパッチするためのスレッド・プールのサイズ

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

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

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

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

このトピックには次の項が含まれます:

•	buildobjserverコマンドの使い方

•	buildobjclientコマンドの使い方

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

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

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

buildobjserverコマンドの使い方

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

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

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

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

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

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

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

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

注意:	CORBAサーバー・アプリケーションのビルド時に-tを指定する場合、UBBCONFIGファイルのMAXDISPATCHTHREADSパラメータを1より大きい値に設定する必要があります。それ以外の値を設定すると、CORBAサーバー・アプリケーションはシングル・スレッド・サーバーとして動作することになります。

注意:	マルチスレッド共同クライアント/サーバー実装はサポートされていません。

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

•	Oracle Tuxedoソフトウェアは、ログ・ファイルに警告を記録します。

•	サーバーの実行可能プログラムがシングル・スレッド・サーバーとして起動します。

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

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ファイルは、このサンプル・コードと同じようなロジックを提供します。

リスト4-1 bootserverclass.hファイルの例

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

 

buildobjclientコマンドの使い方

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

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

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

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

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

•	メソッドはOracle Tuxedoシステムによって割り当てられた任意のスレッドで実行されます。

•	サーバント実装コードは、オブジェクトがその状態に同時アクセスされることを必ずしも防ぎません。ただし、アクティブなサーバントは、一度に1つの実行スレッドに限定されます。

•	メソッドが特定のスレッドで実行されることを保証できません。特定のスレッドに依存しているか、関連付けられているストレージを使用しないでください。

•	サーバントのactivate_objectメソッドまたはdeactivate_objectメソッドが当初呼び出されたリクエストと同じスレッドで実行されるとは仮定しないでください。

•	追加のアプリケーション管理スレッドをサーバント・メソッドの中に作成できます。オブジェクト実装は、スレッドが適切に作成、処理および破棄されることを保証する必要があります。

•	アプリケーション管理スレッドには、ほかのオブジェクトの呼出しを組み込むことができます。

•	同期化のためにシグナルを使用しないでください。シグナルとスレッドの混在はサポートされていません。

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

•	リクエスト・レベルのインターセプタは、そのメソッドによって使用される同じスレッドを通じてOracle Tuxedo CORBAによって呼び出されます。

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

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

•	buildobjserverコマンドと-tオプションを使用してCORBAサーバー・アプリケーションをビルドし、そのアプリケーションのUBBCONFIGサーバー構成ファイルを修正します。

•	CORBAサーバー・アプリケーション・コードを更新し、TobjServantBase::_is_reentrantメソッドを使用してリエントラントを有効化します。

•	UBBCONFIGファイルでCONCURR_STRATEGY = PER_REQUESTを指定することによって、リクエストごとのスレッド・モデルを使用してサーバーを起動します。

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

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

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

•	IIOPを使用したマルチスレッドCORBAクライアントがサポートされています。

•	マルチスレッド・ネイティブCORBAクライアントはサポートされていません。

•	マルチスレッドCORBAクライアントは、単一Bootstrapオブジェクトに制限されています。

•	マルチスレッドCORBAクライアントは、ドメインへの単一ログオンに制限されています。

•	スタブ・ベースの呼出しを使用するCORBAクライアントがサポートされています。

•	動的起動インタフェース(DII)を使用するCORBAクライアントはサポートされていません。

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

このトピックには次の項が含まれます:

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

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

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

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

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

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サンプル・アプリケーションの操作を示します。

図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
{
//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に、このプロセスの要約を示します。以降の項では、これらのタスクを実行する方法について説明します。

図4-3 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

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

runmeコマンドを実行する

この項では、アプリケーションのエンドツーエンドの実行に必要な手順について説明します。次のように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ディレクトリに格納されます。実行時に作成された出力を見るには、次のファイルを参照します。

•	log - コンパイル、サーバー起動またはサーバー停止のエラー

•	output - クライアント・アプリケーションの出力と例外

•	ULOG.date - サーバー・アプリケーションのエラーと例外

表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ディレクトリ	このスクリプトの実行結果を取得するためにrunmeコマンドによって作成されます。
admディレクトリ	セキュリティ暗号化キー・データベース・ファイルを格納するために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サーバー・プロセス。 • Master NameManager - -Nオプションと-Mオプションを両方指定したときに起動するTMFFNAMEサーバー・プロセス。 • SLAVE NameManager - -Nオプションのみを指定したときに起動するTMFFNAMEサーバー・プロセス。 • FactoryFinderオブジェクト - -Fオプションにこのオブジェクトが指定されているときに起動するTMFFNAMEサーバー・プロセス。
simple_per_object_server	オブジェクトごとのスレッド・サーバーとして起動します。
simple_per_request_server	リエントラントなリクエストごとのスレッド・サーバーとして起動します。
ISL	IIOPリスナー・プロセス。

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

Windows

> .\simple_client

UNIX

> ./simple_client

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

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

サーバー・プロセスをシャットダウンしています...

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.

adminプロセスをシャットダウンしています...

Server Id = 0 Group Id = SITE1 Machine = SITE1: shutdown succeeded.
7 processes stopped.

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

Windows

> ..\results\setenv
> make -f clean

UNIX

> ../results/setenv.ksh
> make -f makefile.mk clean

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

このトピックには次の項が含まれます:

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

•	スレッド・モデルの指定

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

•	UBBCONFIGファイルの例

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

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

MAXDISPATCHTHREADS

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

•	MAXDISPATCHTHREADSの値によって、受信するリクエストを格納するために拡大できる、スレッド・プールの最大サイズが決定されます。

•	MAXDISPATCHTHREADSのデフォルト値は1です。1より大きい値を指定した場合、特別なディスパッチ・スレッドが作成および使用されます。このディスパッチャ・スレッドは、スレッド・プールの最大サイズを決定するスレッド数には、含まれていません。

注意:	MAXDISPATCHTHREADSに1より大きい値を指定し、CONCURR_STRATEGYスレッド・モデル・パラメータの値を指定しなかった場合、アプリケーションのスレッド・モデルはデフォルトによってオブジェクトごとのスレッドに設定されます。CONCURR_STRATEGYスレッド・モデル・パラメータの詳細は、4-35ページの「スレッド・モデルの指定」を参照してください。

•	MAXDISPATCHTHREADSパラメータの値に1を指定した場合、CORBAサーバー・アプリケーションがシングル・スレッド・サーバーとして構成されることを示します。

注意:	buildobjserver -tを指定してマルチスレッドCORBAサーバー・アプリケーションをビルドする場合、そのサーバーはマルチスレッド・モードで実行可能です。マルチスレッド型CORBAサーバー・アプリケーションを実行するには、UBBCONFIGファイルのMAXDISPATCHTHREADSパラメータを1よりも大きい値に設定する必要があります。そうしないと、サーバー・アプリケーションはシングル・スレッド・モードで実行されます。

•	MAXDISPATCHTHREADSパラメータに指定する値は、MINDISPATCHTHREADSパラメータに指定する値以上である必要があります。

•	オペレーティング・システムのリソースによって、1つのプロセスで作成できるスレッドの最大数が制限されます。MAXDISPATCHTHREADSは、その制限値から、アプリケーションが必要とするアプリケーション管理スレッドの数を差し引いた値未満にする必要があります。

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

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

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

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

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

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

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

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

*RESOURCES
MAXOBJECTS number

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

*MACHINES
MAXOBJECTS = number

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

UBBCONFIGファイルの例

リスト4-4に、Oracle 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