3. CORBAアプリケーション

3.1. はじめに

本編では、Transactionサービスを用いたシステムを構築するための手順について詳細に説明します。

本編の構成

本編は以下の構成になっています。

3.1. はじめに
このページです。

3.2. 基本設計
Transactionサービスを用いたシステムを構築する際にベースとなる知識について説明しています。

3.3. アプリケーション設計
Transactionサービスでのシステムで業務処理を実施するサーバアプリケーションとそれに対して要求を発行するクライアントアプリケーションの構成パターンについて説明しています。

3.4. 他社OTS製品との相互接続について
CORBAトランザクションサービスをサポートしている他社製品と相互に接続するようなシステムを構築する場合に必要となる知識や設定について説明しています。

3.5. 用語一覧
Transactionサービスの中で使用される用語についてまとめて説明しています。

3.2. 基本設計

Transactionサービスを用いると、分散トランザクションに関する複雑な処理を意識せずにビジネスロジックを記述するだけで高信頼な分散トランザクションシステムを構築することができますが、それを構築する際に基本となる知識について本章では説明していきます。

3.2.1. 基本モデル

Transactionサービスを利用したシステムにおいて、基本となると考えられるモデル形態をいくつか説明します。

3.2.1.1. トランザクションの処理形態

Transactionサービスが提供するトランザクションサービスでは、トランザクション処理アプリケーションプログラムをアプリケーションの動作形態により次のように分類します。

3.2.1.2. システム構成について

Transactionサービスでは、通信基盤にCORBA準拠のORBであるObject Brokerを採用していますので、アプリケーションがネットワーク上のどこにあるかを意識する必要はありません。ネットワーク上の最適な位置にアプリケーションを再配置することができます。

従って、Transactionサービスを使うと、1台のサーバで集中して処理を行う集中型のシステムや複数サーバ・クライアントが協調して処理を行う分散型のシステムなど、さまざまな業務形態に合わせたシステムを構築することができます。

Transactionサービスを使ったトランザクションシステムの構成は基本的に次のようなものの組み合わせになります。

3.2.1.3. サーバトランザクションモデル

サーバトランザクションモデルは、新規トランザクションの生成処理をサーバオブジェクトが行う運用形態です。クライアントアプリケーションは、サーバ上でトランザクションが実行されているかどうかを意識しません。

サーバトランザクション型

詳細は[3.3.1. システム構成 > 3.3.1.1. サーバトランザクションの場合]を参照してください。

3.2.1.4. クライアントトランザクションモデル

クライアントトランザクションモデルは、新規トランザクションの生成処理はクライアントアプリケーションで行う運用形態です。 主にrichクライアントの形態で使用します。

クライアントトランザクション型

詳細は[3.3.1. システム構成 > 3.3.1.2. クライアントトランザクションの場合]を参照してください。

3.2.1.5. 複合形態モデル

複合形態モデルは、上記の2つの形態(サーバトランザクション、クライアントトランザクション)を自由に組み合せた運用形態です。

複合形態モデル型

詳細は[3.3.1. システム構成 > 3.3.1.3. 複合トランザクションの場合]を参照してください。

3.3. アプリケーション設計

本章では、WebOTXを使ったクライアントアプリケーション、およびサーバアプリケーションの設計について、パターンごとに説明しています。


3.3.1. システム構成

Transactionサービスを使ったトランザクションシステムの構成について説明します。 Transactionサービスは2フェーズコミットにより複数のデータベースを確実に更新するとともに、アプリケーション障害等に対してもトランザクションの更新/破棄を完全に行なうため堅牢なトランザクションシステムを構築することができます。次の図は、Transactionサービスを使ったトランザクションシステムにおけるプロセスの構成を示しています。

システム構成図


