CORBAプログラミング・リファレンス

TPフレームワーク

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

Oracle Tuxedo CORBA TPフレームワークでは、ユーザーが高パフォーマンスのTPアプリケーション用のサーバーを作成することを可能にするプログラミングTPフレームワークを提供します。ここでは、TPフレームワークのプログラミング・モデルおよびアプリケーション・プログラミング・インタフェース(API)について詳しく説明します。このAPIの使用方法については、『CORBAサーバー・アプリケーションの作成』でも説明しています。

Oracle Tuxedo CORBAサーバーを開発する場合、TPフレームワークは必須です。この要件は今後のリリースで緩和される予定ですが、多くの場合、TPフレームワークはアプリケーションの主要な構成部分として使用されると考えられます。

Oracle Tuxedoでは、ロード・バランシング、トランザクション機能、および管理機能を備えたインフラストラクチャを提供します。TPフレームワークで使用される基本APIは、Oracleが拡張したCORBA APIです。TPフレームワークのAPIは、顧客に公開されます。Oracle Tuxedo ATMIは、TPフレームワークのAPIと混在して利用可能なオプションのAPIです。このAPIを使用すると、CORBAサーバーとATMIサーバーが混在する環境で分散アプリケーションをデプロイできます。

Oracle Tuxedo CORBA以前、ORB製品は大規模環境ではOracle Tuxedoのパフォーマンスに及びませんでした。Oracle Tuxedoシステムは、1秒あたり数百のトランザクションを処理するアプリケーションをサポートしています。こうしたアプリケーションは、各リクエストで使用するシステム・リソースを最小限に抑え、したがってスループットおよびコスト・パフォーマンスを最大限に引き出す、Oracle Tuxedoのステートレス・サービス・プログラミング・モデルを使用してビルドされます。

現在では、Oracle Tuxedo CORBAとTPフレームワークによって、Oracle Tuxedo ATMIアプリケーションと同等のパフォーマンスを持つCORBAアプリケーションを開発できます。Oracle Tuxedo CORBAサーバーは、CORBAプログラミング・モデルを使用しながら、Oracle Tuxedoステートレス・サービス・プログラミング・モデルに近いスループット、レスポンス時間、およびプライス・パフォーマンスを実現します。

単純なプログラミング・モデル

TPフレームワークでは、単純で便利なCORBAオブジェクトのさまざまな実装のサブセットを選択できます。使用できるのは、サーバー側オブジェクトの実装を開発する場合のみです。クライアント側CORBA ORBを使用する場合、クライアントは、TPフレームワークが管理するサーバー側実装を持つCORBAオブジェクトと対話します。非Oracle Tuxedoサーバー環境で実行されるCORBAオブジェクトにアクセスするように作成されたクライアントは、クライアント・インタフェースの変更や制約もなく、Oracle Tuxedoサーバー環境で実行される同じCORBAオブジェクトにアクセスできます。

TPフレームワークでは、CORBAポータブル・オブジェクト・アダプタ(POA)よりも使いやすく、理解も簡単で、特にエンタープライズ・アプリケーション向けに準備されたサーバー環境およびAPIが提供されます。これは、単純なサーバー・プログラミング・モデルと、ORBIXやVisiBrokerなどのORBを使用していたプログラマにはなじみのある従来のCORBAモデルの実装です。

TPフレームワークを使用すると、次の方法でサーバー環境の複雑さを抑えて、Oracle Tuxedo CORBAサーバーのプログラミングが容易になります。

TPフレームワークには、次の機能があります。

制御フロー

TPフレームワークは、ORBおよびPOAと連携して、次の方法でアプリケーション・プログラムのフローを制御します。

オブジェクトの状態管理

TPフレームワークAPIには、アプリケーション・コードにCORBAオブジェクトの柔軟な状態管理スキームを実装するためのコールバック・メソッドが用意されています。状態管理では、オブジェクトを非アクティブ化したりアクティブ化したりするときのオブジェクトの状態を保存および復元する必要があります。状態管理は、サーバーのパフォーマンスおよびリソース使用量に影響を与える、アクティブ化されたオブジェクトの有効期間にも関係します。アクティブ化されたオブジェクトのデフォルトの有効期間は、IDLのコンパイル時に実装に割り当てたポリシーによって制御されます。

トランザクションの統合

TPフレームワークのトランザクション統合には次の機能があります。

オブジェクトのハウスキーピング

TPフレームワークでは、サーバーの停止時に、サーバーが関与しているすべてのトランザクションがロールバックされ、アクティブ化されているすべてのCORBAオブジェクトが非アクティブ化されます。

高レベルのサービス

TPフレームワークAPIのTPインタフェースには、オブジェクトの登録とユーティリティ関数を実行するメソッドが用意されています。以下のサービスが提供されます。

こうした高レベル・サービスのメソッドは、開発者がCORBA POA、CORBAネーミング・サービス、およびOracle Tuxedo APIを理解しなくても、基となる実装として使用できるようにすることを目的としています。基となるAPI呼出しを高レベルのメソッドのセットと一緒にカプセル化することで、プログラマは、より複雑な基本機能を理解したり使用したりすることなく、ビジネス・ロジックの実現に集中することが可能となります。

状態管理

状態管理では、オブジェクトを非アクティブ化したりアクティブ化したりするときのオブジェクトの状態を保存および復元する必要があります。状態管理は、サーバーのパフォーマンスおよびリソース使用量に影響を与える、アクティブ化されたオブジェクトの有効期間にも関係します。TPフレームワークの外部APIには、activate_objectおよびdeactivate_objectメソッドが用意されています。これらのメソッドは、状態管理コードを配置可能な場所を示します。

アクティブ化ポリシー

TPフレームワークでは、状態管理はアクティブ化ポリシーによって提供されます。このポリシーは、サーバントの作成および破棄ではなく、特定のIDLインタフェースに対するサーバントのアクティブ化および非アクティブ化を制御します。このポリシーが適用されるのは、TPフレームワークを使用するCORBAオブジェクトのみです。

アクティブ化ポリシーは、CORBAオブジェクトがメモリー内でアクティブ化しているデフォルトの期間を決定します。CORBAオブジェクトがPOA内でアクティブ化されているのは、POAのアクティブ・オブジェクト・マップにオブジェクトIDと既存のサーバントを関連付けるエントリが入っている場合です。オブジェクトを非アクティブ化すると、オブジェクトIDとアクティブ化されたサーバントとの関連付けが削除されます。選択できるアクティブ化ポリシーは、method (デフォルト)、transaction、processのいずれかです。

各アクティブ化ポリシーの内容は次のとおりです。

アプリケーション制御のアクティブ化および非アクティブ化

通常、アクティブ化と非アクティブ化の決定は、この章で前述したようにTPフレームワークで行われます。この項の手法は、代替メカニズムの使用方法を示します。アプリケーションは、特定のポリシーを持つオブジェクトのアクティブ化と非アクティブ化のタイミングを明示的に制御できます。

明示的なアクティブ化

アプリケーション・コードでは、processアクティブ化ポリシーを使用するオブジェクトに関して、TPフレームワークのオン・デマンド・アクティブ化機能を無効にすることができます。アプリケーションでは、TP::create_active_object_reference呼出しを使用して、オブジェクトを「事前アクティブ化」、つまり呼出しの前にアクティブ化することができます。

事前アクティブ化のしくみは次のとおりです。アプリケーションは、オブジェクト参照を作成する前に、サーバントをインスタンス化して、その状態を初期化します。アプリケーションはTP::create_active_object_referenceを使用して、オブジェクトをアクティブ・オブジェクト・マップに追加、つまりサーバントとObjectIdを関連付けます。最初の呼出しが行われると、TPフレームワークが、オブジェクト参照を作成したプロセスに直ちにリクエストを転送してから、既存のサーバントに転送します。この際、オブジェクトに対する2番目以降の呼出しと同じように、Server::create_servantに次いでサーバントのactivate_objectメソッドを呼び出す必要はありません。こうしたオブジェクトのオブジェクト参照は別のサーバーを指さないので、アクティブ化されている限り、オブジェクトがオン・デマンドでアクティブ化されることはありません。

事前アクティブ化されたオブジェクトにはprocessアクティブ化ポリシーが設定されているので、プロセスの終了またはTP::deactivateEnable呼出しのいずれかのイベントが発生するまで、オブジェクトはアクティブ化されたままとなります。

使用上の注意

事前アクティブ化は、アプリケーションが共有メモリーなどを使用して状態を初期化して、初期状態のサーバントを同じプロセスで確立する必要がある場合に特に有用です。状態にポインタ、オブジェクト参照、または複雑なデータ構造が含まれている場合、後で別のプロセスで状態が初期化されるまで待機する処理は非常に難しくなるからです。TP::create_active_object_referenceを使用すると、事前アクティブ化されたオブジェクトは、事前アクティブ化を実行したコードと必ず同じプロセスにあります。事前アクティブ化によってリソースがあらかじめ割り当てられるので、便利な手法であっても、事前アクティブ化を多用することは控える必要があります。ただし、必要に応じて適切に使用すれば、事前アクティブ化はその他の方法よりもはるかに効率的です。

