TP フレームワーク

ドキュメントのダウンロード

サイトマップ

用語集

検索

e-docs > Tuxedo > Tuxedo CORBA プログラミング・リファレンス > TP フレームワーク

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

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

ObjectId を文字列形式で指定します。ObjectId は、クラスのこのインスタンスを一意に識別します。プログラマは、ObjectId に指定する情報を決めます。一例として、データベース・キーの保持に使用する方法があります。オブジェクト識別子の値を選択、つまり一意性のレベルを決定することは、アプリケーション・デザインの一環です。BEA Tuxedo ソフトウェアでは、オブジェクト・リファレンスの一意性は保証されません。オブジェクト・リファレンスを文字列化する場合など、オブジェクト・リファレンスをコピーしたり、BEA Tuxedo 環境の外で共有したりすることがあるからです。

サーバント

アプリケーションで既に作成して初期化したサーバントに対するポインタです。

例外

TobjS::InvalidInterface

指定された interfaceName が NULL であることを示します。

TobjS::InvalidObjectId

指定された stroid が NULL であることを示します。

TobjS::ServantAlreadyActive

サーバントは別の ObjectId で使用されているので、オブジェクトを明示的に活性化することができませんでした。サーバントは、1 つの ObjectId でのみ使用できます。異なる ObjectId を持つオブジェクトを事前活性化するには、アプリケーションで複数のサーバントを作成し、ObjectId ごとに個別に事前活性化する必要があります。

TobjS::ObjectAlreadyActive

ObjectId が既にアクティブ・オブジェクト・マップで使用されているので、オブジェクトを明示的に活性化することができませんでした。ある特定の ObjectId には、1 つのサーバントしか関連付けられません。別のサーバントに変更するには、アプリケーションでまずオブジェクトを事前活性化してからもう一度活性化する必要があります。

TobjS::IllegalOperation

オブジェクトにプロセス・バウンド活性化方針が設定されていないので、オブジェクトを明示的に活性化することができませんでした。

説明

このメソッドでは、オブジェクト・リファレンスを作成し、オブジェクトを事前活性化します。作成されたオブジェクト・リファレンスは、オブジェクトへのアクセスで使用するクライアントに渡されます。

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

Server::initialize() 内。最初の呼び出しで活性化しなくて済むように、プロセス・オブジェクトを事前活性化します。
クライアントに返すオブジェクト・リファレンスを作成するすべてのメソッド内。

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

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

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

注記ユーザ制御の同時実行方針オプションが ICF ファイルで設定されている場合、このメソッドに関する制約が 1 つあります (「パラレル・オブジェクト」を参照してください)。TP::create_active_object_reference メソッドは、ユーザ制御の同時実行が設定されたインターフェイスを渡されると、TobjS::IllegalOperation 例外をスローします。AOM はユーザ制御の同時実行が設定されている場合に使用されないので、TP フレームワークには活性化されたオブジェクトをこのサーバに接続する方法がありません。

注意

インターフェイスのオブジェクトを事前活性化する場合、そのインターフェイスの ICF ファイルで process 活性化方針を指定する必要があります。ただし、ICF ファイルで process 活性化方針を指定すると、次の問題が発生する可能性があります。

問題

インターフェイス A のすべてのオブジェクトが事前活性化されるように、SERVER1 を記述します。オブジェクトが TP フレームワークによってオンデマンドで活性化されないようにするために、インターフェイスの activate_object メソッドを記述して、ActivateObjectFailed 例外がスローされるようにします。
SERVER2 もインターフェイス A のオブジェクトを実装します。ただし、SERVER2 では、オブジェクトを事前活性化する代わりに、TP フレームワークでオンデマンド方式でオブジェクトを活性化させます。
管理者は SERVER1 と SERVER2 を同じグループとしてコンフィギュレーションした場合、クライアントでは、SERVER2 からインターフェイス A のオブジェクト・リファレンスを取得して、オブジェクトを呼び出すことができます。ロード・バランシングにより、インターフェイス A のオブジェクトの活性化が SERVER1 に委任されまが、activate_object メソッドが ActivateObjectFailed 例外をスローするため、SERVER1 ではインターフェイス A のオブジェクトを活性化できません。

対策

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

戻り値

新しく作成されたオブジェクト・リファレンス。