構成 説明
クライアントAP クライアントシステム上に存在し、サーバアプリケーションの呼び出しを行うアプリケーションプログラムが動作するプロセスです。三層モデルのプレゼンテーション層に相当するアプリケーションプログラムであり、richクライアントやthinクライアントのServlet/JSPがこれに相当します。これらは利用者がC++言語やJava言語、VB言語で作成します。
サーバAP APサーバ上に存在し、データベースの更新などトランザクション処理を実際に行うサーバオブジェクトが動作するプロセスです。三層モデルのファンクション層に相当しサーバオブジェクトは利用者がC++言語やJava言語で作成します。
Currentライブラリ アプリケーション上に位置し、CORBAトランザクションサービスで規定されている Currentインタフェース暗黙的な伝播 を提供します。利用者は、クライアントアプリケーションやサーバアプリケーションで、このCurrentインタフェースを利用してトランザクションの開始や終了を行います。
Recovery Coordination Server
(RCS)
トランザクションの異常発生時にリカバリ処理を行うプロセスです。サーバAPの障害を検出して自動的にリカバリを開始します。
ProxyRCS
クライアントアプリケーションで開始されたトランザクションの情報を管理します。richクライアントがトランザクションを実行する場合に使用します。
名前サービス

Object Brokerが提供しているサービスで、 CORBA で規定されている名前サービスを実装しています。クライアントアプリケーションはProxyRCSを使用する場合、名前サーバを使用します。
名前サービスを動作させるコンピュータは、Object Brokerの設定で自由に決めることができます。
データベース 三層モデルのデータベース層に相当しアプリケーションが更新・参照を行うデータベースです。データベースには、Oracle、SQL Serverがあります。また、キュー制御にMQSeriesを利用できます。

3.3.1.1. サーバトランザクションの場合

サーバトランザクションの場合、トランザクションの処理を全てサーバAPで実行します。クライアントAPはサーバAPでトランザクションが実行されているかどうかを意識する必要がないため、プレゼンテーション部分の処理になります。そのため基本的な三層モデルのシステムではこの構成を使用します。

サーバAPが複数のデータベースを更新する場合にこの形態を使用します。この形態ではクライアントからの一回の呼び出しでトランザクションは実行され更新されます。そのためトランザクションは一箇所のサーバに集約されるため管理が容易になりますがトランザクションの処理が1つのコンピュータに集中するためクライアントの台数に応じてコンピュータのスペックを決定する必要があります。サーバオブジェクトがアクセスするデータベースはデータベースサーバ上にありますが、同じコンピュータ上にある場合もあります。

この場合サーバコンピュータにのみTransactionサービスのインストールを行ないます。

サーバトランザクション


上図ではクライアントAPは単にAPサーバ上のサーバオブジェクトを呼び出します。サーバオブジェクトはトランザクションを開始して複数のデータベースを更新した後にコミットを実行します。これらの処理はクライアントから一回の呼び出しで完了します。

[3.2.1. 基本モデル > 3.2.1.3. サーバトランザクションモデル]の図も参照してください。

3.3.1.2. クライアントトランザクションの場合

クライアントトランザクションの場合、新規トランザクションの生成処理はクライアントAPで行いますがトランザクションの情報はサーバ上のProxyRCSによって管理されます。そのためクライアント側にはRCSをインストールする必要がありません。 この形態はVBやJava Applet等のrichクライアント側や、thinクライアントのWebコンテナやServlet/JSPで複数のサーバ上のAPをトランザクションとして呼び出す場合に使用します。

この形態の場合サーバ側にトランザクション状態が保存されるので、クライアントに障害が発生した場合データベースをロールバックし、データベースのロックを解除することができます。ただしProxyRCSが動作するサーバはクライアントトランザクションを全て処理するため、クライアントの台数に応じてスペックを決定する必要があります。

この場合クライアントコンピュータにはTransactionサービス実行環境(クライアント)をインストールする必要があります。


クライアントトランザクション1

上図のクライアントAPは複数回サーバオブジェクトを呼び出し、コミットを実行します。