適切な使い方の例として、「イテレータ」パターンを使用するオブジェクトがあります。たとえば、「database_query」メソッドから電話帳の内容のような長い項目リストが無制限IDLシーケンスで返される可能性があるとします。メッセージ・サイズも必要なメモリー量も非常に大きくなるので、こうした項目をすべてシーケンスで返すことは非効率的です。

イテレータ・パターンを使用するオブジェクトは、リストを取得する最初の呼出しで、一定数の項目をシーケンスで返し、さらに要素を取得する場合に呼び出せる「イテレータ」オブジェクトへのリファレンスも返します。イテレータ・オブジェクトは初期オブジェクトによって初期化されます。つまり、初期オブジェクトはサーバントを作成してその状態を設定し、反復処理が長い項目リストのどの位置で止まっているか(データベース、問い合わせパラメータ、カーソルなどを指すポインタ)を追跡します。

初期オブジェクトは、TP::create_active_object_referenceを使用してこのイテレータ・オブジェクトを事前にアクティブ化します。また、そのオブジェクトへのオブジェクト参照を作成してクライアントに戻します。クライアントは、イテレータ・オブジェクトを繰り返し呼び出して、たとえば毎回リスト内の次の100項目を受信します。この状況での事前アクティブ化の利点は、状態を複雑化できることです。多くの場合、初期オブジェクトに制御があるときに、そのコンテキスト(呼出しフレーム)にすべての情報を含むメソッドからこのような状態を最初に設定することが最も簡単です。

クライアントがイテレータ・オブジェクトの操作を終了したら、初期オブジェクトで最終メソッドを呼び出して、イテレータ・オブジェクトを非アクティブ化します。初期オブジェクトは、TP::deactivateEnableメソッドを呼び出すイテレータ・オブジェクトのメソッドを呼び出すことで、イテレータ・オブジェクトを非アクティブ化します。つまり、イテレータ・オブジェクトは、TP::deactivateEnableメソッドを自身に対して呼び出します。

注意事項

通常、この方法で事前アクティブ化されたオブジェクトの場合、クラッシュすると状態を回復することはできません。最初の遅延アクティブ化で設定するには、状態が複雑すぎるか、一貫性を維持できないと考えられるからです。これは、基本的にオブジェクトが1回のアクティブ化期間のみ有効であることを示しており、効果的なオブジェクトのテクニックです。

ただし、「1回」という使い方のために問題が発生する場合があります。クライアントが状態を含むプロセスにつながるオブジェクト参照を保持しており、クラッシュするとその状態を再度作成することができないので、クライアントの次の呼出しが自動的にオブジェクトを新しくアクティブ化することがないように注意を払う必要があります。新しくアクティブ化するとオブジェクトが不当な状態を持つことになるからです。

この問題を解決する方法は、オブジェクトがTPフレームワークによって自動的にアクティブ化されないようにすることです。activate_object呼出しの結果としてTobjS::ActivateObjectFailed例外をTPフレームワークに提供した場合、TPフレームワークはアクティブ化を実行せず、CORBA::OBJECT_NOT_EXIST例外をクライアントに返します。クライアントにはイテレータ(または類似)パターンについての知識があるので、こうした状況について想定しています。クライアントは反復を再起動するように準備する必要があります。

自己非アクティブ化

processアクティブ化ポリシーを設定したオブジェクトを事前アクティブ化できるように、processアクティブ化ポリシーを設定したオブジェクトを非アクティブ化するよう要求することもできます。事前アクティブ化する機能と非アクティブ化を要求する機能は独立しています。つまり、オブジェクトがどのようにアクティブ化されたかに関係なく、オブジェクトを明示的に非アクティブ化することができます。

アプリケーションのメソッドは、TP::deactivateEnable使用して、オブジェクトを非アクティブ化するようにリクエストできます。TP::deactivateEnableを呼び出して、オブジェクトが非アクティブ化された場合、CORBAオブジェクトに対する以降の呼出しによって、以前にアクティブ化されたように、同じプロセスで再度アクティブ化されるとはかぎりません。ObjectIdとサーバントとの関連付けは、CORBAオブジェクトがアクティブ化されてから、サーバー・プロセスが停止されるか、アプリケーションがTP::deactivateEnableを呼び出すまで持続します。関連付けが解除された後、オブジェクトをもう一度呼び出すと、Oracle Tuxedo構成パラメータで許可された場所で再度アクティブ化することができます。

TP::deactivateEnableには2つの形式があります。最初の形式(パラメータなし)では、実行中のオブジェクトは、呼出しが行われたメソッドの終了後に非アクティブ化されます。非アクティブ化するかどうかはオブジェクト自身が決定します。通常、この非アクティブ化は、「サインオフ」シグナルとして機能するメソッド呼出しで行われます。

2番目の形式のTP::deactivateEnableでは、サーバーは、オブジェクトが実行中かどうかにかかわりなく、アクティブ化されている任意のオブジェクトを非アクティブ化するよう要求できます。つまり、どのサーバーもオブジェクトを非アクティブ化するよう要求できます。この形式では、非アクティブ化するオブジェクトを識別するパラメータを指定します。transactionアクティブ化ポリシーが設定されたオブジェクトを明示的に非アクティブ化することはできません。トランザクションが終了するまで、そうしたオブジェクトを安全に非アクティブ化することができないからです。

TP::deactivateEnable呼出しで、TPフレームワークはサーバントのdeactivate_objectメソッドを呼び出します。TPフレームワークがdeactivate_objectを呼び出す正確なタイミングは、非アクティブ化されるオブジェクトの状態によって異なります。オブジェクトが実行中でない場合、TPフレームワークは、制御が呼出し側に戻る前に、オブジェクトを非アクティブ化します。オブジェクトが実行中の場合もあります。これは常にパラメータを持たないTP::deactivateEnable の場合です。この形式では、実行中のオブジェクトが参照されるからです。この場合、TP::deactivateEnableには、オブジェクトが直ちに非アクティブ化されたかどうか通知されません。

サーバントの存続期間

サーバントとは、IDLインタフェースのオペレーションを実装するメソッドを格納したC++クラスのことです。ユーザーはサーバントのコードを記述します。TPフレームワークは、サーバント・コードのメソッドを呼び出してリクエストを満たします。サーバントは、C++の「new」文で作成され、C++の「delete」文で破棄されます。ここでは、作成と破棄、および作成と破棄のタイミングについて説明します。

通常のケース

通常、TPフレームワークはサーバントの存続期間を完全に制御します。基本モデルでは、アクティブ化されていないオブジェクトに対するリクエストを受け取ると、TPフレームワークがサーバントを取得してから、activate_objectメソッドを呼び出してサーバントをアクティブ化します。非アクティブ化する場合、TPフレームワークはサーバントのdeactivate_objectメソッドを呼び出してから、サーバントを破棄します。

「TPフレームワークがサーバントを取得」するフェーズは、TPフレームワークが、サーバントを作成する必要がある場合に、ユーザー作成のサーバー・メソッド、Server::create_servantまたはServerBase::create_servant_with_idを呼び出す、ということです。このとき、アプリケーション・コードはリクエストされたサーバントを指すポインタを返す必要があります。ほとんどの場合、アプリケーションは、サーバントの新しいインスタンスを作成するC++の「new」文を使用することで、この処理を行います。「サーバントを破棄」するフェーズは、TPフレームワークが、実際に削除するサーバントへのリファレンスを削除する、ということです。

アプリケーションでは、サーバントを作成および削除する動作が将来のバージョンの製品で変更される可能性があることを考慮しておく必要があります。アプリケーションは現在の動作に依存してはなりませんが、サーバントを再利用するサーバント・コードを記述する必要があります。具体的には、サーバント・コードは、サーバントがC++の「new」文によって作成されていない場合でも、動作しなければなりません。TPフレームワークは、サーバントが非アクティブ化されてからも削除しないで、後で再度アクティブ化することができます。つまり、サーバントは、コンストラクタでサーバントが作成されたときではなく、サーバントのactivate_objectメソッドでコールバックされたときに自身を初期化しなければならないということです。

特殊なケース

アプリケーションでTPフレームワークの標準的なサーバントの使い方を変更するには、2つのテクニックがあります。サーバントの取得に関するものとサーバントの破棄に関するものです。

アプリケーションでは、明示的な事前アクティブ化により、「取得」メカニズムを変更できます。この場合、アプリケーションはサーバントを作成して初期化してから、サーバントをアクティブ化された状態として宣言するようにTPフレームワークに要求します。こうしたサーバントは、TP::create_active_object_reference呼出しによってTPフレームワークに渡されると、その他のサーバントとまったく同じようにTPフレームワークによって扱われます。唯一の違いは、作成および初期化の方法です。

アプリケーションは、サーバントの破棄をTPフレームワークに任せるかわりに自身で処理することで、「破棄」メカニズムを変更できます。サーバントがServer::create_servant、ServerBase::create_servant_with_idまたはTP::create_active_object_referenceによってTPフレームワークに通知されると、TPフレームワークのデフォルト動作は、そのサーバント自体を削除することになります。この場合、アプリケーション・コードでは、非アクティブ化後にそのサーバントへのリファレンスを使用してはなりません。

