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