サーバオブジェクトがグローバルトランザクションに参加した場合はデータベースの更新を実施します。サーバAPが呼ばれると、クライアントで開始されたトランザクションにその処理を自動的に関連付けます。クライアントからトランザクションがコミットされると、このサーバオブジェクトで更新した内容がすべてコミットされます。




クライアントトランザクション2


上図のクライアントAPでAPサーバ上のトランザクションを制御しています。実際にはトランザクションの開始、サーバオブジェクトに処理を要求、トランザクションのコミットを実施します。この場合サーバコンピュータに存在するProxyRCSとサーバAPのCurrentライブラリがトランザクションを制御します。 サーバオブジェクトの動作は複数回呼び出す場合と同等です。


[3.2.1. 基本モデル > 3.2.1.4. クライアントトランザクションモデル] の図も参照してください。

3.3.1.3. 複合トランザクションの場合

複合トランザクションは、サーバトランザクションがバックエンドのサーバオブジェクトを呼び出す場合や、thinクライアントのケースでJava EEサーバ上のWebコンテナがサーバオブジェクトを呼び出す場合など多段に呼び出された複数のAPサーバ間でトランザクションを共有します。
サーバオブジェクトで新規トランザクションが生成され、サーバトランザクションの場合と同様にトランザクションの情報がバックエンドのサーバに伝達されトランザクションの更新に連動してバックエンドサーバも更新されます。

トランザクションはトランザクションを開始したアプリケーションのみが管理を行いバックエンドのサーバAPはクライアントトランザクションの場合と同様にトランザクションとしての動作Policyを決定するだけです。

この形態ではデータベースを更新する各APサーバ上にTransactionサービスをインストールする必要があります。

クライアントトランザクション


上図のサーバオブジェクト1でトランザクションを制御しています。実際にはトランザクションの開始、サーバオブジェクト2に処理を要求、トランザクションのコミットを実施します。この場合図中の2つのAPサーバの間でトランザクションが共有され、同時に2フェーズコミットが実行されます。

この形態では両方のAPサーバにRCSが存在するため、トランザクションが未完了、あるいは既に2フェーズ目において相手のAPサーバがダウンした場合でもトランザクションを完了することができます。

[3.2.1. 基本モデル > 3.2.1.5. 複合形態モデル]の図も参照してください。

3.3.2. システム構築時の注意

Transactionサービスを利用する最大の利点は、2フェーズコミットメントをサポートしている点です。そのため、複数のデータベースの同期を取って更新する場合にそれらの一貫性を保証します。

データを最適配置したシステムを簡単に作成したい場合に、Transactionサービスは非常に強力なツールになります。システムダウンや通信障害などが発生しても、Transactionサービスがデータベースの一貫性を障害発生時点の状況に合わせて、ネットワーク全体でデータベースをロールバックまたはコミットしますので、データベースの状態は完全な状態(一貫した状態)が維持されます。アプリケーションはほとんど障害に対する処理を考えなくても、簡単にシステムが構築できます。

このネットワーク全体での一貫性を提供しているのが2フェーズコミットの機能です。トランザクションの結果(コミットまたはロールバック)をハードディスク内のファイルに記憶することで、その後の障害に対して耐久性を提供しています。 ただ、次のようなシステムの場合にTransactionサービスの機能を適用せずに、ローカルトランザクションとして管理したほうが良い結果となる場合があります。


またTransactionサービスでは、ACOS Access Toolkit(AAT)が提供するJDBCドライバと連携するための「1フェーズコミット対応リソース」を実装しており、それを使用することで、2フェーズコミットメントに対応していないACOS上のトランザクションをWebOTXシステムの2フェーズコミットトランザクションに参加できる機能を提供しています。 つまり同一のトランザクションで、ACOS上のデータベースとオープンサーバ上のデータベース(Oracleなど)の同時更新を管理することができます。