ただし、アプリケーションからTPフレームワークに対して、TPフレームワークがサーバントを非アクティブ化した後にサーバントを破棄しないように指示することはできます。サーバントの処理は、サーバントのクラス全体について行うのではなく、サーバントを識別するパラメータを付けてTobj_ServantBase::_add_refを呼び出すことで、個別に行います。

サーバントの処理を行うアプリケーションの利点は、サーバントを新しく作成せずに済むことです。サーバントの取得に大きなコストが伴う場合、アプリケーションではサーバントを保存しておいて、後でそれを再利用すると便利です。特に便利なのは事前アクティブ化されたオブジェクトのサーバントの場合ですが、一般的にも言えることです。たとえば、TPフレームワークが次にServer::create_servantまたはServerBase::create_servant_with_idを呼び出した場合、アプリケーションは以前に保存しておいたサーバントを返すことができます。

また、アプリケーションがサーバントの処理を行うようにすると、アプリケーションは、サーバントが必要でなくなったとき、つまりほかのC++インスタンスと同じように、リファレンス数がゼロになったときに、Tobj_ServantBase::_remove_refを使用してサーバントを削除しなければなりません。_remove_ref()メソッドのしくみについては、「Tobj_ServantBase::_remove_ref()」を参照してください。

シングル・スレッドおよびマルチスレッドのサーバー・アプリケーションの作成方法については、『CORBAサーバー・アプリケーションの作成』を参照してください。

オブジェクトの状態の保存と復元

CORBAオブジェクトがアクティブ化されている間、オブジェクトの状態はサーバント内に格納されます。TP::create_active_object_referenceを使用するアプリケーションと違い、状態は、オブジェクトが最初に呼び出されたとき、つまりオブジェクト参照の作成後にCORBAオブジェクトに対してメソッドが最初に呼び出されたときと、オブジェクトが非アクティブ化されて以降の呼出しで初期化しなければなりません。CORBAオブジェクトが非アクティブ化されている間、オブジェクトの状態をサーバントがアクティブ化されていたプロセスの外部に保存する必要があります。オブジェクトの状態は、共有メモリー、ファイル、データベースなどに保存できます。CORBAオブジェクトを非アクティブ化する前に、オブジェクトの状態を保存して、オブジェクトがアクティブ化されたときに状態を復元する必要があります。

プログラマは、オブジェクトの状態の構成要素と、オブジェクトを非アクティブ化する前に何を保存し、オブジェクトをアクティブ化した後に何を復元するかを決定する必要があります。

CORBAオブジェクトのコンストラクタおよびデストラクタの使い方に関する注意

CORBAオブジェクトの状態をサーバント・クラスのコンストラクタまたはデストラクタで初期化、保存、または復元してはなりません。TPフレームワークが、サーバントのインスタンスを非アクティブ化するときに削除しないで、再利用する可能性があるからです。サーバントのインスタンスの作成および削除のタイミングについては、一切保証されません。

トランザクション

以降のセクションでは、トランザクション・ポリシーとトランザクションの使い方について説明します。

トランザクション・ポリシー

CORBAオブジェクトがグローバル・トランザクションに参加できるかどうかは、コンパイル時に実装に割り当てられたトランザクション・ポリシーによって制御されます。以下のポリシーを割り当てることができます。

トランザクションの初期化

トランザクションの初期化には、次の2つの方法があります。

トランザクションの終了

一般に、トランザクションの結果を処理することは、開始プロセスの責任です。したがって、次のことが言えます。

Oracle Tuxedoシステムによって、以下の動作が強制的に実行されます。

トランザクションの一時停止と再開

CORBAオブジェクトは、メソッド呼出し内のトランザクションの一時停止および再開に関する規則に厳密に従う必要があります。以下に、これらの規則と規則に違反した場合のエラーについて説明します。

CORBAオブジェクト・メソッドが実行を開始すると、トランザクションに関する状態は次の3つのいずれかになります。

トランザクションに関する制約

Oracle Tuxedo CORBAトランザクションには、以下の制約が適用されます。

SQLとグローバル・トランザクション

SQLおよびグローバル・トランザクションを使用する場合には、次のガイドラインに従ってください。

トランザクションの結果に関する判断

CORBAオブジェクトは、トランザクション処理の2つの段階で、トランザクションの結果に関与することができます。

トランザクション・タイムアウト

トランザクションのタイムアウトが発生すると、トランザクションをロールバックすることが唯一の結果になるようにトランザクションにマークされ、CORBA::TRANSACTION_ROLLEDBACK標準例外がクライアントに返されます。新しいリクエストを送信しようとすると、トランザクションが中断されるまで、必ずCORBA::TRANSACTION_ROLLEDBACK例外となって失敗します。

IIOPクライアント・フェイルオーバー

サーバー・インスタンスでいつ障害が発生したのかを、その障害が発生したときに行われていた処理との関連で判断するのは必ずしも可能ではありません。たとえば、クライアント・リクエストを処理した後、レスポンスを返す前にサーバー・インスタンスに障害が発生した場合、リクエストが処理されたかどうかを判別することはできません。通常、レスポンスが返ってこなければ、ユーザーはリクエストを再試行します。

Oracle Tuxedo CORBAには、可用性の拡張を目的として、IIOPクライアント・フェイルオーバーのサポートが追加されました。IIOPクライアント・フェイルオーバーは、CORBAリモート・クライアントが自動的に代替ISLに接続し、障害時にリクエストを再試行するための透過的なメカニズムを提供します。

IIOPクライアント・フェイルオーバーでは、インタフェース実装をべき等元としてマークします。べき等元実装は、悪影響なしで反復できる実装です。たとえば、SET BALANCEです。

再試行ポリシーを設定する

インタフェース実装をべき等元としてマークするためには、実装構成ファイル(ICF)でretry_policyオプションを使用して再試行ポリシーを設定する必要があります。ICFの詳細は、「実装構成ファイル(ICF)」を参照してください。

retry_policyオプションには2種類の設定があります。

MIBのサポート

再試行ポリシーは、MIB(5) T_IFQUEUEおよびT_INTERFACEクラスに追加されたTA_RTPOLICY属性でチェックすることもできます。TA_RTPOLICY属性の値は、neverまたはalwaysです。

IIOPクライアント・フェイルオーバーを開始する

IIOPクライアント・フェイルオーバー・サポートを開始するには、UBBCONFIGファイルの*SERVERSセクションの-C warn|noneオプションを使用して、ISLサーバーを指定する必要があります

このオプションを使用すると、クライアントorbからISLへの非公式な直接接続が許可されます。-C warn|noneを使用して指定されていないISLサーバーは、候補IIOPのゲートウェイ・プールには配置されません。その結果、クライアントはこれらのISLサーバーにはフェイルオーバーしません。

リスト3-1に示すUBBCONFIGファイルの例では、1行目と2行目に指定されたISLサーバーでクライアント・フェイルオーバーがサポートされます。3行目のISLサーバーでは、クライアント・フェイルオーバーはサポートされません。

*SERVERS

	ISL SRVGRP=SYS_GRP1 SRVID=10 CLOPT="-A -- -C warn -n //myhost1:2468"

	ISL SRVGRP=SYS_GRP2 SRVID=20 CLOPT="-A -- -C none -n //myhost2:2469"

	ISL SRVGRP=SYS_GRP3 SRVID=30 CLOPT="-A -- -n //myhost3:2470"

IIOPクライアント・フェイルオーバーの制限事項

IIOPクライアント・フェイルオーバーは、以下の場合にはサポートされません。

関連項目

WebLogic CORBAでのクラスタリングとロード・バランシングのサポート

Tuxedo CORBA C++クライアントでは、WebLogicクラスタ・サーバーへのフェイルオーバーとロード・バランシングがサポートされています。詳細は、WebLogic 10.0マニュアルの「クラスタのフェイルオーバーとレプリケーション」および「クラスタでのロード・バランシング」を参照してください。

パラレル・オブジェクト

リリース8.0のOracle Tuxedo CORBAには、パフォーマンスの拡張を目的として並行オブジェクトのサポートが追加されています。並行オブジェクト機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトをステートレス・オブジェクトとして指定できます。1つのドメインの1つのサーバーでしか実行できない、ステートフル・ビジネス・オブジェクトと異なり、ステートレス・ビジネス・オブジェクトは1つのドメインのすべてのサーバーで実行できます。並行オブジェクトの利点は以下のとおりです。

並行オブジェクトの詳細は、『CORBAアプリケーションのスケーリング、分散およびチューニング』を参照してください。

並行オブジェクトを実装するために、同時実行性ポリシー・オプションがICFファイルに追加されています。特定のアプリケーションに対して並行オブジェクトを選択するには、同時実行性ポリシー・オプションをユーザー制御に設定します。ユーザー制御の同時実行性を選択すると、ビジネス・オブジェクトはアクティブ・オブジェクト・マップ(AOM)に登録されないので状態を持たなくなり、同時に複数のサーバー上でアクティブ化されることができます。このため、こうしたオブジェクトは「並行オブジェクト」と呼ばれます。

ユーザー制御の同時実行性を選択した場合、サーバントの実装は以下のいずれかの記述に該当しなければなりません。

