| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > トランザクションの CORBA サーバ・アプリケーションへの統合 |
|
Tuxedo CORBA サーバ・アプリケーションの開発方法
|
トランザクションの CORBA サーバ・アプリケーションへの統合
この章では、CORBA サーバ・アプリケーションにトランザクションを統合する方法について、Transactions University サンプル・アプリケーションを例にして説明します。Transactions サンプル・アプリケーションは、学生がコースのセットを登録するプロセスをカプセル化します。Transactions サンプル・アプリケーションでは、CORBA サーバ・アプリケーションをトランザクションに統合するためのすべての方法ではなく、トランザクションの振る舞いの 2 つのモデルを示すことによって、アプリケーション一般、特にオブジェクトの永続状態に対するトランザクションの振る舞いの影響を示します。
ここでは、以下の内容について説明します。
また、この章ではユーザ定義例外についても説明します。Transactions サンプル・アプリケーションはユーザ定義例外を利用します。この例外は、クライアント・アプリケーションに返すことができ、クライアントが開始したトランザクションのロールバックを発生させることが可能です。
BEA Tuxedo システムでのトランザクションの概要
BEA Tuxedo システムでは、データベースのトランザクションが正確に完了すること、およびデータベースのトランザクションが高性能なトランザクションの ACID プロパティ (原子性、一貫性、独立性、および持続性) のすべてを備えることを保証する手段として、トランザクションが提供されています。つまり、永続ストレージに複数の書き込みオペレーションを実行する上での要件があるので、オペレーションの成功が保証されている必要があります。オペレーションが 1 つでも失敗すれば、一連のオペレーションの全体がロールバックされます。
一般に、トランザクションは次のリストで説明される状況に適しています。それぞれの状況は、BEA Tuxedo システムでサポートされているトランザクション・モデルをカプセル化しています。
たとえば、旅行代理店アプリケーションがあるとします。クライアント・アプリケーションは、たとえばフランスのストラスブールからオーストラリアのアリス・スプリングスまでなど、遠隔地への旅行を手配する必要があります。このような旅行では、複数の予約が必要になります。クライアント アプリケーションでは、旅程の各区分の予約が順番に行われます。たとえば、ストラスブールからパリ、パリからニューヨーク、ニューヨークからロサンゼルスの予約が順番に行われます。しかし、いずれかのフライトが予約できないとき、クライアント・アプリケーションにはその時点で予約済みのほかのフライトをすべてキャンセルする方法が必要です。たとえば、クライアント・アプリケーションでロサンゼルスからホノルルへの指定日のフライトを予約できなかったら、クライアント・アプリケーションはその時点までに済ませたフライト予約をキャンセルする必要があります。
たとえば、インターネット・ベースのオンライン・ショッピング・アプリケーションを検討してみます。クライアント・アプリケーションのユーザがオンライン・カタログを一覧して、複数の購入を選択します。ユーザは、購入したい商品をすべて選択したら、ボタンをクリックして購入を実行し、クレジット・カード情報を入力します。クレジット・カードの確認が失敗したら (たとえば、ユーザのクレジット・カード情報が無効だった場合)、ショッピング・アプリケーションでは、未決済の購入選択をすべてキャンセルしたり、会話で行われたすべての購入トランザクションをロールバックしたりできる必要があります。
たとえば、銀行取引アプリケーションがあるとします。クライアントは、窓口オブジェクトに対して振替オペレーションを呼び出します。振替オペレーションは、銀行データベースに対して以下の呼び出しを実行するために窓口オブジェクトを必要とします。
銀行データベースの振替先呼び出しに失敗した場合、銀行取引アプリケーションではそれまでの振替元呼び出しをロールバックする機能が必要です。
CORBA サーバ・アプリケーションでのトランザクションの設計およびインプリメンテーション
ここでは、CORBA サーバ・アプリケーションでのトランザクションを設計およびインプリメントする方法について、Transactions University サンプル・アプリケーションを例にして説明します。また、ここでは、Transactions サンプル・アプリケーションの動作と、トランザクションをインプリメントする際の設計上の考慮事項についても説明します。トランザクション全般の詳細については、第 6 章の 12 ページ「トランザクションの CORBA クライアントおよびサーバ・アプリケーションへの統合」を参照してください。
Transactions サンプル・アプリケーションは、学生がコースのセットを登録するプロセスを、トランザクションを利用してカプセル化します。このアプリケーションで使用されているトランザクション・モデルは、前の節で説明したように、会話モデルと、単一の呼び出しがデータベースに対して複数のオペレーションを個別に行うモデルを組み合わせたものです。
この Transactions サンプル・アプリケーションは、Security サンプル・アプリケーションを基に以下の機能を追加したものです。
Transactions サンプル・アプリケーションは、次の 2 とおりの方法でトランザクションをロールバックします。
したがって、Transactions サンプル・アプリケーションでも、ユーザ定義の CORBA 例外をインプリメントする方法が示されています。たとえば、学生が登録可能なコースの最大数を超えているコースに登録しようとすると、サーバ・アプリケーションは、TooManyCredits 例外を返します。クライアント・アプリケーションは、この例外を受け取ると、自動的にトランザクションをロールバックします。
ここでは、次の内容について説明します。
Transactions University サンプル・アプリケーションのしくみ
学生を登録するプロセスをインプリメントするために、Transactions サンプル・アプリケーションは、以下の作業を実行します。
Registrar オブジェクトは、発生する可能性のある次の問題を確認します。これらは、トランザクションのコミットを妨げる問題です。
NotRegisteredList の値が空の場合、クライアント・アプリケーションはトランザクションをコミットします。
NotRegisteredList 値にコースが含まれていない場合、クライアント・アプリケーションは、登録に成功したコースに対する登録プロセスを完了するかどうかを指定するよう学生に要求します。登録を完了するように選択した場合、クライアント・アプリケーションはトランザクションをコミットします。登録を取り消すように選択した場合、クライアント・アプリケーションはトランザクションをロールバックします。
Transactions University サンプル・アプリケーションで使用するトランザクション・モデル
Transactions サンプル・アプリケーションの基本設計原理は、コース登録を一度に 1 つではなくグループ単位で処理することです。この設計は、Registrar オブジェクトへのリモート呼び出しの数を最小にすることに役立ちます。
この設計のインプリメンテーションで、Transactions サンプル・アプリケーションはトランザクションの使用の 1 モデルを示します。トランザクションの各モデルの詳細については、第 6 章の 2 ページ「BEA Tuxedo システムでのトランザクションの概要」を参照してください。このモデルの特徴は、次のとおりです。
Registrar オブジェクトは、登録可能なコースについて学生を登録してから、登録のプロセスに失敗したコースのリストを返します。クライアント・アプリケーションは、トランザクションをコミットするかロールバックするかを選択できます。トランザクションは、クライアント・アプリケーションとサーバ・アプリケーションの間の会話をカプセル化します。
University サーバ・アプリケーションのオブジェクト状態に関する注意事項
Transactions University サンプル・アプリケーションはトランザクションに関与するため、University サーバ・アプリケーションは通常、オブジェクト状態に関していくつかの点 (特にロールバック時の) を考慮する必要があります。ロールバックが発生した場合、サーバ・アプリケーションは、関連するすべてのオブジェクトが、正しい状態に復元された永続状態を持つことを保証する必要があります。
Registrarオブジェクトがデータベースのトランザクションに使用されるので、このオブジェクトについてはトランザクションに関与させるのが正しい設計上の選択です。つまり、このオブジェクトのインターフェイスに always トランザクション方針を割り当てることです。オブジェクト呼び出し時にトランザクションがまだスコープ指定されていない場合、BEA Tuxedo システムは、トランザクションを自動的に開始します。
Registrar オブジェクトを自動的にトランザクション・モードになるようにすることで、このオブジェクトによって実行されるすべてのデータベース書き込みオペレーションは、常にトランザクションのスコープ内で行われることになり、クライアント・アプリケーションによってトランザクションが開始されたかどうかは関係がなくなります。サーバ・アプリケーションは XA リソース・マネージャを使用し、またオブジェクトは、データベースに書き込みを実行するときにトランザクションにあることが保証されます。したがって、XA リソース・マネージャがオブジェクトの代わりにロールバックまたはコミットの権限を持つことになるので、オブジェクトにはロールバックまたはコミット権限がありません。
しかし、RegisterFactory オブジェクトは、トランザクションの過程で使用されるデータを管理しないのでトランザクションから除外してもかまいません。オブジェクトをトランザクションから除外することで、トランザクションに課せられる処理のオーバーヘッドを最小化します。
Registrar オブジェクトで定義されたオブジェクト方針
Registrarオブジェクトをトランザクションに関与するようにするために、ICF ファイルは Registrar インターフェイスに always トランザクション方針を指定します。したがって、Transactions サンプル・アプリケーションでは、ICF ファイルで、Registrar インターフェイスに対して以下のオブジェクト方針を指定します。
RegistrarFactory オブジェクトで定義されたオブジェクト方針 RegistrarFactory オブジェクトをトランザクションから除外するために、ICF ファイルは Registrar インターフェイスに ignore トランザクション方針を指定します。したがって、Transactions サンプル・アプリケーションでは、ICF ファイルで、RegistrarFactory インターフェイスに対して以下のオブジェクト方針を指定します。
Transactions サンプル・アプリケーションでの XA リソース・マネージャの使用 Transactions サンプル・アプリケーションは、オブジェクト状態データを自動的に処理する Oracle トランザクション・マネージャ・サーバ (TMS) を使用します。XA リソース・マネージャを使用すると、サーバ・アプリケーションで管理される別のオブジェクトが、データベースとの間のデータの読み書きをどのように実行するかについて、以下のような特定の要件が適用されます。
XA リソース・マネージャの特徴は、ロールバック時のオブジェクト状態データの処理に関する設計の問題をより簡単なものにすることです。トランザクションに関与するオブジェクトは、コミットおよびロールバック権限を XA リソース・マネージャに委譲します。これによって、サーバ・アプリケーションのインプリメントは、大幅に単純化されます。
Transactions サンプル・アプリケーションのコンフィギュレーションの要件
University サンプル・アプリケーションは、Oracle のトランザクション・マネージャ・サーバ (TMS) を使用します。Oracle のデータベースを使用するには、サーバ・アプリケーションを構築する際に、Oracle から提供された特定のファイルを含める必要があります。
Transactions サンプル・アプリケーションの構築、設定、および実行の詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。また、オンライン・マニュアルにも、各サンプル・アプリケーション用の UBBCONFIG ファイルと、ファイルの各エントリの説明が示されています。
トランザクションの CORBA クライアントおよびサーバ・アプリケーションへの統合
BEA Tuxedo システムは、次のようにしてトランザクションをサポートします。
オブジェクトがポーリングされるとき、そのオブジェクトが TransactionCurrent オブジェクトの rollback_only() オペレーションを呼び出して現在のトランザクションのコミットを拒否する可能性があります。さらに、現在のトランザクションがロールバックされる場合、オブジェクトは、データベースへの書き込みをスキップできます。現在のトランザクションのコミットを拒否するオブジェクトがなければ、トランザクションはコミットされます。
以後の節では、必要なトランザクションの振る舞いをオブジェクトに指定するためにオブジェクトの活性化方針とトランザクション方針を使用する方法を説明します。これらの方針は、インターフェイスに適用されます。したがって、そのインターフェイスをインプリメントしているすべてのオペレーションとオブジェクトに適用されます。
注記 サーバ・アプリケーションが、トランザクションに参加するオブジェクトを管理している場合、そのアプリケーションの Server オブジェクトは、TP::open_xa_rm() オペレーションおよび TP::close_xa_rm() オペレーションを呼び出す必要があります。データベース接続の詳細については、第 6 章の 18 ページ「XA リソース・マネージャのオープン」を参照してください。
オブジェクトを自動的にトランザクションに関与させる方法
BEA Tuxedo システムは、always トランザクション方針を提供します。これは、オブジェクトが呼び出されたときにトランザクションがまだスコープ指定されていない場合、BEA Tuxedo システムがトランザクションを自動的に開始するように、そのオブジェクトのインターフェイスを定義します。そのオブジェクトの呼び出しが完了すると、BEA Tuxedo システムは、自動的にトランザクションをコミットまたはロールバックします。サーバ・アプリケーションもオブジェクト・インプリメンテーションも、この状態で TransactionCurrent オブジェクトを呼び出す必要はありません。つまり、BEA Tuxedo システムは、サーバ・アプリケーションの代わりに自動的に TransactionCurrent オブジェクトを呼び出します。
オブジェクトのインターフェイスに always トランザクション方針を割り当てることが適切なのは、次の場合です。
オブジェクトを自動的にトランザクションに関与させる必要がある場合は、当該のオブジェクトのインターフェイスに関する次の方針をインプリメンテーション・コンフィギュレーション・ファイル (ICF ファイル) に記述します。
注記 データベース・カーソルは、複数のトランザクションにまたがることができません。CORBA の University サンプル・アプリケーションにある CourseSynopsisEnumerator オブジェクトでは、一致するコース概要を University データベースで検索するためにデータベース・カーソルが使用されています。データベース・カーソルは複数のトランザクションにまたがることができないので、CourseSynopsisEnumerator オブジェクトの activate_object() オペレーションは一致するすべてのコース概要をメモリに読み取ります。カーソルはイテレータ・クラスによって管理されているので、CourseSynopsisEnumerator オブジェクトからは見えないことに注意してください。 オブジェクトのトランザクションへの参加の有効化 オブジェクトをトランザクションのスコープ内で呼び出すことができるようにする必要がある場合、optional トランザクション方針をそのオブジェクトのインターフェイスに割り当てることができます。optional トランザクション方針は、データベース書き込みオペレーションを実行しないものの、トランザクション時に呼び出すことができるようにする必要があるオブジェクトに適しています。 オブジェクトに optional トランザクション方針を適用するために、そのオブジェクトのインターフェイス用の ICF ファイルで次の方針を指定できます。
オブジェクトがデータベース書き込みオペレーションを実行しており、オブジェクトがトランザクションに関与できるようにする必要がある場合は、always トランザクション方針を割り当てる方が適切です。ただし、目的に応じて optional 方針を使用し、TransactionCurrent オブジェクトに対する呼び出しで書き込みオペレーションをカプセル化できます。つまり、オブジェクトがまだトランザクション内にスコープ指定されていない場合、データを書き込むオペレーション内で、トランザクションを開始およびコミットまたはロールバックするために TransactionCurrent オブジェクトを呼び出し、write 文の周囲にトランザクションをスコープします。これによって、データベース書き込みオペレーションがトランザクションに関与する形で処理されます。また、性能も向上します。TransactionCurrent オブジェクトがトランザクションのスコープ内で呼び出されなければ、すべてのデータベース読み取りオペレーションがトランザクションの外部になるので、効率が高くなります。 注記 BEA Tuxedo システムで使用される XA リソース・マネージャの一部では、トランザクションに関与するすべてのオブジェクトについて、データベース書き込みオペレーションに加えて読み取りオペレーションについても、トランザクション内でスコープ指定する必要があります(しかし、それでも独自にトランザクションのスコープ指定はできます)。たとえば、BEA Tuxedo システムで Oracle TMS を使用する場合に、この要件が該当します。トランザクション方針を選択してオブジェクトに割り当てる場合、使用している XA リソース・マネージャの要件を把握します。 トランザクションのスコープ指定時のオブジェクト呼び出しの防止 多くの場合、オブジェクトをトランザクションから除外することは危険です。このようなオブジェクトがトランザクション時に呼び出されると、オブジェクトは例外を返し、トランザクションがロールバックされることがあります。BEA Tuxedo システムには never トランザクション方針が用意されていて、これをオブジェクトのインターフェイスに割り当てれば、現在のトランザクションが一時停止中でも、特定のオブジェクトをトランザクションの処理中に呼び出されないようにできます。 このトランザクション方針は、ロールバックできないディスクに永続状態を書き込むオブジェクトに適しています。たとえば、XA リソース・マネージャに管理されていないディスクにデータを書き込むオブジェクトなどです。クライアント・アプリケーションで、呼び出しの一部がトランザクションのスコープ指定を引き起こしているかどうかを認識できない場合、クライアント/サーバ・アプリケーションでこの機能を使用することは重要です。したがって、トランザクションがスコープ指定されている場合、この方針を持つオブジェクトが呼び出されると、トランザクションをロールバックできるようになります。 トランザクションのスコープ指定がされているときにオブジェクトの呼び出しを禁止するには、ICF ファイルで当該のオブジェクトのインターフェイスに次の方針を割り当てます。
実行中のトランザクションからのオブジェクトの除外 トランザクションの過程でオブジェクトの呼び出しを許可し、ただしそのオブジェクトをトランザクションの一部にはしないことがふさわしい場合もあります。このようなオブジェクトがトランザクションの最中に呼び出された場合、トランザクションは自動的に中断します。オブジェクトに対する呼び出しが完了すると、トランザクションは自動的に再開します。この目的のために、BEA Tuxedo システムには ignore トランザクション方針が用意されています。 ignore トランザクション方針は、通常はデータをディスクに書き込まないファクトリなどのオブジェクトに適している場合があります。ファクトリをトランザクションから除外することで、そのファクトリは、トランザクションの最中でもほかのクライアントの呼び出しに使用できるようになります。さらに、この方針を使用すると、トランザクションに関与しているオブジェクトを呼び出す際のオーバーヘッドが軽減されるので、サーバ・アプリケーションの処理効率が向上します。 トランザクションがオブジェクトに伝達されることを禁止するには、ICF ファイルで当該のオブジェクトのインターフェイスに次の方針を割り当てます。
方針の割り当て ICF ファイルを作成してオブジェクトに方針を指定する方法の詳細については、「第 2 章の 17 ページ「ステップ 4: オブジェクトのメモリ内での振る舞い」」を参照してください。 XA リソース・マネージャのオープン オブジェクトのインターフェイスに always または optional トランザクション方針が適用されている場合、Server オブジェクトの Server::initialize() オペレーションの TP::open_xa_rm() オペレーションを呼び出す必要があります。リソース・マネージャは、UBBCONFIG ファイルの GROUPS セクションにある OPENINFO パラメータで提供された情報を基にオープンされます。デフォルト・バージョンの Server::initialize() オペレーションは、自動的にリソース・マネージャをオープンします。 データをディスクに書き込まず、トランザクションに参加しているオブジェクト (通常、トランザクション方針は optional) がある場合、TP::open_xa_rm() オペレーションへの呼び出しを含める必要があります。その呼び出しでは、ヌル・リソース・マネージャを指定します。 XA リソース・マネージャのクローズ Server オブジェクトの Server::initialize() オペレーションが、XA リソース・マネージャをオープンする場合は、Server::release() オペレーションに以下の呼び出しを含めます。
TP::close_xa_rm();
トランザクション管理とオブジェクト状態管理
CORBA クライアントおよびサーバ・アプリケーションにトランザクションが必要な場合に、トランザクションとオブジェクト状態の管理を統合する方法は複数あります。一般に、BEA Tuxedo システムでは、オペレーション呼び出しの間のトランザクションについてスコープ指定を自動的に行うようにでき、このときにアプリケーションのロジックを変更したり、オブジェクトが永続状態をディスクに書き込む方法を変更したりする必要はありません。
ここでは、トランザクションとオブジェクト状態の管理に関する重要な項目の一部を説明します。
XA リソース・マネージャへのオブジェクト状態管理の委譲
XA リソース・マネージャを使用すると、たとえば CORBA University サンプル・アプリケーションで使用される Oracle のリソース・マネージャなどであれば、一般に、ロールバックでのオブジェクト状態データの処理に関連する設計上の問題が簡単になります。トランザクション・オブジェクトはコミットおよびロールバックの処理をいつでも XA リソース・マネージャに委譲できるので、このことによってサーバ・アプリケーションをインプリメントする作業が大幅に簡略化されます。つまり、トランザクションに関与するプロセス・バウンドまたはメソッド・バウンド・オブジェクトは、トランザクション時にデータベースに書き込みを実行し、トランザクションのロールバック時にリソース・マネージャに従ってデータベースに書き込まれたデータをロールバックできます。
トランザクションの作業が完了してから、データベースへの書き込みが始まるまでの待機
transaction 活性化方針は、トランザクションの作業が完了するまで書き込みたくない、または書き込めないメモリ内の状態をディスクに保持するオブジェクトに適しています。transaction 活性化方針をオブジェクトに割り当てると、オブジェクトは、以下のようになります。
トランザクションの作業が完了したら、BEA Tuxedo システムは各トランザクション・バウンド・オブジェクトの Tobj_ServantBase::deactivate_object() オペレーションを呼び出して、DR_TRANS_COMMITTING または DR_TRANS_ABORT のどちらかの reason コードを渡します。変数が DR_TRANS_COMMITTING の場合、オブジェクトは、データベース書き込みオペレーションを呼び出すことができます。変数が DR_TRANS_ABORT であれば、オブジェクトは自身のデータベース書き込みオペレーションを省略します。
transaction 活性化方針のオブジェクトへの割り当ては、以下のような場合に適しています。
ロールバックの対象となる可能性のあるデータベース書き込みオペレーションの数を減らすことができるので、これによって、パフォーマンスがより効率的になります。
BEA Tuxedo システムが reason 値として DR_TRANS_COMITTING を渡す場合、オブジェクトは、必要であれば TransactionCurrent オブジェクトの rollback_only() オペレーションを呼び出すことができます。Tobj_ServantBase::deactivate_object() オペレーションの内部で rollback_only() オペレーションを呼び出した場合、その Tobj_ServantBase::deactivate_object() オペレーションが再度呼び出される点に注意してください。
トランザクションのコミットを待機してからデータベースに書き込む機能をオブジェクトに付与するには、当該のオブジェクトのインターフェイスに関する次の方針を ICF ファイルに記述します。
注記 トランザクション・バウンド・オブジェクトは、Tobj_ServantBase::deactivate_object() オペレーション内でトランザクションを開始したり、ほかのオブジェクトを呼び出したりすることはできません。トランザクション・バウンド・オブジェクトが Tobj_ServantBase::deactivate_object() オペレーションの内部から実行できる唯一の有効な呼び出しは、データベースへの書き込みオペレーションのみです。
また、トランザクションに関与するオブジェクトがある場合、そのオブジェクトを管理する Server オブジェクトは、管理されるオブジェクトがディスクに一切のデータを書き込まない場合でも、XA リソース・マネージャをオープンするための呼び出し、およびクローズするための呼び出しをそれぞれ含んでいる必要があります。 (データをディスクに書き込まない、トランザクションに関与するオブジェクトがある場合、ヌル・リソース・マネージャを指定します)。XA リソース・マネージャをオープンする方法およびクローズする方法の詳細については、「第 6 章の 18 ページ「XA リソース・マネージャのオープン」」および「第 6 章の 18 ページ「XA リソース・マネージャのクローズ」」を参照してください。
BEA Tuxedo のトランザクションの使用に関する注意事項
CORBA クライアント/サーバ・アプリケーションにトランザクションを統合する際の注意事項は、以下のとおりです。
既存のトランザクションが既に活性化している場合に、新しいトランザクションを開始することはできません。既存のトランザクションを中断すれば、新しいトランザクションを開始できます。しかし、中断したトランザクションを後で再開できるのは、トランザクションを中断したオブジェクトだけです。
トランザクション・オブジェクトは、自身を呼び出すようなオブジェクトを呼び出せません。
CORBA::OBJ_ADAPTER
トランザクション内にあるクライアントが、現在別のトランザクション内にあるオブジェクトに対してオペレーションを呼び出そうとすると、以下のエラー・メッセージが発行されます。
CORBA::INVALID_TRANSACTION
トランザクション外でオブジェクトが呼び出された場合、データの読み取りに対するトランザクションのスコープにオーバーヘッドは生じません。この方法で、トランザクション内でオブジェクトが呼び出されるかどうかに関係なく、オブジェクトのすべての書き込みオペレーションは、トランザクションに関与する形で処理されます。
オブジェクトのオペレーションの内部で例外が発生した場合、クライアント・アプリケーションは OBJ_ADAPTER 例外を受け取ります。この状況で、BEA Tuxedo システムは自動的にトランザクションをロールバックします。ただし、クライアント・アプリケーションは、トランザクションが BEA Tuxedo ドメインでスコープ指定されていないことをまったく認識していません。
注記 WebLogic Enterprise バージョン 4.2 ソフトウェアでは、この状況を回避する方法がありません。トランザクションを開始する前に、アプリケーションができるだけ周到にデータの検証を実行するようにしてください。
トランザクション中に TP::deactivateEnable メソッドが呼び出された場合、オブジェクトはトランザクションの終了時に非活性化されます。しかし、TP::deactivateEnable メソッドが呼び出された時点とトランザクションがコミットされた時点の間に、オブジェクトで何らかのメソッドが呼び出された場合、そのオブジェクトは決して非活性化されません。
ユーザ定義の例外
Transactions サンプル・アプリケーションには、ユーザ定義例外 TooManyCredits のインスタンスが含まれています。クライアント・アプリケーションが学生をコースに登録しようとしたときに、学生が登録可能なコースの最大数を超えている場合、サーバ・アプリケーションはこの例外を返します。クライアント・アプリケーションは、この例外を受け取ると、学生をコースに登録するトランザクションをロールバックします。ここでは、CORBA クライアント/サーバ・アプリケーションでユーザ定義例外を定義およびインプリメントする方法について、TooManyCredits を例にして説明します。
CORBA クライアント/サーバ・アプリケーションにユーザ定義例外を含める作業には、次の手順が関与します。
次の節では、最初の 2 つの手順の説明と例を示します。
例外の定義
クライアント/サーバ・アプリケーションの OMG IDL ファイルでは、以下の作業を行います。
exception TooManyCredits
{
unsigned short maximum_credits;
};
NotRegisteredList register_for_courses(
in StudentId student,
in CourseNumberList courses)
raises (TooManyCredits);
例外のスロー
例外を使用するオペレーションのインプリメンテーションでは、次の例のように、例外をスローするコードを記述します。
if ( ... ) {
UniversityZ::TooManyCredits e;
e.maximum_credits = 18;
throw e;
}
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||