ただし、本来であれば1フェーズコミットメントでの動作を前提としているものを、いわば無理やり2フェーズコミットトランザクションに参加させているため、トランザクション完了処理の際にヒューリスティックとなる可能性が高くなります。つまりトランザクション全体をコミットしていいのかロールバックしていいのかTransactionサービス(トランザクションマネージャ)で判断がつかなくなる状態となります。

トランザクションのコミット時には、まず2フェーズコミットメントに対応しているリソース群に対して第1段階(プリペア)が行われ、それが正常に完了したら、ACOS側データベースに対してAATが提供するJDBCドライバを経由してコミット要求を発行します。これの結果に従ってトランザクション全体をコミットするかロールバックするかの判断をするわけですが、例えばACOSとの通信障害などによりこれが失敗すると上述のような状態に陥ります。1フェーズコミットメントが前提のリソースに対して、プリペアが実施されずにいきなりコミット要求が発行されることによる弊害です。

通信障害が発生していたとしてもACOS上のデータ更新は正常にコミットされて完了しているかもしれません。その場合はトランザクション全体をコミットする必要があります。逆に、処理要求自体がACOS側に到達していない可能性もあります。その場合はトランザクション全体をロールバックして更新を無効にしてあげなければなりません。

最終的にはACOS上のデータベースの更新状況をログなどで判断した後に、WebOTXが提供する統合運用管理ツール、あるいは運用管理コマンドにより強制的にトランザクションを完了させる必要があります。

流れなどの詳細については [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.4. Transactionサービス ] に記述していますのでそちらをご参照ください。

3.4. 他社OTS製品との相互接続について

他社が提供するOTSシステムとの相互接続方法について説明します。

3.4.1. 概要

分散オブジェクト技術CORBAに対応したアプリケーションサーバが多くのベンダから出荷されています。同時に基幹系の情報システムといった、より高い信頼性が要求されるような業務分野にもそれが利用されるようになると考えられます。
そのため、トランザクションサービスを利用する市場が拡大し、それをマルチベンダ環境で実現することが必須技術の1つになることが予想できます。

Transactionサービスは、CORBAトランザクションサービス1.4に準拠しているので、この仕様に準拠した他社のCORBA OTS製品との接続が可能です。現実に複数社との2フェーズコミットメントを用いた相互接続試験も成功しているという実績があります。

複数OTSを用いたシステムの典型的な1例としては次のような、商品の受注システムが考えられます。

2つのOTS製品を用いたシステムの例

簡単に処理の流れを説明します。

  1. クライアントAPでは、トランザクションを開始(begin)して、AシステムのX社OTSにそれを通知します。その後顧客管理オブジェクトが呼び出されます。ここでは入力された情報をもとにデータベースAを仮更新します。
  2. 顧客管理オブジェクトではその後、Bシステム内の受注管理オブジェクトを呼び出します。ここでは注文した商品の在庫チェック等を実施し、データベースBを仮更新します。このときX社OTSからY社OTSに対してトランザクション情報が引き継がれて1つのグローバルトランザクションとして動作します。
  3. ここまで正常に終了すると、クライアントAPでトランザクションの終了要求(commit)を発行します。失敗した場合はロールバック要求を出して業務を失敗させます。
  4. ここで2フェーズコミット処理が2つのOTSにより実施されます。コミットの延長でデータベースを正式に更新し、トランザクションは完了します。

3.4.2. 接続方法

上記の例の場合、Aシステムでは、Bシステム内の受注管理オブジェクトを呼び出すために、そのリファレンスを入手する必要があります。入手の方法として主なものに、次の2つが考えられます。

CORBA名前サービスは仕様があいまいな点が多いため、各ORBベンダ毎に独自の実装を行っている場合が多く、相互接続できないケースが頻繁に起こります。OMGではこれを改善するためにこれを進化させた仕様である「インターオペラブル名前サービス(INS)」を提唱しています。これをX社ORBとY社ORBの両方がサポートしていれば、この手段は有効になります。