リリース8.0のOracle Tuxedoソフトウェアでは、実装構成ファイル(ICF)が変更されてユーザー制御の同時実行性をサポートするようになりました。リスト3-2では、このサポートのための変更箇所が太字で強調されています。ICFの構文の説明については、「ICFの構文」を参照してください。

[#pragma activation_policy method|transaction|process]
[#pragma transaction_policy never|ignore|optional|always]
[#pragma concurrency_policy user_controlled|system_controlled]
[Module module-name {]
   implementation [implementation-name]
     {
     implements (module-name::interface-name);
     [activation_policy (method|transaction|process);]
     [transaction_policy (never|ignore|optional|always);]
     [concurrency_policy (user_controlled|system_controlled);]
     };
  [};]

ユーザー制御の同時実行性は、ファクトリ・ベース・ルーティング、すべてのアクティブ化ポリシー、およびすべてのトランザクション・ポリシーで使用できます。これらの機能との対話は次のとおりです。

TPフレームワークAPI

ここでは、TPフレームワークAPIについて説明します。このAPIの使用方法については、『CORBAサーバー・アプリケーションの作成』でも説明しています。

TPフレームワークは、次のコンポーネントから構成されます。

TPフレームワークの可視部分は、2種類のオペレーションで構成されています。

Serverインタフェース

Serverインタフェースには、アプリケーション固有のサーバー初期化および終了ロジック用のコールバック・メソッドが用意されています。このインタフェースには、オブジェクトをアクティブ化するためにサーバントが必要な場合に、サーバントを作成するためのコールバック・メソッドも用意されています。

Serverインタフェースには次の特徴があります。

Serverインタフェースのメソッドの説明については、「ServerBaseインタフェース」を参照してください。

C++宣言

C++マッピングについては、「ServerBaseインタフェース」を参照してください。

ServerBaseインタフェース

serverBaseインタフェースを使用すると、マルチスレッド処理機能の利点を最大限に活用できます。ServerBaseクラスを継承する独自のServerクラスを作成することもできます。このクラスでは以下のものが提供されます。

ServerBaseクラスでは、以前のリリースのServerクラスで利用可能だったオペレーションを使用できます。Serverクラスは、ServerBaseクラスを継承します。

これらのオペレーションは、シングル・スレッド・アプリケーションでもマルチスレッド・アプリケーションでも使用できます。

これらのメソッドは、マルチスレッド・サーバー・アプリケーションでのみ使用できます。

C++宣言(Server.h内)

C++のマッピングは次のとおりです。

class OBBEXPDLLUSER ServerBase {
public:

    virtual CORBA::Boolean
        initialize(int argc, char** argv) = 0;

    virtual void
        release() = 0;

    virtual Tobj_Servant
        create_servant(const char* interfaceName) = 0;

       // Default Implementations Supplied
       virtual Tobj_Servant
           create_servant_with_id(const char* interfaceName,
                                   const char* stroid);

       virtual CORBA::Boolean
           thread_initialize(int argc, char** argv);

       virtual void
           thread_release();

};

class Server : public ServerBase {
public:

    CORBA::Boolean initialize(int argc, char** argv);
    void release();
    Tobj_Servant create_servant(const char* interfaceName);
};

Server::create_servant()

概要

サーバントを作成してC++オブジェクトをインスタンス化します。

C++バインディング

class Server {
public:
      Tobj_Servant     create_servant(const char* interfaceName);
};

引数

interfaceName

例外

Server::create_servant()で例外がスローされた場合は、TPフレームワークがその例外を捕捉します。アクティブ化は失敗します。クライアントに対してCORBA::OBJECT_NOT_EXIST()例外が生成されます。また、エラー・メッセージが次のように例外型ごとにユーザー・ログ(ULOG)ファイルに書き込まれます。

TobjS::CreateServantFailed

TobjS::OutOfMemory

CORBA::Exception

その他の例外

説明

create_servantメソッドは、リクエストがサーバーに送信され、そのリクエストを満たすための利用可能なサーバントがない場合に、TPフレームワークによって呼び出されます。TPフレームワークは、作成するサーバントのインタフェース名を指定してcreate_servant メソッドを呼び出します。サーバー・アプリケーションでは、適切なC++オブジェクトをインスタンス化して、そのオブジェクトを指すポインタを返します。通常、このメソッドは、インタフェース名のswitch文を格納しており、インタフェース名に従って新しいオブジェクトを作成します。

戻り値

Tobj_Servant

ServerBase::create_servant_with_id()

概要

ターゲット・オブジェクト用のサーバントを作成します。このメソッドは、シングル・スレッドおよびマルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

Tobj_Servant create_servant_with_id (const char* interfaceName,
                                     const char* stroid);

引数

interfaceName

stroid

説明

TPフレームワークは、リクエストがサーバーに送信されたときに、そのリクエストを満たすための利用可能なサーバントがない場合にcreate_servant_with_idメソッドを呼び出します。TPフレームワークは、作成するサーバントのインタフェースとサーバントに関連付けられるオブジェクトのオブジェクトIDを渡します。サーバー・アプリケーションでは、適切なC++オブジェクトをインスタンス化して、そのオブジェクトを指すポインタを返します。通常、このメソッドは、インタフェース名のswitch文を格納しており、インタフェース名に従って新しいオブジェクトを作成します。オブジェクトIDを指定すると、サーバントの実装では、サーバント・インスタンスの作成時にターゲット・オブジェクトの情報を基に様々な決定を行えます。リエントラントのサポートは、サーバントの実装でターゲット・オブジェクトの情報を利用する方法の一例です。

ServerBaseクラスには、インタフェース名を渡す標準のcreate_servantメソッドを呼び出すcreate_servant_with_idのデフォルト実装が用意されています。このデフォルト実装では、ターゲット・オブジェクトIDパラメータは無視されます。

戻り値

Tobj_Servant

例

Tobj_Servant simple_per_request_server::create_servant_with_id(
const char* intf_repos_id, const char* stroid)
{
TP::userlog("create_servant_with_id called in thread %ld",
(unsigned long)SIMPTHR_GETCURRENTTHREADID);

//このオブジェクトIDに基づいて必要な初期化を
//実行する

return create_servant(intf_repos_id);
}

Server::initialize()

概要

アプリケーションが、データベースへのログイン、既知のオブジェクト・ファクトリの作成および登録、グローバル変数の初期化などのアプリケーション固有の初期化手続きを実行できるようにします。

C++バインディング

class Server {
public:

        CORBA::Boolean  initialize(int argc, char** argv);

};

引数

argcおよびargv引数がコマンドラインから渡されます。argc引数には、サーバー名が格納されます。argv引数には、アプリケーション固有の最初のコマンドライン・オプションが格納されます(存在する場合)。

コマンドライン・オプションは、SERVERSセクションにあるサーバーのエントリのCLOPTパラメータを使用して、UBBCONFIGファイルで指定します。CLOPTパラメータには、システムで認識されるオプション、ダブル・ハイフン(--)、アプリケーション固有のオプションの順に指定します。argcの値は、アプリケーション固有のオプションの数よりも1大きい値です。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「ubbconfig(5)」を参照してください。

例外

Server::initialize()で例外が発生すると、TPフレームワークがその例外を捕捉します。TPフレームワークは、initialize()がFALSEを返した場合と同じように動作します。つまり、例外は失敗と見なされます。また、エラー・メッセージが次のように例外型ごとにユーザー・ログ(ULOG)ファイルに書き込まれます。

TobjS::InitializeFailed

CORBA::Exception

その他の例外

説明

サーバー初期化の最後のステップとして呼び出されるinitializeコールバック・メソッドを使用すると、アプリケーションがアプリケーション固有の初期化を実行できます。

通常、サーバー・アプリケーションは、Server::initializeで以下のタスクを実行します。

サーバー・アプリケーションでは、必要なXAリソース・マネージャを開く必要があります。この処理には、以下のいずれかのメソッドを呼び出します。

戻り値

BooleanのTRUEまたはFALSE。TRUEは成功を示します。FALSEは失敗を示します。initialize()でエラーが発生した場合、アプリケーション・コードはFALSEを返します。アプリケーション・コードでは、システム・コールのexit()を呼び出してはなりません。exit()を呼び出すと、TPフレームワークが起動時に割り当てられたリソースを解放できないので、予期できない結果が発生する可能性があります。

戻り値がFALSEの場合は、次のように処理されます。

ServerBase::thread_initialize()

概要

Oracle Tuxedoソフトウェアを使用して作成されたスレッドに対して、必要なアプリケーション固有の初期化を実行します。このメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

CORBA::Boolean thread_initialize(int argc, char** argv)

引数

argc

argv

説明

スレッド・プールを管理する場合、Oracle Tuxedoソフトウェアでは、オペレーティング・システムのスレッド・ライブラリ・サービスを使用してスレッドを作成および解放します。アプリケーションの要件によっては、リクエストを処理する前にこれらのスレッドを初期化する必要があります。

thread_initializeコールバック・メソッドは、スレッドが作成されるたびに、スレッドの初期化を目的として呼び出されます。ただし、Oracle Tuxedoソフトウェアでは、リクエストをディスパッチするために多数のシステム所有スレッドを管理しています。これらのスレッドも、スレッド・プールに追加されます。状況によっては、ユーザーが実装したサーバントのメソッドもこれらのシステム所有スレッドで実行されます。このため、Oracle Tuxedoソフトウェアではthread_initializeメソッドを呼び出して、システム所有のスレッドが初期化されます。

ServerBaseクラスには、初期化されたスレッドでXAリソース・マネージャを開くthread_initializeメソッドのデフォルト実装が用意されています。

戻り値

CORBA::Boolean

例

CORBA::Boolean simple_per_request_server::thread_initialize(
int argc, char** argv)
{
TP::userlog("thread_initialize called in thread %ld",
(unsigned long)SIMPTHR_GETCURRENTTHREADID);
return CORBA_TRUE;
}

Server::release()

概要

アプリケーションが、データベースからのログオフ、既知のファクトリの登録の削除、リソースの割当て解除などのアプリケーション固有のクリーンアップを実行できるようにします。

C++バインディング

typedef Tobj_ServantBase* Tobj_Servant;

class Server {
public:
        void      release();
};

引数

なし。

例外

release()で例外が発生した場合は、TPフレームワークがその例外を捕捉します。各例外により、エラー・メッセージが次のようにユーザー・ログ(ULOG)ファイルに書き込まれます。

TobjS::ReleaseFailed

CORBA::Exception

その他の例外

いずれの場合でも、例外の発生に続いてサーバーが終了します。

説明

サーバー初期化の最初のステップとして呼び出されるreleaseコールバック・メソッドを使用すると、アプリケーションがアプリケーション固有のクリーンアップを実行できます。ユーザーは、仮想関数の定義をオーバーライドする必要があります。

通常、このメソッドでは以下の処理が実行されます。

このメソッドは、通常は管理者またはオペレータからのtmshutdownコマンドに対して呼び出されます。

TPフレームワークには、Server::release()のデフォルト実装が用意されています。デフォルト実装は、サーバー用のXAリソース・マネージャを閉じます。この処理は、UBBCONFIGファイルでサーバーのグループに対してデフォルトとして構成されているCLOSEINFOを使用するtx_close()呼出しによって行われます。

アプリケーションでは、開かれているXAリソース・マネージャを閉じる必要があります。この処理には、以下のいずれかのメソッドを呼び出します。

戻り値

なし。

ServerBase::thread_release()

概要

Oracle Tuxedoソフトウェアで作成されたスレッドが解放されたときに、アプリケーション固有のクリーンアップを実行します。このメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

void thread_release()

引数

なし。

説明

thread_releaseコールバック・メソッドは、スレッドが解放されるたびに呼び出されます。アプリケーション固有のリソース・クリーンアップを実行する場合は、thread_releaseを実装します。

ServerBaseクラスには、解放されたスレッドのXAリソース・マネージャを閉じるthread_releaseメソッドのデフォルト実装が用意されています。

戻り値

なし。

例

void simple_per_request_server::thread_release()
{
TP::userlog("thread_release called in thread %ld",
(unsigned long)SIMPTHR_GETCURRENTTHREADID);
}

Tobj_ServantBaseインタフェース

Tobj_ServantBaseインタフェースは、PortableServer::RefCountServantBaseクラスから継承され、CORBAオブジェクトがスレッドセーフ方式でその状態の管理を支援できるようにするオペレーションを定義します。IDLコンパイラによって生成されたすべての実装スケルトンは、Tobj_ServantBaseクラスを自動的に継承します。Tobj_ServantBaseクラスには、プログラマがオプションで実装できる2つの仮想メソッド(activate_object()およびdeactivate_object())が含まれます。

アクティブ化されたいないCORBAオブジェクトに対するリクエストが受信されるたびに、オブジェクトがアクティブ化され、activate_object()メソッドがサーバントに対して呼び出されます。CORBAオブジェクトが非アクティブ化されると、deactivate_object()メソッドがサーバントに対して呼び出されます。非アクティブ化のタイミングは、実装のアクティブ化ポリシーによって決まります。deactivate_object()メソッドが呼び出されると、TPフレームワークは呼出しの理由を示す理由コードを渡します。

これらのメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++宣言(Tobj_ServantBase.h内)

次に、Tobj_servantBaseインタフェースのC++マッピングを示します。

class Tobj_ServantBase : public PortableServer::RefCountServantBase {
public:

    Tobj_ServantBase& operator=(const Tobj_ServantBase&);
    Tobj_ServantBase() {}
    Tobj_ServantBase(const Tobj_ServantBase& s) :
        PortableServer::RefCountServantBase(s) {}

    virtual void activate_object(const char *) {}

    virtual void deactivate_object(const char*, 
        TobjS::DeactivateReasonValue) {}

    virtual CORBA::Boolean _is_reentrant() { return CORBA_FALSE; }
};

typedef Tobj_ServantBase * Tobj_Servant;

Tobj_ServantBase::activate_object()

概要

オブジェクトIDをサーバントに関連付けます。このメソッドによって、アプリケーションでは、オブジェクトがアクティブ化されたときにオブジェクトの状態を復元できます。状態は、共有メモリー、通常のフラット・ファイル、またはデータベース・ファイルから復元できます。

C++バインディング

class Tobj_ServantBase : public PortableServer::ServantBase {
public:	
        virtual void activate_object(const char * stroid) {}
};

引数

stroid

説明

オブジェクトのアクティブ化は、クライアントがアクティブ化されていないCORBAオブジェクトのメソッドを呼び出すことで開始されます。これにより、ポータブル・オブジェクト・アダプタ(POA)がサーバントをCORBAオブジェクトに割り当てます。activate_object()メソッドは、クライアントが呼び出したメソッドの前に呼び出されます。activate_object()から正常に制御が戻った場合、つまり例外が発生しなかった場合、リクエストされたメソッドがサーバントで実行されます。

プログラマは、activate_object()およびdeactivate_object()メソッドとクライアントが呼び出すメソッドを使用して、オブジェクトの状態を管理できます。これらのメソッドを使用してオブジェクトの状態を管理する方法は、アプリケーションのニーズによって異なります。これらのメソッドの使用方法は、「CORBAサーバー・アプリケーションの作成」を参照してください。

オブジェクトがグローバル・トランザクションに関与している場合、activate_object()はそのグローバル・トランザクションのスコープ内で実行されます。

オブジェクトのプログラマは、格納されているオブジェクトの状態が一貫性があるかどうかをチェックする必要があります。つまり、アプリケーション・コードでは、deactivate_object()がオブジェクトの状態を正しく保存したかどうかを示す永続性フラグを保存する必要があります。このフラグをactivate_object()でチェックします。

戻り値

なし。

例外

activate_object()の実行中にエラーが発生した場合、アプリケーション・コードでは、CORBA標準例外またはTobjS::ActivateObjectFailed例外を生成する必要があります。例外が発生すると、TPフレームワークは例外を捕捉して、以下のイベントが発生します。

TobjS::ActivateObjectFailed

TobjS::OutOfMemory

CORBA::Exception

その他の例外

Tobj_ServantBase::_add_ref()

概要

サーバントのリファレンスを追加します。このメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

void _add_ref()

引数

なし。

説明

このメソッドは、サーバントのリファレンスが必要な場合に呼び出します。このメソッドを呼び出すと、サーバントのリファレンス数が1つインクリメントされます。

戻り値

なし。

例

myServant * servant = new intf_i();
if(servant != NULL)
   servant->_add_ref();

Tobj_ServantBase::deactivate_object()

概要

オブジェクトIDとサーバントとの関連付けを削除します。このメソッドを使用すると、アプリケーションでは、オブジェクトが非アクティブ化される前にオブジェクトの状態のすべてまたは一部を保存できます。状態は、共有メモリー、通常のフラット・ファイル、またはデータベース・ファイルに保存できます。

C++バインディング

class Tobj_ServantBase : public PortableServer::ServantBase {
public:	
        virtual void deactivate_object(const char* stroid,
                       TobjS::DeactivateReasonValue  reason) {}
};

引数

stroid

reason

説明

オブジェクトの非アクティブ化は、CORBAオブジェクトの実装に設定されているアクティブ化ポリシーに従って、システムまたはアプリケーションによって開始されます。deactivate_object() メソッドは、CORBAオブジェクトが非アクティブ化される前に呼び出されます。これらのポリシーおよび使い方については、「ICFの構文」を参照してください。

CORBAオブジェクトの実装のアクティブ化ポリシーがmethodの場合にクライアントによって呼び出されるメソッド、またはアクティブ化ポリシーがtransactionの場合にトランザクションの処理が終わったときに呼び出されるメソッドの実行後に、非アクティブ化が発生する場合もあります。また、アクティブ化ポリシーがtransactionまたはprocessの場合、サーバー・シャットダウンの結果として発生することもあります。

さらに、Oracle Tuxedoソフトウェアでは、processまたはmethodが設定されたCORBAオブジェクトを、TP::deactivateEnable()およびTP::deactivateEnable(-,-,-)メソッドによってユーザー側で制御して非アクティブ化することができます。TP::deactivateEnableをオブジェクトのメソッド内で呼び出すと、メソッドの終了時にそのオブジェクトが非アクティブ化されます。transactionアクティブ化ポリシーが設定されたオブジェクトでTP::deactivateEnableを呼び出すと、例外(TobjS::IllegalOperation)が発生し、TPフレームワークは何の処理も行いません。processアクティブ化ポリシーが設定されたオブジェクトに対してTP::deactivateEnable(-,-,-)を呼び出すと、そのオブジェクトは非アクティブ化されます。詳細は、「TP::deactivateEnable()」を参照してください。

プログラマは、activate_object() およびdeactivate_object()メソッドとクライアントが明示的に呼び出すメソッドを使用して、オブジェクトの状態を管理できます。これらのメソッドを使用してオブジェクトの状態を管理する方法は、アプリケーションのニーズによって異なります。これらのメソッドの使用方法は、「CORBAサーバー・アプリケーションの作成」を参照してください。

transactionアクティブ化ポリシーが設定されたCORBAオブジェクトでは、DR_TRANS_COMMITTING理由コードでdeactivate_object()メソッドが呼び出されたときに、トランザクションの結果に関して判断できます。このメソッドは、Current.rollback_only()メソッドを呼び出すことで、トランザクションをロールバックさせることができます。そうでない場合は、2フェーズ・コミット・アルゴリズムが続行されます。トランザクションは、Current.rollback_only()がこのメソッドで呼び出されなかったという理由以外でもコミットされないことがあります。トランザクションに関与するその他のCORBAオブジェクトまたはリソース・マネージャも、トランザクションのロールバックを支持できます。

制約

このメソッドが呼び出されたときにオブジェクトがトランザクションに関与している場合、オブジェクトが呼び出された理由に基づいて、実行可能な処理が制約されます。オブジェクトがトランザクションに関与していた場合、アクティブ化ポリシーがtransactionで、呼出しのreasonコードは以下のいずれかです。

DR_TRANS_ABORTED

DR_TRANS_COMMITTING

こうした制約がある理由は、トランザクション・バウンドのアクティブ化ポリシーを設定されたオブジェクトの非アクティブ化が、トランザクションのトランザクション・マネージャからTPフレームワークに対する呼出しによって制御されるからです。reasonコードDR_TRANS_COMMITTINGで呼出しが行われた場合、トランザクション・マネージャは2フェーズ・コミットのフェーズ1 (準備)を実行しています。この段階では、トランザクションを一時停止する呼び出し、または新しいトランザクションを開始する呼出しを行うことはできません。別のプロセス内のCORBAオブジェクトを呼び出すにはそのプロセスがトランザクションに参加する必要があり、トランザクション・マネージャはすでに準備フェーズを実行しているので、この呼出しを行うとエラーが発生します¹。トランザクションに関与していないCORBAオブジェクトを呼び出すには、そのトランザクションを一時停止する必要があるので、これもエラーの原因となります。同じことはtpcall()にもあてはまります。

同じように、reasonコードDR_TRANS_ABORTEDでの呼出しが行われた場合、トランザクション・マネージャはすでに中断中です。トランザクション・マネージャが中断中の場合、トランザクションを一時停止したり、新しいトランザクションを開始したりすることはできません。この制約は、DR_TRANS_COMMITTINGに関しても適用されます。

戻り値

なし。

例外

クライアントによって呼び出されるCORBAオブジェクト・メソッドで例外が発生した場合、TPフレームワークが例外を捕捉して、最終的にクライアントに返します。これは、deactivate_object()を呼び出して例外が発生した場合にもあてはまります。

クライアントには、deactivate_object()で発生した例外について通知されません。アプリケーション・コードでは、格納されているCORBAオブジェクトの状態が一貫性があるかどうかをチェックする必要があります。たとえば、アプリケーション・コードで、deactivate_object()がオブジェクトの状態を正しく保存したかどうかを示す永続性フラグを保存すると便利です。このフラグをactivate_object()でチェックします。

deactivate_object()の実行中にエラーが発生した場合、アプリケーション・コードでは、CORBA標準例外またはDeactivateObjectFailed例外を生成する必要があります。deactivate_object()がTPフレームワークで呼び出されると、TPフレームワークは例外を捕捉して、次のイベントが発生します。

TobjS::DeactivateObjectFailed

CORBA::Exception

その他の例外

Tobj_ServantBase::_is_reentrant()

概要

オブジェクトが同時のリエントラント呼出しをサポートすることを示します。このメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

CORBA::Boolean _is_reentrant()

引数

なし。

説明

Oracle Tuxedoサーバー・インフラストラクチャでは、このメソッドを使用して、サーバント実装がリエントラント呼出しをサポートしているかどうかを判断します。リエントラントをサポートするには、複数のスレッドがオブジェクトと対話する場合に状態の整合性を保護するためのコードをサーバントに含める必要があります。

Tobj_ServantBaseクラスには、FALSEを返す_is_reentrantメソッドのデフォルト実装が用意されています。

戻り値

CORBA::Boolean

例

CORBA::Boolean Simple_i::_is_reentrant()
{ TP::userlog("_is_reentrant called in thread %ld",
(unsigned long)SIMPTHR_GETCURRENTTHREADID);
return CORBA_TRUE;
}

Tobj_ServantBase::_remove_ref()

概要

サーバントのリファレンスを解放します。このメソッドは、マルチスレッド・サーバー・アプリケーションの開発をサポートします。

C++バインディング

void _remove_ref()

パラメータ

なし。

説明

このメソッドは、サーバントのリファレンスが必要でなくなった場合に呼び出します。このメソッドを呼び出すと、サーバントのリファレンス数が1つ減ります。_remove_ref()メソッドによってリファレンス数がゼロになると、このメソッドは自身のthisポインタに対してC++の「delete」文を呼び出し、サーバントを「削除」します。

戻り値

なし。

例

if(servant != NULL)
   servant->_remove_ref();

TPインタフェース

TPインタフェースでは、アプリケーション・コードで呼び出せるサービス・メソッドのセットが提供されます。これは、アプリケーション・コードで安全に呼び出せるTPフレームワーク内の唯一のインタフェースです。その他のインタフェースは、システム・コードでのみ呼び出すことを目的としたコールバック・メソッドを持っています。

このインタフェースの目的は、ポータブル・オブジェクト・アダプタ(POA)、CORBAネーミング・サービス、およびOracle Tuxedoシステムで提供される基底のAPIに対する呼出しのかわりに、アプリケーション・コードで呼出し可能な高レベルの呼出しを行えるようにすることです。これらの呼出しにより、プログラマはより簡単なAPIを使用できるので、複雑な基底APIを使用せずに済みます。TPインタフェースでは、CORBA APIを拡張したOracle Tuxedoソフトウェアの以下の2つの機能を暗黙的に使用します。

FactoryFinderオブジェクトの詳細は、「FactoryFinderインタフェース」を参照してください。ファクトリ・ベース・ルーティングの詳細は、Oracle Tuxedoアプリケーションの設定を参照してください。

使用上の注意

C++宣言( TP.h内)

C++のマッピングは次のとおりです。

class TP {
public:
   static CORBA::Object_ptr  create_object_reference(
                                  const char*    interfaceName, 
                                  const char*   stroid,
                                  CORBA::NVList_ptr criteria);
   static CORBA::Object_ptr  create_active_object_reference(	
                                  const char*  interfaceName, 
                                  const char* stroid,
                                  Tobj_Servant servant);
   static CORBA::Object_ptr  get_object_reference();	
   static void               register_factory(
                                  CORBA::Object_ptr factory_or, 
                                  const char*       factory_id);
   static void               unregister_factory(
                                  CORBA::Object_ptr factory_or,
                                  const char*       factory_id);
   static void               deactivateEnable()
   static void               deactivateEnable(
                                  const char*  interfaceName,
                                  const char* stroid,
                                  Tobj_Servant servant);
   static CORBA::ORB_ptr     orb();
   static Tobj_Bootstrap*    bootstrap();
   static void               open_xa_rm();
   static void               close_xa_rm();
   static int                userlog(char*, ... );
   static char*                 get_object_id(CORBA::Object_ptr obj);
   static void               application_responsibility(
                                 Tobj_Servant servant);
};

TP::application_responsibility()

概要

アプリケーションがサーバントの存続期間に責任を持つことをTPフレームワークに伝えます。

C++バインディング

static void application_responsibility(Tobj_Servant servant);

引数

servant

例外

TobjS::InvalidServant

説明

このメソッドは、アプリケーションがサーバントの存続期間を制御することをTPフレームワークに通知します。このメソッドを呼び出すと、TPフレームワークがオブジェクトを非アクティブ化した後に、つまりサーバントのdeactivate_objectメソッドを呼び出した後に、オブジェクトに対して何の処理も行われません。

サーバントをアプリケーション側で処理する場合、その他のC++インスタンスと同じように、不要になった時点でサーバントを削除しなければなりません。

サーバントがTPフレームワークに認識されていない(アクティブ化されていない)場合、この呼出しは無効です。

戻り値

なし。

TP::bootstrap()

概要

Tobj::Tobj_Bootstrapオブジェクトに対するポインタを返します。Bootstrapオブジェクトは、FactoryFinderオブジェクト、インタフェース・リポジトリ、TransactionCurrentオブジェクト、およびSecurityCurrentオブジェクトへの初期リファレンスにアクセスする場合に使用します。

C++バインディング

static Tobj_Bootstrap* TP::bootstrap();

引数

なし。

戻り値

bootstrap()は、正常に終了すると、サーバー・アプリケーションの開始時にTPフレームワークで作成されたTobj::Tobj_Bootstrapオブジェクトに対するポインタを返します。

例外

なし。

説明

TPフレームワークでは、初期化の一部としてTobj::Tobj_Bootstrapオブジェクトが作成されます。したがって、アプリケーション・コードでほかのTobj::Tobj_Bootstrapオブジェクトをサーバー内に作成する必要はありません。

TP::close_xa_rm()

概要

呼出しプロセスのリンク先のXAリソース・マネージャを閉じます。

C++バインディング

static void TP::close_xa_rm ();

引数

なし。

説明

close_xa_rm()メソッドは、呼出しプロセスのリンク先のXAリソース・マネージャを閉じます。XAリソース・マネージャは、OracleやInformixなどのデータベース・ベンダーから提供されます。

このメソッドは、グローバル・トランザクションに関与する各サーバーに対してServer::release()メソッドから1回呼び出す必要があります。これには、XAリソース・マネージャにリンクされているサーバーと、グローバル・トランザクションに関与し、XA準拠リソース・マネージャに実際にはリンクされていないサーバーが含まれます。

close_xa_rm()メソッドは、リソース・マネージャに固有のクローズ呼出しのかわりに呼び出します。リソース・マネージャの初期化セマンティクスはそれぞれ異なるので、特定のリソース・マネージャを閉じるための情報を、Oracle TuxedoシステムのUBBCONFIGファイルのGROUPSセクションにあるCLOSEINFOパラメータに指定します。

CLOSEINFO文字列の形式は、基礎となるリソース・マネージャを提供しているデータベース・ベンダーの要件によって異なります。CLOSEINFOパラメータの詳細は、Oracle Tuxedoアプリケーションの設定と、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のubbconfig(5)のリファレンス・ページを参照してください。また、XAライブラリを使用するアプリケーションの開発およびインストール方法については、データベース・ベンダーのドキュメントを参照してください。

戻り値

なし。

例外

CORBA::BAD_INV_ORDER

Tobj::RMFailed

TP::create_active_object_reference()

概要

オブジェクト参照を作成し、オブジェクトを事前にアクティブ化します。

C++バインディング

static CORBA::Object_ptr
    create_active_object_reference(
           const char*       interfaceName, 
           const char*      stroid,
           Tobj_Servant     servant);

引数

interfaceName

stroid

servant

例外

TobjS::InvalidInterface

TobjS::InvalidObjectId

TobjS::ServantAlreadyActive

TobjS::ObjectAlreadyActive

TobjS::IllegalOperation

説明

このメソッドでは、オブジェクト参照を作成し、オブジェクトを事前アクティブ化します。作成されたオブジェクト参照は、オブジェクトへのアクセスで使用するクライアントに渡されます。

通常、アプリケーションではこのメソッドを以下の2か所で呼び出します。

このメソッドを使用すると、アプリケーションでは最初の呼出しの前にオブジェクトをアクティブ化できます。この処理が有用となる理由については、「明示的なアクティブ化」を参照してください。ユーザーはまずサーバントを作成し、状態を設定してから、create_active_object_referenceを呼び出します。TPフレームワークでは、サーバントおよびObjectId文字列をアクティブ・オブジェクト・マップに入れます。その結果、TPフレームワークですでにServer::create_servantを呼び出し、サーバント・ポインタを受け取ってから、servant::activate_objectを呼び出した場合とまったく同じ状態になります。

アクティブ化されたオブジェクトは、プロセス・バウンド・アクティブ化ポリシーで宣言されたインタフェース用でなければなりません。それ以外の場合、例外が発生します。

オブジェクトを非アクティブ化すると、クライアントで保持されていたオブジェクト参照を使用して、そのオブジェクトをほかのプロセスでアクティブ化することができます。この処理が問題となる状況については、「明示的なアクティブ化」を参照してください。

注意

インタフェースのオブジェクトを事前アクティブ化する場合、そのインタフェースのICFファイルでprocessアクティブ化ポリシーを指定する必要があります。ただし、ICFファイルのインタフェースについてprocessアクティブ化ポリシーを指定すると、次の問題が発生する可能性があります。

問題

回避策

この問題を防ぐには、管理者がSERVER1とSERVER2をそれぞれ別のグループとして構成します。グループを定義するには、UBBCONFIGファイルのSERVERSセクションを使用します。

戻り値

新しく作成されたオブジェクト参照。

TP::create_object_reference()

概要

オブジェクト参照を作成します。作成されたオブジェクト参照は、オブジェクトへのアクセスで使用するクライアントに渡されます。

C++バインディング

static CORBA::Object_ptr    TP::create_object_reference (
                               const char* interfaceName,
                               const char* stroid,
                               CORBA::NVList_ptr criteria);

引数

interfaceName

stroid

criteria

例外

create_object_reference()メソッドの例外は以下のとおりです。

InvalidInterface

InvalidObjectId

説明

create_object_reference() メソッドの呼出しは、サーバー・アプリケーションの役割です。このメソッドによって、オブジェクト参照が作成されます。作成されたオブジェクト参照は、オブジェクトへのアクセスで使用するクライアントに渡されます。

通常、サーバー・アプリケーションではこのメソッドを以下の2か所で呼び出します。

create_object_reference()メソッドの呼出し方法とタイミングの例については、『CORBAサーバー・アプリケーションの作成』を参照してください。

戻り値

Object

例

次のサンプル・コードは、criteria引数の使用方法を示しています。

CORBA::NVList_ptr criteria;
CORBA::Long branch_id = 7;
CORBA::Long account_id = 10001;
CORBA::Any any_val;

// Create the list and assign to _var to cleanup on exit
CORBA::ORB::create_list (2, criteria);
CORBA::NVList_var criteria_var(criteria);

// Add the BRANCH_ID
any_val <<= branch_id;
criteria->add_value("BRANCH_ID", any_val, 0);

// Add the ACCOUNT_ID
any_val <<= account_id;
criteria->add_value("ACCOUNT_ID", any_val, 0);

// Create the object reference.
TP::create_object_reference ("IDL:BankApp/Teller:1.0",
"Teller_01", criteria);

TP::deactivateEnable()

概要

CORBAオブジェクトのアプリケーション制御の非アクティブ化を有効にします。

C++バインディング

current-object形式

static void           TP::deactivateEnable();

any-object形式

static void        TP::deactivateEnable(
                           const char*  interfaceName,
                           const char* stroid,
                            Tobj_Servant servant);

引数

interfaceName

stroid

servant

例外

deactivateEnable()メソッドの例外は以下のとおりです。

IllegalOperation

TobjS::ObjectNotActive

説明

このオブジェクトを使用すると、同時実行されているオブジェクト(オブジェクトを呼び出したメソッドの終了時)、または別のオブジェクトを非アクティブ化できます。このメソッドは、プロセス・バウンド・アクティブ化ポリシーが設定されたオブジェクトに対してのみ使用できます。このメソッドにより、processアクティブ化ポリシーが設定されたオブジェクトをさらに柔軟に扱うことができます。

呼び出されるオーバーロード関数の種類によって、操作は次のようになります。

current-object形式

any-object形式

非アクティブ化をリクエストされたオブジェクトにtransactionアクティブ化ポリシーが設定されていた場合、IllegalOperation例外が発生します。これは、こうしたオブジェクトを非アクティブ化すると、Oracle Tuxedoトランザクション・マネージャからのトランザクション終了の通知と競合する場合があるからです。

戻り値

なし。

TP::get_object_id ()

概要

サーバーが、TPフレームワークで作成されたオブジェクト参照からObjectId文字列を取り出せるようにします。

C++バインディング

char* TP::get_object_id(Corba::Object_ptr obj);

引数

obj

ObjectIdを取り出すオブジェクト参照。

例外

TobjS::InvalidObject

説明

このメソッドを使用すると、サーバーが、TPフレームワークで作成されたオブジェクト参照からObjectId文字列を取り出せます。オブジェクト参照がクライアントORBなどによって作成され、TPフレームワークで作成されていない場合、例外が発生します。

呼出し側では、オブジェクト参照が不要になった場合に、戻り値に対してCORBA::string_freeを呼び出す必要があります。

戻り値

オブジェクト参照の作成時にTP::create_object_referenceまたはTP::create_active_object_referenceに渡されたObjectId文字列。

TP::get_object_reference()

概要

現在のオブジェクトへのポインタを返します。

C++バインディング

static CORBA::Object_ptr  TP::get_object_reference ();

引数

なし。

get_object_reference()がServer::initialize()またはServer::release()内から呼び出された場合、アプリケーションのTPオブジェクトの実行スコープ外で呼び出されたものと見なされるので、TobjS::NilObject例外が発生します。

例外

get_object_reference()メソッドの例外は次のとおりです。

NilObject

説明

このメソッドは、現在のオブジェクトへのポインタを返します。返されたCORBA::Object_ptrポインタは、クライアントに渡すことができます。

戻り値

CORBAオブジェクトの実行スコープ内で呼び出された場合、get_object_reference()メソッドは、現在のオブジェクトのCORBA::Object_ptrを返します。それ以外の場合、TobjS::NilObject例外が発生します。

TP::open_xa_rm()

概要

呼出しプロセスのリンク先のXAリソース・マネージャを開きます。

C++バインディング

static void TP::open_xa_rm();

引数

なし。

例外

Tobj::RMFailed

説明

open_xa_rm()メソッドは、呼出しプロセスのリンク先のXAリソース・マネージャを開きます。XAリソース・マネージャは、OracleやInformixなどのデータベース・ベンダーから提供されます。

グローバル・トランザクションに関与するサーバーごとにServer::initialize()メソッドから1回、このメソッドを呼び出す必要があります。グローバル・トランザクションに関与しているすべてのサーバーだけでなく、XAリソース・マネージャにリンクされたサーバーも含まれますが、XA準拠のリソース・マネージャに実際にはリンクされていません。

open_xa_rm()メソッドは、リソース・マネージャに固有のオープン呼出しのかわりに呼び出します。リソース・マネージャの初期化セマンティクスはそれぞれ異なるので、特定のリソース・マネージャを開くための情報を、UBBCONFIGファイルのGROUPSセクションにあるOPENINFOパラメータに指定します。

OPENINFO文字列の形式は、基礎となるリソース・マネージャを提供しているデータベース・ベンダーの要件によって異なります。CLOSEINFOパラメータの詳細は、Oracle Tuxedoアプリケーションの設定と、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のubbconfig(5)のリファレンス・ページを参照してください。また、XAライブラリを使用するアプリケーションの開発およびインストール方法については、データベース・ベンダーのドキュメントを参照してください。

戻り値

なし。

TP::orb()

概要

ORBオブジェクトに対するポインタを返します。

C++バインディング

static CORBA::ORB_ptr TP::orb();

引数

なし。

例外

なし。

説明

ORBオブジェクトにアクセスすると、アプリケーションでは、string_to_object()やobject_to_string()などのORBオペレーションを呼び出すことができます。

戻り値

orb()は、正常に終了すると、サーバー・プログラムの開始時にTPフレームワークで作成されたORBオブジェクトに対するポインタを返します。

TP::register_factory()

概要

Oracle Tuxedo FactoryFinderオブジェクトを見つけて、Oracle Tuxedoファクトリを登録します。

C++バインディング

static void TP::register_factory(
              CORBA::Object_ptr factory_or, const char* factory_id);

引数

factory_or

factory_id

例外

register_factory()メソッドの例外は以下のとおりです。

TobjS::CannotProceed

TobjS::InvalidName

TobjS::InvalidObject

TobjS::RegistrarNotAvailable

TobjS::OverFlow

説明

このメソッドでは、Oracle Tuxedo FactoryFinderオブジェクトを見つけて、Oracle Tuxedoファクトリに登録します。通常、TP::register_factory()は、サーバーがファクトリを作成するときに、Server::initialize()から呼び出します。register_factory()メソッドでは、Oracle Tuxedo FactoryFinderオブジェクトを見つけて、Oracle Tuxedoファクトリに登録します。

戻り値

なし。

TP::unregister_factory()

概要

Oracle Tuxedo FactoryFinderオブジェクトを見つけて、ファクトリを削除します。

C++バインディング

static void TP::unregister_factory (
               CORBA::Object_ptr factory_or, const char* factory_id);

引数

factory_or

factory_id

例外

unregister_factory()メソッドの例外は以下のとおりです。

CannotProceed

InvalidName

RegistrarNotAvailable

TobjS::OverFlow

説明

このメソッドは、Oracle Tuxedo FactoryFinderオブジェクトを探し、ファクトリを削除します。通常、TP::unregister_factory()はサーバー・ファクトリを登録解除するためにServer::release()から呼び出されます。

戻り値

なし。

TP::userlog()

概要

ユーザー・ログ(ULOG)ファイルにメッセージを書き込みます。

C++バインディング

static int    TP::userlog(char*, ...);

引数

最初の引数では、printf(3S)スタイルの形式を指定します。printf(3S)引数については、CまたはC++リファレンス・マニュアルで説明されています。

例外

なし。

説明

userlog()メソッドは、ユーザー・ログ(ULOG)ファイルにメッセージを書き込みます。メッセージは、時刻(hhmmss)、システム名、プロセス名、および呼出しプロセスのプロセスIDで構成されるタグを付けて、ULOGファイルに追加されます。タグの最後にはコロンが付けられます。

サーバー・アプリケーションでは、userlog()によるメッセージをアプリケーション・エラーのデバッグで有用となるメッセージに限定することをお薦めします。ULOGが重要度の低いメッセージでいっぱいになると、実際のエラーの特定が難しくなります。

戻り値

userlog()メソッドは、出力された文字数を返し、出力エラーが発生した場合には、負の値を返します。出力エラーには、現在のログ・ファイルのオープン・エラーや書込みエラーがあります。

例

次のサンプル・コードは、TP::userlog()メソッドの使用方法を示しています。

userlog (“System exception caught: %s", e.get_id());

CosTransactions::TransactionalObjectインタフェース(任意)

このインタフェースの使用は非推奨になりました。このインタフェースの使用は任意となったので、トランザクションに関与するオブジェクトに対して、このインタフェースの下位インタフェースを使用する必要はありません。プログラマは、neverまたはignoreトランザクション・ポリシーを指定して、オブジェクトがトランザクションに関与しないように指定できます。トランザクションの処理にインタフェースを使用する必要はありません。指定するのはトランザクション・ポリシーだけです。

エラー、例外、およびエラー・メッセージ

TPフレームワークで生成される例外

TPフレームワークでは以下の例外が発生します。発生した例外は、エラーが発生したクライアントに返されるか、TPで検出されます。

CORBA::INTERNAL
CORBA::OBJECT_NOT_EXIST
CORBA::OBJ_ADAPTER
CORBA::INVALID_TRANSACTION
CORBA::TRANSACTION_ROLLEDBACK

これらの例外の理由は明確ではないので、TPフレームワークでは、例外が発生するたびに、理由を示すエラー・メッセージがユーザー・ログ・ファイルに書き込まれます。

サーバー・アプリケーション・コード内の例外

クライアントによって呼び出されたメソッド内で発生した例外は、クライアントによって呼び出されたメソッドで発生した例外と同じように、クライアントに返されます。

TPフレームワークの以下のコールバック・メソッドは、オブジェクトに対するクライアントのリクエスト以外のイベントによって開始されます。

Tobj_ServantBase::activate_object()
Tobj_ServantBase::deactivate_object()
Server::create_servant()

これらのメソッドで例外が発生した場合、まったく同じ例外がクライアントに通知されるわけではありません。ただし、これらの各メソッドは、reason文字列を含む例外を生成するように定義されています。TPフレームワークでは、コールバックによって生成された例外が捕捉され、reason文字列がユーザー・ログ・ファイルに書き込まれます。TPフレームワークでは、クライアントに例外を返すこともできます。これらの例外の詳細は、TPフレームワークの各コールバック・メソッドの説明を参照してください。

例

Tobj_ServantBase::deactivate_object()の場合、次のコードはDeactivateObjectFailed例外をスローします。

throw TobjS::DeactivateObjectFailed( “deactivate failed to save
                                       state!”);

このメッセージは、時刻(hhmmss)、システム名、プロセス名、および呼出しプロセスのプロセスIDで構成されるタグを付けて、ユーザー・ログ・ファイルに追加されます。タグの最後にはコロンが付けられます。上記のthrow文によって、次の行がユーザー・ログ・ファイルに書き込まれます。

151104.T1!simpapps.247: APPEXC: deactivate failed to save state!

151104は時刻(3:11:04pm)、T1はシステム名、simpappsはプロセス名、247はプロセスIDをそれぞれ示し、APPEXCはメッセージがアプリケーション例外メッセージであることを示します。

例外とトランザクション

CORBAオブジェクト・メソッドまたはTPフレームワークのコールバック・メソッドで例外が発生しても、TPフレームワークがトランザクションを開始していないかぎり、トランザクションは自動的にはロールバックされません。例外が発生した条件に基づいてトランザクションをロールバックする場合は、アプリケーション・コードでCurrent.rollback_only()を呼び出す必要があります。

CORBAオブジェクトに対するネストされた呼出しに関する制約

TPフレームワークには、CORBAオブジェクトに対するネストされた呼出しに関して制約があります。制約の内容は次のとおりです。

TPフレームワークでは、別のCORBAオブジェクトがすでにメソッド呼出しを処理しているオブジェクトのクライアントとして機能していることを検出すると、呼出し側にCORBA::OBJ_ADAPTER 例外を返します。

¹理論上は、同じプロセスのトランザクションCORBAオブジェクトに対する呼出しは、新しいプロセスをトランザクション・マネージャに登録する必要がないため、有効となります。ただし、CORBAオブジェクトに対する呼出しがプロセスで発生するようにプログラミングすることはできないため、このような処理は行わないでください。