|
b.
|
Registrarオブジェクトの register_for_courses()操作を呼び出して、コースのリストを渡します
|
|
•
|
Registrarオブジェクトの register_for_courses()操作は、リスト内の各コースに対して、ループ処理で次の作業を繰り返し実行し、登録リクエストを処理します。
|
Registrarオブジェクトは、トランザクションをコミットできないようにする可能性がある次の問題をチェックします。
NotRegisteredListの値が空の場合、クライアント・アプリケーションはトランザクションをコミットします。
NotRegisteredListの値にコースが含まれている場合、クライアント・アプリケーションは、登録に成功したコースの登録プロセスを完了するかどうかを指定するよう学生に要求します。登録を完了するように選択した場合、クライアント・アプリケーションはトランザクションをコミットします。登録を取り消すように選択した場合、クライアント・アプリケーションはトランザクションをロールバックします。
Registrarオブジェクトは、学生を登録可能なコースに登録し、登録のプロセスに失敗したコースのリストを返します。クライアント・アプリケーションは、トランザクションをコミットするかロールバックするかを選択できます。トランザクションは、クライアント・アプリケーションとサーバー・アプリケーションの間の会話をカプセル化します。
|
•
|
register_for_courses()操作は、Universityデータベースの複数チェックを実行します。いずれか1つのチェックが失敗した場合、トランザクションをロールバックできます。
|
Registrarオブジェクトがデータベースのトランザクションに使用されるため、このオブジェクトについてはトランザクションに関与させることが正しい設計上の選択です。つまり、このオブジェクトのインタフェースに
alwaysトランザクション・ポリシーを割り当てることです。オブジェクト呼出し時にトランザクションがまだスコープ指定されていない場合、Oracle Tuxedoシステムは、トランザクションを自動的に開始します。
Registrarオブジェクトが自動的にトランザクションに関与するようにすることで、このオブジェクトによって実行されるすべてのデータベース書込み操作は、クライアント・アプリケーションが開始したかどうかに関係なく、常にトランザクションのスコープ内で完了します。サーバー・アプリケーションはXAリソース・マネージャを使用し、またオブジェクトは、データベースに書込みを実行するときにトランザクションにあることが保証されます。したがって、XAリソース・マネージャがオブジェクトの代わりにロールバックまたはコミットの権限を持つことになるので、オブジェクトにはロールバックまたはコミット権限がありません。
ただし、RegistrarFactoryオブジェクトは、トランザクションの最中に使用するデータを管理しないため、トランザクションから除外できます。オブジェクトをトランザクションから除外することで、トランザクションに課せられる処理のオーバーヘッドを最小化します。
Registrarオブジェクトがトランザクションに関与するようにするために、ICFファイルは、
Registrarインタフェースに対して
alwaysトランザクション・ポリシーを指定します。したがって、Transactionサンプル・アプリケーションでは、ICFファイルで、
Registrarインタフェースに対して次のオブジェクト・ポリシーを指定します。
RegistrarFactoryオブジェクトをトランザクションから除外するために、ICFファイルは
Registrarインタフェースに
ignoreトランザクション・ポリシーを指定します。したがって、Transactionサンプル・アプリケーションでは、ICFファイルで、
RegistrarFactoryインタフェースに対して次のオブジェクト・ポリシーを指定します。
Oracle Tuxedoシステムは、alwaysトランザクション・ポリシーを提供します。これは、オブジェクトが呼び出されたときにトランザクションがまだスコープ指定されていない場合、Oracle Tuxedoシステムがトランザクションを自動的に開始するように、そのオブジェクトのインタフェースで定義できます。そのオブジェクトの呼出しが完了すると、Oracle Tuxedoシステムは、自動的にトランザクションをコミットまたはロールバックします。サーバー・アプリケーションもオブジェクト実装も、この状態でTransactionCurrentオブジェクトを呼び出す必要はありません。つまり、Oracle Tuxedoシステムは、サーバー・アプリケーションの代わりに自動的にTransactionCurrentオブジェクトを呼び出します。
|
注意:
|
データベース・カーソルは、複数のトランザクションにまたがることができません。CORBAのUniversityサンプル・アプリケーションにあるCourseSynopsisEnumeratorオブジェクトでは、一致するコース概要をUniversityデータベースで検索するためにデータベース・カーソルが使用されています。データベース・カーソルは複数のトランザクションにまたがることができないため、 CourseSynopsisEnumeratorオブジェクトに対する activate_object()操作は一致するすべてのコース概要をメモリーに読み込みます。カーソルはイテレータ・クラスによって管理されているため、 CourseSynopsisEnumeratorオブジェクトからは見えないことに注意してください。
|
オブジェクトがデータベースの書込み操作を実行し、かつオブジェクトがトランザクションに関与できるようにする場合、alwaysトランザクション・ポリシーの割当てが、一般的にはより適した選択です。ただし、好みに合せて、
optionalポリシーを使用して、TransactionCurrentオブジェクトでの呼出しでwrite文をカプセル化できます。つまり、オブジェクトがまだトランザクション内にスコープ指定されていない場合、データを書き込む操作内で、トランザクションを開始およびコミットまたはロールバックするためにTransactionCurrentオブジェクトを呼び出し、write文の周囲にトランザクションをスコープします。これによって、データベース書込み操作がトランザクションに関与する形で処理されます。また、パフォーマンスも向上します。このオブジェクトがトランザクションのスコープ内で呼び出されなければ、すべてのデータベース読取り操作が非トランザクション型になるので、効率が高くなります。
ignoreトランザクション・ポリシーは、通常はデータをディスクに書き込まないファクトリなどのオブジェクトに適している場合があります。ファクトリをトランザクションから除外することで、そのファクトリは、トランザクションの最中でもほかのクライアントの呼出しに使用できるようになります。さらに、このポリシーを使用すると、トランザクションに関与しているオブジェクトを呼び出す際のオーバーヘッドが軽減されるので、サーバー・アプリケーションの処理効率が向上します。
オブジェクトのインタフェースにalwaysまたは
optionalトランザクション・ポリシーが適用されている場合は、サーバー・オブジェクトの
Server::initialize()操作の
TP::open_xa_rm()操作を呼び出す必要があります。リソース・マネージャは、
UBBCONFIGファイルの
GROUPSセクションにある
OPENINFOパラメータで提供された情報を基にオープンされます。デフォルト・バージョンの
Server::initialize()操作は、リソース・マネージャを自動的にオープンします。
サーバー・オブジェクトのServer::initialize()操作がXAリソース・マネージャをオープンする場合は、
Server::release()操作に次の呼出しを含める必要があります。
transactionアクティブ化ポリシーは、トランザクションの作業が完了するまで書き込まない、または書き込めないメモリー内の状態をディスクに保持するオブジェクトに適しています。
transactionアクティブ化ポリシーをオブジェクトに割り当てると、オブジェクトは、次のようになります。
transactionアクティブ化ポリシーのオブジェクトへの割当ては、次のような場合に適しています。
Oracle Tuxedoシステムがreason値としてDR_TRANS_COMMITTINGを渡す場合、オブジェクトは、必要であればTransactionCurrentオブジェクトの
rollback_only()操作を呼び出すことができます。
Tobj_ServantBase::deactivate_object()操作の内部で
rollback_only()操作を呼び出した場合、その
Tobj_ServantBase::deactivate_object()操作が再度呼び出される点に注意してください。
|
注意:
|
トランザクション・バウンド・オブジェクトは、Tobj_ServantBase::deactivate_object()操作内でトランザクションを開始したり、他のオブジェクトを呼び出したりすることはできません。トランザクション・バウンド・オブジェクトが Tobj_ServantBase::deactivate_object()操作の内部から実行できる有効な呼出しは、データベースへの書込み操作のみです。
|
|
•
|
トランザクション・バウンド・オブジェクトについては、すべての状態の処理をTobj_ServantBase::deactivate_object()操作で実行することを検討してください。これにより、 Tobj_ServantBase::deactivate_object()操作が呼び出された時点でトランザクションの結果が分かるため、オブジェクトが自身の状態を適切に扱うことが簡単になります。
|
|
•
|
トランザクション・ポリシーとしてalwaysを割り当てたオブジェクトが、クライアント・アプリケーションではなくOracle Tuxedoシステムで開始されたトランザクションに関与している場合は、次に注意してください。
|
|
•
|
TP::deactivateEnableメソッドを持つトランザクション・オブジェクトに関する次の制限に注意してください。
|
トランザクション中にTP::deactivateEnableメソッドが呼び出された場合、オブジェクトは
トランザクションの終了時に非アクティブ化されます。しかし、
TP::deactivateEnableメソッドが呼び出された時点とトランザクションがコミットされた時点の間に、オブジェクトで何らかのメソッドが呼び出された場合、そのオブジェクトは決して非アクティブ化されません。
Transactionsサンプル・アプリケーションには、ユーザー定義の例外TooManyCreditsのインスタンスが含まれています。クライアント・アプリケーションが学生をコースに登録しようとしたときに、学生が登録可能なコースの最大数を超えている場合、サーバー・アプリケーションはこの例外をスローします。クライアント・アプリケーションは、この例外を捕捉すると、学生をコースに登録するトランザクションをロールバックします。ここでは、CORBAクライアント/サーバー・アプリケーションでユーザー定義例外を定義および実装する方法について、
TooManyCreditsを例にして説明します。