実際の方法について説明します。

3.4.2.1. Bシステム側

リファレンスをファイルに格納する形式
BシステムのサーバAPを起動して受注管理オブジェクトを作成する際に、このオブジェクトリファレンスを文字列化し、ファイルに格納して、それをAシステム側で参照します。サーバAPのプログラミング例の一部を次に示します。エラー処理は省いています。

IDLファイル
 interface test : CosTransactions::TransactionalObject {
        void method();
 };


メイン処理部分
 #include "iostream"
 #include "fstream"
 #include "stdio"
 #include "orb.h"
 ……

 int main(int argc, char **argv) {
   ……
   // ORB、POA(rootPOA)の初期化等

   ……
   // オブジェクトリファレンスの生成
   test* p = new test();
   CORBA::Object_var o = rootPOA->servant_to_reference(p);
   test_ptr tp = test::_narrow(o);

   // 文字列に変換
   CORBA::String_var str = ORB->object_to_string(tp);
   
 #define DEF_FILE  "ior.dat" 
   // ior.datという名前のファイルに格納
   ofstream strm(DEF_FILE);
   strm &st str << endl;
   strm.close();
   ...

 };


インターオペラブル名前サービスを使用する形式
BシステムのサーバAPで、受注管理オブジェクトのリファレンスをインターオペラブル名前サービスに登録する場合、次のようなプログラミングになります。登録作業自体は、提供しているサンプルプログラムと同様に名前サービスのインタフェースを使用します。

なおここでは、リファレンスを格納するための名前サーバが動作するマシンはBシステム内に存在するケースを考えることにします。

 #include "orb.h"
 ……

 int main(int argc, char **argv) {
   ……
   // ORB、POA(rootPOA)の初期化等

   ……
   // オブジェクトリファレンスの生成
   test* p = new test();
   CORBA::Object_var o = rootPOA->servant_to_reference(p);
   test_ptr tp = test::_narrow(o);

   // インターオペラブル名前サーバに登録
   // 実際は名前サービスへの登録と同じ要領

   // NamingServiceオブジェクトリファレンスの取得
   CORBA::Object_var obj = 
       orb->resolve_initial_references("NameService");
   CosNaming::NamingContext_var nmctx = 
       CosNaming::NamingContext::_narrow(obj);

   CosNaming::Name test;
   test.length(1);
   test.id = (const char*)"test";
   test[0].kind = (const char*)"";
   nmctx->bind(test, tp);
   ...
 };


3.4.2.2. Aシステム側

リファレンスをファイルに格納する形式
Aシステム側から、Bシステムのオブジェクト呼び出しを実施するために、そのオブジェクトリファレンスを取得します。Bシステム側で作成した"ior.dat"ファイルからオブジェクトリファレンスを取り出します。プログラミング例の一部を次に示します。

 #include "stdio.h"
 #include "stdlib.h"
 #include "string.h"
 #include "orb.h"
 ……

 int main(int argc, char **argv) {
   ……
   // ORBの初期化等

   ……

 #define DEF_FILE  "ior.dat" 
   // ファイルから文字列を取得
   FILE *fp = fopen(DEF_FILE, "r");

 #define BUFFER_SIZE 1024
   char buffer[BUFFER_SIZE], *bp;
   fgets(buffer, BUFFER_SIZE, fp);
   fclose(fp);
   if (bp = strchr(buffer, '\n'))
        *bp = '\0';

   // オブジェクトリファレンスに変換
   CORBA::Object_var o = ORB->string_to_object(buffer);
   test_ptr tp = test::_narrow(o);
   ...
   // tpを用いてBシステムのオブジェクト呼び出しを実施
   ...
 };


