|
•
|
状態管理。この項では、次の内容について説明します。
|
|
•
|
method (これはデフォルトのアクティブ化ポリシーです。)
|
transactionアクティブ化ポリシーでは、2フェーズ・コミット・アルゴリズムを実行する前に、オブジェクトがトランザクションの結果に関して支持するかどうかを判断できます。オブジェクトがトランザクションのロールバックを支持する場合は、
Tobj_ServantBase::deactivate_objectメソッドの
Current.rollback_only()を呼び出します。トランザクションのコミットを支持する場合は、
Current.rollback_only()を呼び出しません。
アプリケーション・コードでは、processアクティブ化ポリシーを使用するオブジェクトに関して、TPフレームワークのオン・デマンド・アクティブ化機能を無効にすることができます。アプリケーションでは、
TP::create_active_object_reference呼出しを使用して、オブジェクトを「事前アクティブ化」、つまり呼出しの前にアクティブ化することができます。
事前アクティブ化のしくみは次のとおりです。アプリケーションは、オブジェクト参照を作成する前に、サーバントをインスタンス化して、その状態を初期化します。アプリケーションはTP::create_active_object_referenceを使用して、オブジェクトをアクティブ・オブジェクト・マップに追加、つまりサーバントと
ObjectIdを関連付けます。最初の呼出しが行われると、TPフレームワークが、オブジェクト参照を作成したプロセスに直ちにリクエストを転送してから、既存のサーバントに転送します。この際、オブジェクトに対する2番目以降の呼出しと同じように、
Server::create_servantに次いでサーバントの
activate_objectメソッドを呼び出す必要はありません。こうしたオブジェクトのオブジェクト参照は別のサーバーを指さないので、アクティブ化されている限り、オブジェクトがオン・デマンドでアクティブ化されることはありません。
事前アクティブ化されたオブジェクトにはprocessアクティブ化ポリシーが設定されているため、(1)プロセスの終了または(2)
TP::deactivateEnable呼出しのいずれかのイベントが発生するまで、オブジェクトはアクティブ化されたままとなります。
初期オブジェクトは、TP::create_active_object_referenceを使用してこのイテレータ・オブジェクトを事前にアクティブ化します。また、そのオブジェクトへのオブジェクト参照を作成してクライアントに戻します。クライアントは、イテレータ・オブジェクトを繰り返し呼び出して、たとえば毎回リスト内の次の100項目を受信します。この状況での事前アクティブ化の利点は、状態を複雑化できることです。多くの場合、初期オブジェクトに制御があるときに、そのコンテキスト(呼出しフレーム)にすべての情報を含むメソッドからこのような状態を最初に設定することが最も簡単です。
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には、オブジェクトが直ちに非アクティブ化されたかどうか通知されません。
|
注意:
|
TP::deactivateEnable(interface, object id, servant)メソッドを使用すると、オブジェクトを非アクティブ化できます。ただし、オブジェクトがトランザクションに参加している場合、オブジェクトが非アクティブ化されるのは、トランザクションがコミットまたはロールバックしたときです。トランザクションがコミットまたはロールバックする前にオブジェクトに対して呼出しが行われた場合、オブジェクトは非アクティブ化されません。
|
CORBAオブジェクトがアクティブ化されている間、オブジェクトの状態はサーバント内に格納されます。TP::create_active_object_referenceを使用するアプリケーションとは異なり、状態は、オブジェクトが最初に呼び出されたとき、つまりオブジェクト参照の作成後にCORBAオブジェクトに対してメソッドが最初に呼び出されたときと、オブジェクトが非アクティブ化されて以降の呼出しで初期化する必要があります。CORBAオブジェクトが非アクティブ化されている間、オブジェクトの状態をサーバントがアクティブ化されていたプロセスの外部に保存する必要があります。オブジェクトの状態は、共有メモリー、ファイル、データベースなどに保存できます。CORBAオブジェクトを非アクティブ化する前に、オブジェクトの状態を保存して、オブジェクトがアクティブ化されたときに状態を復元する必要があります。
|
•
|
optional (これはデフォルトの transaction_policyです。)
|
|
注意:
|
optionalポリシーは、管理構成によって影響を受ける唯一のトランザクション・ポリシーです。システム管理者が UBBCONFIGファイルまたは管理ツールを使用して、 AUTOTRAN属性をインタフェースに対して設定すると、既にトランザクションに関与している場合を除いて、オブジェクトの呼出し時にトランザクションが自動的に開始されます。つまり、 alwaysポリシーを指定した場合と同じ動作になります。
|
|
•
|
CosTransactions::Current::begin()操作を使用した、アプリケーション・コードによる方法。この処理は、クライアントでもサーバーでも行うことができます。この操作の説明については、 『CORBAトランザクションの使用』を参照してください。
|
詳細は、『CORBAトランザクションの使用』を参照してください。
|
•
|
エラー処理: 不当な動作が発生した場合、TPフレームワークによって CORBA::TRANSACTION_ROLLEDBACK例外がクライアント・アプリケーションに対して生成され、トランザクションはOracle Tuxedoシステムによってロールバックされます。
|
|
•
|
不当なサーバーの動作: 一時停止状態のトランザクションに関与したメソッドから復帰します(つまり、一時停止が呼び出された場合、再開を呼び出さずにメソッドから復帰します)。
|
|
•
|
エラー処理: 不当な動作が発生した場合、TPフレームワークによって CORBA::OBJ_ADAPTER例外がクライアントに対して生成され、トランザクションはロールバックされます。 CORBA::OBJ_ADAPTER例外は、クライアント・アプリケーションがトランザクションを初期化していないために発生します。したがって、クライアント・アプリケーションでは、トランザクション・エラーが発生することを予想していません。
|
|
•
|
不当なサーバーの動作: トランザクションを開始して、トランザクションがアクティブな状態でメソッドから復帰します。
|
|
•
|
エラー処理: 不当な動作が発生した場合、TPフレームワークによって CORBA::OBJ_ADAPTER例外がクライアント・アプリケーションに対して生成され、トランザクションはOracle Tuxedoシステムによってロールバックされます。 CORBA::OBJ_ADAPTER例外は、クライアント・アプリケーションがトランザクションを初期化していないために発生します。したがって、クライアント・アプリケーションでは、トランザクション・エラーが発生することを予想していません。
|
|
•
|
アプリケーションは、Server::initialize()でトランザクションを開始した場合、メソッドから復帰する前にトランザクションをコミットまたはロールバックする必要があります。アプリケーションがトランザクションを開始していない場合、TPフレームワークはサーバーを停止します。この理由は、 Server::initializeメソッドの終了後に制御をアプリケーションに戻す予測可能な方法がないからです。
|
|
•
|
CORBAオブジェクトがトランザクションに関与しており、transactionアクティブ化ポリシーが設定されている場合、かつメソッドに渡された理由コードが DR_TRANS_COMMITTINGまたは DR_TRANS_ABORTEDの場合、 Tobj_ServantBase::deactivate_objectメソッドからはどのCORBAオブジェクトに対しても呼出しは行われません。こうした呼出しに対しては、 CORBA::BAD_INV_ORDER例外が生成されます。
|
|
•
|
SQL COMMITおよびROLLBACK文を使用して、Current.begin()を明示的に使用して開始されたグローバル・トランザクションやシステムによって暗黙的に開始されたグローバル・トランザクションを終了することはできません。各データベース製品でグローバル・トランザクションを使用する場合のその他の制約については、データベース・ベンダーのマニュアルで確認してください。
|
Current.rollback_onlyメソッドを使用すると、現在のトランザクションをロールバックすることが唯一の結果になることが保証されます。
Current.rollback_only()は、どのCORBAオブジェクト・メソッドからも呼び出せます。
ただしこの動作は、processまたは
methodアクティブ化ポリシーが設定されたオブジェクトには適用されません。CORBAオブジェクトがトランザクションをロールバックする場合、CORBAオブジェクトは
Current::rollback_onlyを呼び出します。トランザクションをコミットすることを支持する場合、その呼出しを行いません。ただし、コミットすることを支持してもトランザクションが実際にコミットされるとは限りません。その後、ほかのオブジェクトがトランザクションをロールバックすることを支持する可能性があるからです。
|
注意:
|
SQLカーソルのユーザーは、methodまたは processアクティブ化ポリシーを持つオブジェクトを使用する場合には注意する必要があります。プロセスは、クライアントが開始したトランザクション内にSQLカーソルをオープンします。通常のSQLデータベース製品では、クライアントがトランザクションをコミットすると、そのトランザクション内でオープンされたすべてのカーソルが自動的にクローズされますが、オブジェクトはそのカーソルがクローズされたことを示す通知を受け取りません。
|
retry_policyオプションには2種類の設定があります。
|
•
|
never: デフォルト設定です。インタフェース実装がべき等元ではなく、リクエストは自動的には再試行されません。
|
|
•
|
always: インタフェース実装がべき等で、障害発生時には常にリクエストが再試行されます。
|
リスト3-1に示す次の
UBBCONFIGファイルの例では、1行目と2行目に指定されたISLサーバーでクライアント・フェイルオーバーがサポートされます。3行目のISLサーバーでは、クライアント・フェイルオーバーはサポートされません。
|
•
|
Tuxedoシステムが提供するオブジェクト・フェイルオーバーの場合 アプリケーションが提供するオブジェクト・フェイルオーバーのみサポートされます。
|
[#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);]
};
[};]
|
注意:
|
ユーザー制御の同時実行性について、1つ制約があります。TP::create_active_object_referenceは、ユーザー制御の同時実行性が設定されたインタフェースを渡されると、 TobjS::IllegalOperation例外をスローします。AOMはユーザー制御の同時実行性が設定されている場合に使用されないので、TPフレームワークにはアクティブ化されたオブジェクトをこのサーバーに接続する方法がありません。
|
|
•
|
Server C++クラス。アプリケーション固有のサーバー初期化および終了ロジック用の仮想メソッドを持っています
|
|
•
|
ServerBase C++クラス。マルチスレッド・サーバー・アプリケーション用の仮想メソッドを持っています。
|
|
•
|
Tobj_ServantBase C++クラス。オブジェクトの状態管理用の仮想メソッドを持っています
|
|
•
|
TP C++クラス。次の処理を実行するためのメソッドを用意しています。
|
|
•
|
ユーザーが記述し、TPフレームワークで呼び出すコールバック・メソッド。Tobj_ServantBaseおよび Serverクラスのメソッドも含まれます。これらの操作は、TPフレームワークのコードでのみ呼び出すためのものです。アプリケーション・コードでは、これらのクラスのメソッドを呼び出してはなりません。呼び出した場合、予期できない結果となる可能性があります。
|
|
•
|
ServerクラスはC++ネイティブ・クラスです。
|
|
•
|
Server.hファイルには、Serverクラスの宣言および定義が格納されています。
|
ServerBaseクラスでは、以前のリリースの
Serverクラスに含まれていた操作を使用できます。Serverクラスは、ServerBaseクラスを継承します。
|
•
|
ServerBase::thread_release()
|
オブジェクトの完全修飾インタフェース名を含む文字列を指定します。この名前は、TP::create_object_reference()を使用してオブジェクト参照を作成した場合に指定したインタフェース名、または
TP::create_active_object_reference()の呼出しで使用したオブジェクト参照のインタフェース名と同じになります。この名前を使用して、作成する必要があるサーバントを決定できます。
Server::create_servant()で例外がスローされた場合は、TPフレームワークがその例外を捕捉します。アクティブ化は失敗します。クライアントに対して
CORBA::OBJECT_NOT_EXIST()例外が生成されます。また、エラー・メッセージが次のように例外型ごとにユーザー・ログ(
ULOG)ファイルに書き込まれます。
reasonはユーザー指定の理由を示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
reasonはユーザー指定の理由を示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
create_servantメソッドは、リクエストがサーバーに到着し、そのリクエストを満たすために使用できるサーバントがない場合に、TPフレームワークによって呼び出されます。TPフレームワークは、作成するサーバントのインタフェース名を指定して
create_servant メソッドを呼び出します。サーバー・アプリケーションでは、適切なC++オブジェクトをインスタンス化して、そのオブジェクトを指すポインタを返します。通常、このメソッドは、インタフェース名のswitch文を格納しており、インタフェース名に従って新しいオブジェクトを作成します。
create_servantメソッドがNULLポインタを返した場合、アクティブ化は失敗します。
CORBA::OBJECT_NOT_EXIST()例外がクライアントに返されます。また、次のメッセージがユーザー・ログ(
ULOG)に書き込まれます。
ここで、interfaceNameは呼び出したインタフェースのインタフェースID、
oidは対応するオブジェクトIDです。
Tobj_Servant create_servant_with_id (const char*
interfaceName,
const char*
stroid);
TPフレームワークは、リクエストがサーバーに到着し、そのリクエストを満たすために使用できるサーバントがない場合にcreate_servant_with_idメソッドを呼び出します。TPフレームワークは、作成するサーバントのインタフェースとサーバントに関連付けられるオブジェクトのオブジェクトIDを渡します。サーバー・アプリケーションでは、適切なC++オブジェクトをインスタンス化して、そのオブジェクトを指すポインタを返します。通常、このメソッドは、インタフェース名の
switch文を格納しており、インタフェース名に従って新しいオブジェクトを作成します。オブジェクトIDを指定すると、サーバントの実装では、サーバント・インスタンスの作成時にターゲット・オブジェクトの情報を基に様々な決定を行えます。リエントラントのサポートは、サーバントの実装でターゲット・オブジェクトの情報を利用する方法の一例です。
ServerBaseクラスには、インタフェース名を渡す標準の
create_servantメソッドを呼び出す
create_servant_with_idのデフォルト実装が用意されています。このデフォルト実装では、ターゲット・オブジェクトIDパラメータは無視されます。
argcおよび
argv引数がコマンド行から渡されます。
argc引数には、サーバー名が格納されます。
argv引数には、アプリケーション固有の最初のコマンド行オプションが格納されます(存在する場合)。
Server::initialize()で例外が発生すると、TPフレームワークがその例外を捕捉します。TPフレームワークは、
initialize()がFALSEを返した場合と同じように動作します。つまり、例外は失敗と見なされます。また、エラー・メッセージが次のように例外型ごとにユーザー・ログ(
ULOG)ファイルに書き込まれます。
reasonは、アプリケーション・コードで指定される文字列です。例:
exceptionは、発生したCORBA例外のインタフェースIDです。
BooleanのTRUEまたは
FALSE。
TRUEは成功を示します。
FALSEは失敗を示します。
initialize()でエラーが発生した場合、アプリケーション・コードは
FALSEを返します。アプリケーション・コードでは、システム・コールの
exit()を呼び出してはなりません。
exit()を呼び出すと、TPフレームワークが起動時に割り当てられたリソースを解放できないので、予期できない結果が発生する可能性があります。
戻り値がFALSEの場合は、次のように処理されます。
|
•
|
initialize()メソッドで開始され、終了されていないトランザクションは、最終的にタイムアウトします。自動的にロールバックされるわけではありません。
|
CORBA::Boolean thread_initialize(int argc, char** argv)
thread_initializeコールバック・メソッドは、スレッドが作成されるたびに、スレッドの初期化を目的として呼び出されます。ただし、Oracle Tuxedoソフトウェアでは、リクエストをディスパッチするために多数のシステム所有スレッドを管理しています。これらのスレッドも、スレッド・プールに追加されます。状況によっては、ユーザーが実装したサーバントのメソッドもこれらのシステム所有スレッドで実行されます。このため、Oracle Tuxedoソフトウェアでは
thread_initializeメソッドを呼び出して、システム所有のスレッドが初期化されます。
ServerBaseクラスには、初期化されたスレッドでXAリソース・マネージャを開く
thread_initializeメソッドのデフォルト実装が用意されています。
release()で例外が発生した場合は、TPフレームワークがその例外を捕捉します。各例外により、エラー・メッセージが次のようにユーザー・ログ(
ULOG)ファイルに書き込まれます。
reasonは、アプリケーション・コードで指定される文字列です。例:
exceptionは、発生したCORBA例外のインタフェースIDです。
|
•
|
Server::initialize()でFactoryFinderに登録されたCORBAオブジェクト・ファクトリの登録の削除。
|
TPフレームワークには、Server::release()のデフォルト実装が用意されています。デフォルト実装は、サーバー用のXAリソース・マネージャを閉じます。この処理は、
UBBCONFIGファイルでサーバーのグループに対してデフォルトとして構成されている
CLOSEINFOを使用する
tx_close()呼出しによって行われます。
|
注意:
|
サーバーがtmshutdown(1)コマンドから停止リクエストを受信すると、他のリモート・オブジェクトからのリクエストを受信できなくなります。サーバーを停止する場合、順序を考慮しなければならないことがあります。たとえば、サーバー1の Server::release()メソッドからサーバー2にあるオブジェクトのメソッドにアクセスする必要がある場合、サーバー1を停止してから、サーバー2を停止しなければなりません。特に、 TP::unregister_factory()メソッドは、別のサーバーにあるFactoryFinder Registrarオブジェクトにアクセスします。通常、 TP::unregister_factory()メソッドは release()メソッドから呼び出されるので、FactoryFinderサーバーは、 Server::release()メソッドで TP::unregister_factory()を呼び出すすべてのサーバーの後に停止する必要があります。
|
thread_releaseコールバック・メソッドは、スレッドが解放されるたびに呼び出されます。アプリケーション固有のリソース・クリーンアップを実行する場合は、
thread_releaseを実装します。
ServerBaseクラスには、解放されたスレッドのXAリソース・マネージャを閉じる
thread_releaseメソッドのデフォルト実装が用意されています。
Tobj_ServantBaseインタフェースは、
PortableServer::RefCountServantBaseクラスから継承され、CORBAオブジェクトがスレッド・セーフ方式でその状態の管理を支援できるようにする操作を定義します。IDLコンパイラによって生成されたすべての実装スケルトンは、
Tobj_ServantBaseクラスを自動的に継承します。
Tobj_ServantBaseクラスには、プログラマがオプションで実装できる2つの仮想メソッド(
activate_object()および
deactivate_object())が含まれます。
|
注意:
|
CORBAオブジェクトのアクティブ化と非アクティブ化に対して呼び出されることがTPフレームワークによって保証されるメソッドは、 Tobj_ServantBase::activate_object()および Tobj_ServantBase::deactivate_object()のみです。サーバント・クラス・コンストラクタおよびデストラクタは、アクティブ化または非アクティブ化時に(C++の Server::create_servant呼出しを介して)呼び出される場合と呼び出されない場合があります。したがって、サーバー・アプリケーション・コードは、サーバント・クラスのコンストラクタまたはデストラクタでCORBAオブジェクトの状態処理を行ってはなりません。 |
|
注意:
|
プログラマが直接的にTobj_ServantBaseへのキャストや参照を使用する必要はありません。 Tobj_ServantBaseメソッドはスケルトンに含まれているので、サーバントの実装にも含まれることになります。プログラマは activate_objectおよび deactivate_objectメソッドを定義できますが、これらのメソッドを直接呼び出してはなりません。TPフレームワークだけがこれらのメソッドを呼び出します。
|
次に、Tobj_servantBaseインタフェースのC++マッピングを示します。
オブジェクトIDを文字列形式で指定します。 オブジェクトIDは、クラスのこのインスタンスを一意に識別します。このオブジェクトIDは、
TP::create_object_reference()を使用してオブジェクト参照を作成したときに指定したID、または
TP::create_active_object_reference()の呼出しで使用したオブジェクト参照のIDと同じになります。
プログラマは、activate_object()および
deactivate_object()メソッドとクライアントが呼び出すメソッドを使用して、オブジェクトの状態を管理できます。これらのメソッドを使用してオブジェクトの状態を管理する方法は、アプリケーションのニーズによって異なります。これらのメソッドの使用方法は、
「CORBAサーバー・アプリケーションの作成」を参照してください。
activate_object()の実行中にエラーが発生した場合、アプリケーション・コードでは、CORBA標準例外または
TobjS::ActivateObjectFailed例外を生成する必要があります。例外が発生すると、TPフレームワークは例外を捕捉して、以下のイベントが発生します。
|
•
|
activate_object()がクライアントの開始したトランザクション内で実行されている場合、トランザクションはロールバック されません。
|
|
•
|
CORBA::OBJECT_NOT_EXIST例外がクライアントに返されます。
|
reasonはユーザー指定の理由を示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
reasonはユーザー指定の理由を示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
myServant * servant = new intf_i();
if(servant != NULL)
servant->_add_ref();
reasonコードは、
transactionアクティブ化ポリシーが設定されたオブジェクト専用です。これは、トランザクションがクライアントまたはシステムによって自動的に開始された場合に発生します。
deactivate_object()メソッドがこの理由コードで呼び出された場合、トランザクションはロールバック対象としてマークされます。
reasonコードは、
transactionアクティブ化ポリシーが設定されたオブジェクト専用です。これは、トランザクションがクライアントまたはTPフレームワークによって開始された場合に発生します。これは、オブジェクトが呼び出されたトランザクションに対して
Current.commit()操作が呼び出されたことを示します。
deactivate_object()メソッドは、トランザクション・マネージャが2フェーズ・コミット・アルゴリズムを開始する直前、つまり
prepareがリソース・マネージャに送信される前に呼び出されます。
CORBAオブジェクトでは、DR_TRANS_COMMITTING reasonコードでdeactivate_object()メソッドが呼び出されたときに、トランザクションの結果に関して判断できます。このメソッドは、
Current.rollback_only()メソッドを呼び出すことで、トランザクションをロールバックさせることができます。そうでない場合は、2フェーズ・コミット・アルゴリズムが続行されます。トランザクションは、
Current.rollback_only()がこのメソッドで呼び出されなかったという理由以外でもコミットされないことがあります。トランザクションに関与するその他のCORBAオブジェクトまたはリソース・マネージャも、トランザクションのロールバックを支持できます。
アプリケーションがこのオブジェクトに対してTP::deactivateEnable(-,-,-)を実行したためにオブジェクトが非アクティブ化されることを示します。これは、
processアクティブ化ポリシーを設定されたオブジェクトに関してのみ発生します。
CORBAオブジェクトの実装のアクティブ化ポリシーがmethodの場合にクライアントによって呼び出されるメソッド、またはアクティブ化ポリシーが
transactionの場合にトランザクションの処理が終わったときに呼び出されるメソッドの実行後に、非アクティブ化が発生する場合もあります。また、アクティブ化ポリシーが
transactionまたは
processの場合に、サーバーが停止されると発生します。
|
注意:
|
deactivate_objectメソッドは、サーバーの停止時に、アクティブ・オブジェクト・マップに残っている各オブジェクト - TPフレームワークによって暗黙的に登録される場合(オン・デマンド・アクティブ化テクニック TP::create_servantとサーバントの activate_objectメソッド)と、ユーザーにより TP::create_active_object_referenceで明示的に登録される場合があります - に対して呼び出されます。
|
プログラマは、activate_object()および
deactivate_object()メソッドとクライアントが明示的に呼び出すメソッドを使用して、オブジェクトの状態を管理できます。これらのメソッドを使用してオブジェクトの状態を管理する方法は、アプリケーションのニーズによって異なります。これらのメソッドの使用方法は、
「CORBAサーバー・アプリケーションの作成」を参照してください。
transactionアクティブ化ポリシーが設定されたCORBAオブジェクトでは、
DR_TRANS_COMMITTING理由コードで
deactivate_object()メソッドが呼び出されたときに、トランザクションの結果に関して判断できます。このメソッドは、
Current.rollback_only()メソッドを呼び出すことで、トランザクションをロールバックさせることができます。そうでない場合は、2フェーズ・コミット・アルゴリズムが続行されます。トランザクションは、
Current.rollback_only()がこのメソッドで呼び出されなかったという理由以外でもコミットされないことがあります。トランザクションに関与するその他のCORBAオブジェクトまたはリソース・マネージャも、トランザクションのロールバックを支持できます。
同じように、reasonコード
DR_TRANS_ABORTEDでの呼出しが行われた場合、トランザクション・マネージャはすでに中断中です。トランザクション・マネージャが中断中の場合、トランザクションを一時停止したり、新しいトランザクションを開始したりすることはできません。この制約は、
DR_TRANS_COMMITTINGに関しても適用されます。
クライアントには、deactivate_object()で発生した例外について通知されません。アプリケーション・コードでは、格納されているCORBAオブジェクトの状態が一貫性があるかどうかをチェックする必要があります。たとえば、アプリケーション・コードで、
deactivate_object()がオブジェクトの状態を正しく保存したかどうかを示す永続性フラグを保存すると便利です。このフラグを
activate_object()でチェックします。
deactivate_object()の実行中にエラーが発生した場合、アプリケーション・コードでは、CORBA標準例外または
DeactivateObjectFailed例外を生成する必要があります
。deactivate_object()がTPフレームワークで呼び出されると、TPフレームワークは例外を捕捉して、次のイベントが発生します。
reasonはユーザー指定の理由を示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
exceptionIDは例外のインタフェースIDを示し、
interfaceNameと
oidはそれぞれ呼び出されたCORBAオブジェクトのインタフェースIDとオブジェクトIDを示します。
CORBA::Boolean _
is_reentrant()
Tobj_ServantBaseクラスには、
FALSEを返す
_is_reentrantメソッドのデフォルト実装が用意されています。
|
•
|
TP.hファイルには、 TPクラスの宣言および定義が格納されています。
|
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);
};
Tobj::Tobj_Bootstrapオブジェクトに対するポインタを返します。Bootstrapオブジェクトは、FactoryFinderオブジェクト、インタフェース・リポジトリ、TransactionCurrentオブジェクト、およびSecurityCurrentオブジェクトへの初期リファレンスにアクセスする場合に使用します。
bootstrap()は、正常に終了すると、サーバー・アプリケーションの開始時にTPフレームワークで作成された
Tobj::Tobj_Bootstrapオブジェクトに対するポインタを返します。
TPフレームワークでは、初期化の一部としてTobj::Tobj_Bootstrapオブジェクトが作成されます。したがって、アプリケーション・コードで他の
Tobj::Tobj_Bootstrapオブジェクトをサーバー内に作成する必要はありません。
|
注意:
|
Tobj::Tobj_Bootstrapオブジェクトの所有権はTPフレームワークにあるため、サーバー・アプリケーション・コードでBootstrapオブジェクトを破棄しないようにしてください。
|
close_xa_rm()メソッドは、呼出しプロセスのリンク先のXAリソース・マネージャを閉じます。XAリソース・マネージャは、OracleやInformixなどのデータベース・ベンダーから提供されます。
|
注意:
|
この呼出しの機能は、Tobj::TransactionCurrent::close_xa_rm()によっても提供されます。TransactionCurrentオブジェクトのオブジェクト参照を取得する必要がないので、サーバー・アプリケーションでリソース・マネージャを閉じる方法としては、 TP::close_xa_rm() メソッドを使う方がはるかに便利です。TransactionCurrentオブジェクトのリファレンスは、Bootstrapオブジェクトから取得できます。Bootstrapオブジェクトへの参照を取得する方法の詳細は、 「TP::bootstrap()」を参照してください。TransactionCurrentオブジェクトの詳細は、 「CORBAブートストラップ処理のプログラミング・リファレンス」という項と 『CORBAトランザクションの使用』を参照してください。
|
close_xa_rm()メソッドは、リソース・マネージャに固有のクローズ呼出しのかわりに呼び出します。リソース・マネージャの初期化セマンティクスはそれぞれ異なるので、特定のリソース・マネージャを閉じるための情報を、Oracle Tuxedoシステムの
UBBCONFIGファイルの
GROUPSセクションにある
CLOSEINFOパラメータに指定します。
CLOSEINFO文字列の形式は、基礎となるリソース・マネージャを提供しているデータベース・ベンダーの要件によって異なります。
CLOSEINFOパラメータの詳細は、
Oracle Tuxedoアプリケーションの設定と、
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
ubbconfig(5)のリファレンス・ページを参照してください。また、XAライブラリを使用するアプリケーションの開発およびインストール方法については、データベース・ベンダーのドキュメントを参照してください。
tx_close()呼出しによって、エラー戻りコードが返されました。
|
注意:
|
TPフレームワークによって返されるその他の例外とは異なり、Tobj::RMFailed例外は、 TobjS_c.h ( TobjS.idlから派生)ではなく、 tobj_c.h ( tobj.idlから派生)で定義されます。これは、ネイティブ・クライアントでもXAリソース・マネージャを開けるからです。したがって、返される例外は、ネイティブ・クライアント・コードおよび Server::release() (ネイティブ・クライアントと共有される代替メカニズムである TransactionCurrent::close_xa_rmを使用している場合)で想定される例外と一致します。
|
ObjectIdを文字列形式で指定します。
ObjectIdは、クラスのこのインスタンスを一意に識別します。プログラマは、
ObjectIdに指定する情報を決めます。一例として、データベース・キーの保持に使用する方法があります。オブジェクト識別子の値を選択、つまり一意性のレベルを決定することは、アプリケーション・デザインの一環です。Oracle Tuxedoソフトウェアでは、オブジェクト参照の一意性は保証されません。オブジェクト参照を文字列化する場合など、オブジェクト参照をコピーしたり、Oracle Tuxedo環境の外で共有したりすることがあるからです。
サーバントが別のObjectIdですでに使用されているため、オブジェクトを明示的にアクティブ化できませんでした。サーバントは、単一の
ObjectIdでのみ使用できます。別の
ObjectIdを含むオブジェクトを事前にアクティブ化するには、アプリケーションが複数のサーバントを作成し、
ObjectIdごとに1つずつ事前にアクティブ化する必要があります。
ObjectIdがすでにアクティブ・オブジェクト・マップで使用されているため、オブジェクトを明示的にアクティブ化できませんでした。ある特定の
ObjectIdには、1つのサーバントしか関連付けられません。別のサーバントに変更するには、アプリケーションでまずオブジェクトを事前アクティブ化してからもう一度アクティブ化する必要があります。
|
•
|
Server::initialize()内。最初の呼出しでアクティブ化しなくて済むように、プロセス・オブジェクトを事前アクティブ化します。
|
ここで、<CORBA interface name>は任意のオブジェクト・クラス名です。例:
ObjectIdを文字列形式で指定します。
ObjectIdは、クラスのこのインスタンスを
一意で識別します。
ObjectIdに指定する情報を決めるのは、プログラマの裁量です。一例として、
ObjectIdをデータベース・キーの保持に使用する方法があります。オブジェクト識別子の値を選択、つまり一意性のレベルを決定することは、アプリケーション・デザインの一環です。Oracle Tuxedoソフトウェアでは、オブジェクト参照の一意性は保証されません。というのは、オブジェクト参照を文字列として渡す場合など、オブジェクト参照をコピーしたり、Oracle Tuxedoドメインの外で共有したりすることがあるからです。オブジェクト参照での呼出しを並列実行できるように、一意の
ObjectIdを選択することを強くお薦めします。
Oracle Tuxedoシステムの管理者は、UBBCONFIGファイルでルーティング規則を指定して、ファクトリ・ベース・ルーティングを構成します。この機能の詳細は、オンライン・ドキュメントの
Oracle Tuxedoアプリケーションの設定を参照してください。
create_object_reference()メソッドの例外は次のとおりです。
指定されたinterfaceNameがNULLであることを示します。
指定されたstroidがNULLであることを示します。
create_object_reference()メソッドの呼出しは、サーバー・アプリケーションの役割です。このメソッドによって、オブジェクト参照が作成されます。作成されたオブジェクト参照は、オブジェクトへのアクセスで使用するクライアントに渡されます。
|
•
|
Server::initialize()内。サーバーのファクトリを作成します。
|
create_object_reference()メソッドの呼出し方法とタイミングの例は、
『CORBAサーバー・アプリケーションの作成』を参照してください。
deactivateEnable()メソッドの例外は次のとおりです。
TP::deactivateEnableメソッドが、アクティブ化ポリシーを
transactionに設定されたオブジェクトによって呼び出されたことを示します。
|
注意:
|
シングル・スレッド・サーバーの場合、TP::deactivateEnable(interface, object id, servant)メソッドを使用すると、オブジェクトを非アクティブ化できます。ただし、オブジェクトがトランザクションに参加している場合、オブジェクトが非アクティブ化されるのは、トランザクションがコミットまたはロールバックしたときです。トランザクションがコミットまたはロールバックする前にオブジェクトに対して呼出しが行われた場合、オブジェクトは非アクティブ化されません。
|
アプリケーションでは、ObjectIdと関連付けられたサーバントを指定することで、オブジェクトの非アクティブ化をリクエストします。
非アクティブ化をリクエストされたオブジェクトにtransactionアクティブ化ポリシーが設定されていた場合、
IllegalOperation例外が発生します。これは、こうしたオブジェクトを非アクティブ化すると、Oracle Tuxedoトランザクション・マネージャからのトランザクション終了の通知と競合する場合があるからです。
static CORBA::Object_ptr TP::get_object_reference ();
get_object_reference()が
Server::initialize()または
Server::release()内から呼び出された場合、アプリケーションのTPオブジェクトの実行スコープ外で呼び出されたものとみなされるため、
TobjS::NilObject例外が発生します。
get_object_reference()メソッドの例外は次のとおりです。
tx_open()呼出しによって、エラー戻りコードが返されました。
open_xa_rm()メソッドは、呼出しプロセスのリンク先のXAリソース・マネージャを開きます。XAリソース・マネージャは、OracleやInformixなどのデータベース・ベンダーから提供されます。
|
注意:
|
このメソッドの機能は、Tobj::TransactionCurrent::close_xa_rm()によっても提供されます。ただし、TransactionCurrentオブジェクトのオブジェクト参照を取得する必要がないので、サーバー・アプリケーションでリソース・マネージャを開く方法としては、 TP::open_xa_rm()メソッドを使う方がはるかに便利です。TransactionCurrentオブジェクトのリファレンスは、Bootstrapオブジェクトから取得できます。Bootstrapオブジェクトへの参照を取得する方法の詳細は、 「TP::bootstrap()」を参照してください。TransactionCurrentオブジェクトの詳細は、 「CORBAブートストラップ処理のプログラミング・リファレンス」という項と 『CORBAトランザクションの使用』を参照してください。
|
グローバル・トランザクションに参加するサーバーごとにServer::initialize()メソッドから1回、このメソッドを呼び出す必要があります。グローバル・トランザクションに関与しているすべてのサーバーだけでなく、XAリソース・マネージャにリンクされたサーバーも含まれますが、XA準拠のリソース・マネージャに実際にはリンクされていません。
open_xa_rm()メソッドは、リソース・マネージャに固有のオープン呼出しのかわりに呼び出します。リソース・マネージャの初期化セマンティクスはそれぞれ異なるので、特定のリソース・マネージャを開くための情報を、
UBBCONFIGファイルの
GROUPSセクションにある
OPENINFOパラメータに指定します。
OPENINFO文字列の形式は、基礎となるリソース・マネージャを提供しているデータベース・ベンダーの要件によって異なります。
CLOSEINFOパラメータの詳細は、
Oracle Tuxedoアプリケーションの設定と、
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
ubbconfig(5)のリファレンス・ページを参照してください。また、XAライブラリを使用するアプリケーションの開発およびインストール方法については、データベース・ベンダーのドキュメントを参照してください。
ORBオブジェクトにアクセスすると、アプリケーションでは、
string_to_object()や
object_to_string()などのORB操作を呼び出すことができます。
|
注意:
|
TPフレームワークがORBオブジェクトを所有しているため、アプリケーションで削除しないようにしてください。
|
orb()は、正常に終了すると、サーバー・プログラムの開始時にTPフレームワークで作成された
ORBオブジェクトに対するポインタを返します。
static void TP::register_factory(
CORBA::Object_ptr factory_or, const char* factory_id);
TP::create_object_reference()メソッドを使用して、アプリケーション・ファクトリ用に作成されたオブジェクト参照を指定します。
register_factory()メソッドの例外は次のとおりです。
FactoryFinderが検索中に内部エラーに遭遇したことを示します。エラーは、ユーザー・ログ(ULOG)に書き込まれます。この例外が発生した場合は、すぐに作業担当者に通知してください。内部エラーの重大度によっては、FactoryFinderまたはNameManagerが実行されていたサーバーが終了していることがあります。FactoryFinderサービスが終了した場合は、新しいFactoryFinderサービスを開始します。NameManagerが終了しており、別のNameManagerが実行中である場合は、新規のNameManagerを開始します。稼動中のNameManagerがない場合は、アプリケーションを再起動します。
id文字列が空であることを示します。フィールドに空白または制御文字が含まれている場合にも例外が発生します。
id文字列が128バイト(許可されている最大長)より長いことを示します。
static void TP::unregister_factory (
CORBA::Object_ptr factory_or, const char* factory_id);
TP::create_object_reference()メソッドを使用して、アプリケーション・ファクトリ用に作成されたオブジェクト参照を指定します。
unregister_factory()メソッドの例外は次のとおりです。
FactoryFinderが検索中に内部エラーに遭遇したことを示します。エラーは、ユーザー・ログ(ULOG)に書き込まれます。この例外が発生した場合は、すぐに作業担当者に通知してください。内部エラーの重大度によっては、FactoryFinderまたはNameManagerが実行されていたサーバーが終了していることがあります。FactoryFinderサービスが終了した場合は、新しいFactoryFinderサービスを開始します。NameManagerが終了しており、別のNameManagerが実行中である場合は、新規のNameManagerを開始します。稼動中のNameManagerがない場合は、アプリケーションを再起動します。
id文字列が空であることを示します。フィールドに空白または制御文字が含まれている場合にも例外が発生します。
id文字列が128バイト(許可されている最大長)より長いことを示します。
最初の引数では、printf(3S)スタイルの形式を指定します。
printf(3S)引数については、CまたはC++リファレンス・マニュアルで説明されています。
userlog()メソッドは、ユーザー・ログ(
ULOG)ファイルにメッセージを書き込みます。メッセージは、時刻(hhmmss)、システム名、プロセス名、および呼出しプロセスのプロセスIDで構成されるタグを付けて、
ULOGファイルに追加されます。タグの最後にはコロンが付けられます。
サーバー・アプリケーションでは、userlog()によるメッセージをアプリケーション・エラーのデバッグで有用となるメッセージに限定することをお薦めします。
ULOGが重要度の低いメッセージでいっぱいになると、実際のエラーの特定が難しくなります。
userlog()メソッドは、出力された文字数を返し、出力エラーが発生した場合には、負の値を返します。出力エラーには、現在のログ・ファイルのオープン・エラーや書込みエラーがあります。
Tobj_ServantBase::deactivate_object()の場合、次のコードは
DeactivateObjectFailed例外をスローします。
151104は時刻(3:11:04pm)、
T1はシステム名、
simpappsはプロセス名、
247はプロセスIDをそれぞれ示し、
APPEXCはメッセージがアプリケーション例外メッセージであることを示します。