インターオペラブル名前サービスを使用する形式
Bシステムのオブジェクトリファレンスを取得します。Aシステム側ではBシステムで動作する名前サーバにアクセスして目的のオブジェクトリファレンスを取り出します。プログラミング例の一部を次に示します。インターオペラブル名前サービスの詳細については、「Object Broker マニュアル」を参照してください。

 #include "orb.h"
 ……

 int main(int argc, char **argv) {
   ……
   // ORBの初期化等

   ……

   // インターオペラブル名前サーバから目的のリファレンスを取得
   CORBA::Object_var obj = 
       orb->string_to_object(
           "iiopname://Y社名前サービスのホスト名/test");
   test_ptr tp = test::_narrow(o);
   ...
 };

3.5. 用語一覧

ACID特性 原子性(Atomicity)、一貫性(Consistency)、隔離性(Isolation)、永続性(Durability)の4つのトランザクション特性を示します。
Atomicity(原子性) トランザクションのACID特性の1つです。結果が成功か失敗の2通りしかとれない分解不能な最小単位であることです。
Consistency(一貫性) トランザクションのACID特性の1つです。結果が部分的に異なることなく、一貫したものになることです。
Controlオブジェクト Controlインタフェースを提供するオブジェクトです。
Controlインタフェース トランザクションコンテキストを代表するトランザクションサービスの提供するインタフェースです。Controlインタフェースによって明示的にトランザクションコンテキストを管理することができます。
Coordinatorオブジェクト Coordinatorインタフェースを提供するオブジェクトです。
Coordinatorインタフェース トランザクションコンテキストに対してトランザクション参加者が操作するためのトランザクションサービスが提供するインタフェースです。トランザクション情報の取得、トランザクションの比較、トランザクションへのリソースの登録などを行うことができます。
CORBA (Common Object Request Broker Architecture) OMGが定めたオブジェクト指向に基づく分散システム構築のための共通仕様です。
CORBA標準例外 ORBが標準としてサポートする例外です。オペレーションの記述で宣言をしなくてもリクエストはこれらの例外を返すことができます。
Currentオブジェクト Currentインタフェースを提供するオブジェクトです。
Currentインタフェース 間接的なコンテキスト管理を提供するトランザクションサービスのインタフェースです。トランザクションの開始、コミット、ロールバックなどを行うことができます。
Durability(永続性) トランザクションのACID特性の1つです。結果は障害などに影響を受けずに永久に保存されます。
Heuristic決定
ヒューリスティック決定
トランザクションの結果が決定する前に人為的にトランザクションの結果をコミットまたはロールバックに決定することです。Heuristic決定が行われると一貫性は保証されません。
IDL(Interface Definition Language) CORBAオブジェクトのインタフェースを共通に定義するためのインタフェース言語です。
INVALID_TRANSACTION標準例外 リクエストが不正なトランザクションコンテキストを運んだことを通知するための標準例外です。
Isolation(隔離性) トランザクションのACID特性の一つです。並列して実行される他のトランザクションによって影響を受けません。
OMG(Object Management Group) 分散オブジェクト環境に関する仕様開発と普及を目的とする非営利団体です。
RecoveryCoordinatorオブジェクト RecoveryCoordinatorインタフェースを提供するオブジェクトです。
RecoveryCoordinatorインタフェース リカバラブルオブジェクトが状態を回復するための処理をトランザクションに対して要求するためのインタフェースです。
Resourceオブジェクト Resourceインタフェースを提供するオブジェクトです。利用者が作成します。
Resourceインタフェース トランザクションを完了するときに使用する2フェーズコミットメントプロトコルを利用するためのインタフェースです。
SubtransactionAwareResourceオブジェクト SubtransactionAwareResourceインタフェースを提供するオブジェクトです。利用者が作成します。
Subtransaction Aware Resourceインタフェース ネストされたトランザクション動作を実装するリカバラブルオブジェクトはSubtransactionAwareResourceインタフェースと呼ばれるResourceインタフェースを特殊化したものをサポートします。リカバラブルオブジェクトは、トランザクションサービスに対してSubtransactionAwareResourceインタフェースを提供するオブジェクトを登録することによって、サブトランザクション完了の通知を受けることができます。
Synchronizationオブジェクト Synchronizationインタフェースを提供するオブジェクトです。
Synchronizationインタフェース 同期プロトコルを提供するインタフェースです。同期プロトコルはコミット/ロールバックの開始前と完了後にこのインタフェースで定義されたメソッドが呼び出されます。
Terminatorインタフェース トランザクションをコミットまたはロールバックするためのオペレーションをサポートします。一般的にこれらのオペレーションはトランザクション生成者によって利用されます。
TransactionalBaseインタフェース WebOTX Transaction Service上で動作するアプリケーションの特別なインタフェースで、サーバ側のアプリケーションでデータベースを使用可能となります。
TransactionalObjectインタフェース オブジェクト自身がトランザクショナルであることをトランザクションサービスに通知するためにのインタフェースです。サーバオブジェクトがこのインタフェースを派生することでトランザクショナルオブジェクトとみなされます。
TransactionFactoryインタフェース Controlオブジェクトを生成するためのファクトリインタフェースです。直接的なコンテキスト管理でトランザクション生成者がトランザクションを開始するときに使います。
TransactionServiceインタフェース WebOTX Transaction Service固有のトランザクションサービスを表現するインタフェースです。トランザクションサービスの初期化、データベースの登録などを行うことができます。
TRANSACTION_REQUIRED標準例外 アクティブなトランザクションが要求されているのに空のトランザクションコンテキストを伝播したことを示す標準例外です。
TRANSACTION_ROLLEDBACK標準例外 関連するトランザクションがすでにロールバックしたまたはロールバックをマークしたことを示す標準例外です。
XID トランザクション識別子
1フェーズコミット トランザクションに登録されているリソースが1つである場合、リソースに対して直ちにコミットを要求します。
2フェーズコミット トランザクションに登録されているリソースが複数の場合、リソース全体のコミットを実現します。1つでもリソースがコミットできなければトランザクションはロールバックされます。
1フェーズコミット対応リソース トランザクションに登録されるリソースのうち、1フェーズコミットメントにしか対応していないリソースをさします。2フェーズコミットメントに対応していないデータベースにアクセスするために使用されますが、WebOTXが提供するTransactionサービスでは、それをグローバルトランザクションに参加させ、2フェーズコミットメントに対応したリソースとの調整(データベース同時更新)を可能にするための機構を提供しています。
アンチェックドトランザクション チェックドトランザクションを行わないことです。トランザクションの完全性の保証はアプリケーションに任されます。
暗黙的な伝播 トランザクションサービスがクライアントアプリケーションのスレッドに関連付けられたトランザクションコンテキストをサーバオブジェクトに転送することです。これにより、サーバオブジェクトはクライアントアプリケーションに関連付けられていたトランザクションに参加します。
オープン文字列 リソースマネージャの初期化時に指定する文字列です。オープン文字列中に指定する内容はリソースマネージャ毎に異なります。
オブジェクト 個々に区別することができるものや概念を「構造」と「動作」として一つにまとめた単位で抽象化したもののことです。
干渉 暗黙の伝播でサーバオブジェクトとのインタフェースを効率的に中継することです。転送されるネットワークメッセージの数を最小化することができます。
間接的なコンテキスト管理 トランザクションの管理をCurrentインタフェースで行うことです。これにより、簡単なインタフェースでトランザクションの開始・終了が行えます。
クローズ文字列 リソースマネージャの終了時に指定する文字列です。クローズ文字列中に指定する内容はリソースマネージャ毎に異なります。
グローバルトランザクション システム内で分散して実行されるトランザクションブランチの集まりです。
コミット トランザクションが正常に終了し、トランザクション内で変更されたデータを更新することです。
コミットチェック コミットをする前にコミット要求がトランザクション生成者から発行されていることと、すべての遅延同期リクエストのリプライを受信したことをチェックします。
サブトランザクション トップレベルトランザクションまたはサブトランザクションから生成されたトランザクションのことです。
スケルトン サーバアプリケーションが提供するメソッドルーチンへのディスパッチングルーチンを提供するものです。スタブと同様にIDLコンパイラでコンパイルすることにより生成されます。
スタブ クライアントプログラムにIDLで定義されたオペレーション群へのアクセスを提供するルーチン群のことです。IDLコンパイラでコンパイルすることにより生成されます。
チェックドトランザクション X/OpenのDTPトランザクションモデルと同一の完全性を保証するためにトランザクションサービスインタフェースの使用に制約を設けて動作することです。チェックドトランザクションにはリプライチェック・コミットチェック・レジュームチェックがあります。
直接的なコンテキスト管理 トランザクションの管理にCurrentオブジェクトを使わずに直接Controlオブジェクトや他のオブジェクトにアクセスして行います。
伝播 サーバアプリケーションオブジェクトの呼び出し時にターゲットオブジェクトに対してトランザクションを伝達することです。
トップレベルトランザクション トランザクション生成者によって新規に作成されたトランザクションのことです。
トランザクショナルオブジェクト トランザクションの中で呼び出されることにより動作が影響を受けるオブジェクトです。
トランザクショナルクライアント 1つのトランザクションの中で多くのトランザクショナルオブジェクトのオペレーションを呼び出すことができるプログラムです。
トランザクショナルサーバ リカバラブルオブジェクトではないトランザクショナルオブジェクトの集合です。
トランザクション ACID特性を持つ仕事の単位です。コミットまたはロールバックで終了します。
トランザクションコンテキスト トランザクションのさまざまな状態を管理する論理的な概念で、Controlオブジェクトに対応します。
トランザクションサービス CORBAトランザクションサービスをアプリケーションに提供するシステムです。WebOTX Transaction ServiceはNECの提供するトランザクションサービスです。
トランザクション生成者 トランザクションを生成するトランザクショナルクライアントのことです。
トランザクションブランチ スレッド毎かつリソースマネージャ毎に生成される最小のリカバリ単位です。
トランザクションモデル CORBAトランザクションサービスではフラットトランザクションとネストトランザクションの2つのトランザクションモデルがあります。
ネストトランザクション 親子関係をもつ多段のトランザクションを実現するモデルです。
非トランザクショナルオブジェクト トランザクションの結果に関連を持たずにデータを更新できるオブジェクトです。
非トランザクショナルクライアント トランザクションの制御を行わないプログラムです。
フラットトランザクション 単一のトランザクションを実現する基本的なモデルです。
明示的な伝播 トランザクションサービスがトランザクションコンテキストを転送するのではなく、アプリケーションがオペレーションの引数で直接トランザクションコンテキストを示すオブジェクトを転送します。
リカバラブルオブジェクト トランザクショナルオブジェクトの中でトランザクションの結果(コミットとロールバック)により、影響を受 けるデータを持つものです。
リカバラブルサーバ 一つ以上のリカバラブルオブジェクトを含むオブジェクトの集合です。
リソースオブジェクト トランザクション処理の対象となるリソースを代表するオブジェクトです。
リプライチェック リクエスト中で実行したすべての遅延同期リクエストのリプライを受信していることを、リプライを返す前に確認するチェックです。
レジュームチェック トランザクションコンテキストが以前にスレッドと関連付けられていたことを、レジューム前に確認するチェックです。
ローカルトランザクション グローバルトランザクションに参加しないトランザクションです。トランザクションサービスの範囲外で動作します。
ロールバック トランザクションが失敗し、変更のあったデータをトランザクション開始前の状態に戻します。