次の方法で共有

トランザクション処理の概念と DTC

  • [アーティクル]

デスクトップおよびビジネス システム部門からの白書

トピック

はじめに
ACID プロパティ
実行のシナリオ
アプリケーション プログラマの観点から見たトランザクション
リソース マネージャの観点から見たトランザクション
トランザクション マネージャの観点から見たトランザクション
分散トランザクション
概念のまとめ

はじめに

アプリケーションの作成は簡単ではありませんが、時代と共に大規模なアプリケーションの構築を可能にする概念や技術が発明されています。アプリケーションを独立したモジュールとして構造化するモジュラリティ (モジュール化) の考え方は、単純な部品からより複雑なシステムを構築することや、ソフトウェアの再利用を可能にしました。モジュール型アプリケーションの記述を可能にするのが、オブジェクト指向の概念と Microsoft コンポーネント オブジェクト モデル (COM) です。

アプリケーションをコンポーネントとして構造化すると、個々の部品を 1 台のコンピュータにまとめて常駐しておくことができます。または、ネットワークを経由してリモート プロシージャ コールを使用して互いにやり取りできます。したがって、コンポーネントはモジュラリティだけでなく、一般的な分散の概念も実現します。

アプリケーションを独立したコンポーネントの集まりとして構造化する場合、コンポーネントの管理が問題になることがあります。コンポーネント構造ではない単一構造のアプリケーションは、それ自体を 1単位として障害を起こし、再起動されます。しかし、モジュール型システムでは、ある 1 つのコンポーネントの障害がほかのコンポーネントに影響を与えてはならず、障害を分離してその影響を制限できるような、何らかの手段が求められます。モジュール型の実行を提供し、それによって障害処理の単純化と自動化を実現するのがトランザクションです。トランザクションによって、単純な実行フレームワークの概念が開発者とユーザーの双方に提供されます。

ユーザーにとってのトランザクションとは、発生の有無を特定できる単一の変化を示すイベントです。一方、開発者にとってのトランザクションとは、分散処理への参加が可能なモジュールを記述できるプログラミング スタイルです。たとえば、ある銀行口座から別の銀行口座にお金を振り替えることを考えます。開発者とユーザーは、必ず両方の口座がどちらも変更されるか、またはどちらも変更されないことを期待しています。このような処理を分散システムで実現することは困難であり、コンピュータに障害が起きた場合にメッセージが失われる可能性があります。トランザクションは、 1 組の操作をそれ以上分解できない原子的な 1 実行単位にまとめる手段を提供します。

このような原子的あるいは "オール オア ナッシング" 的な考え方は決して目新しいものではなく、日常生活のいたるところで見受けられます。たとえば、条件付発行証書に関する契約を行う際、証書の責任者がその取引を調整します。責任者は各当事者の署名を集め、全員の署名の完了を公表した時点で契約が成立します。結婚式で牧師は、まず新郎と新婦の双方に "汝はこの者を配偶者とするや否や?" とたずね、二人が "はい" と答えたらその時点で二人の結婚を明言します。映画の舞台監督は最初に "セット準備 OK?" とたずね、スタッフ全員が "OK" と答えたら監督は "アクション!" と叫びます。帆船の操舵手は、船の上手回しを準備するときにまず乗組員に "準備はよいか?" とたずね、全員が "準備よし" と答えたら、"下手舵!" と叫んで船の方向を変えます。

以上の例はいずれもトランザクションの基本原則である、"複数の独立した実体がすべて同意しなければならない" ということを示しています。同意しない当事者が 1 人でもいれば取引は成立しません。しかしいったん全員が同意すれば取引は成立します。Microsoft 分散トランザクション コーディネータ (MS DTC) は、COM アーキテクチャにおける自分以外のコンポーネントに対して、このようなトランザクションの調整を行います。

MS DTC の用語では、監督に当たるものをトランザクション マネージャと呼びます。また、トランザクションでは、トランザクションによって保護されるリレーショナル データベースなどのリソースを実装しますが、そのような意味合いからトランザクションへの参加者をリソース マネージャと呼びます。

アプリケーションでは、トランザクション マネージャの BeginTransaction メソッドを呼び出してトランザクションを開始します。これにより、トランザクションを表すトランザクション オブジェクトが作成されます。次に、アプリケーションはリソース マネージャを呼び出して、トランザクションの作業を実行します。

アプリケーションから個々のリソース マネージャを初めて呼び出すと、アプリケーションの現在のトランザクションが識別されます。たとえば、アプリケーションでリレーショナル データベースを使用していれば、アプリケーションは ODBC インターフェイスを呼び出します。一方、ODBC インターフェイスはトランザクション オブジェクトを ODBC 接続に関連付けます。これ以降、トランザクションが終了するまでの間、その接続を経由して行われるすべてのデータベース呼び出しがトランザクションの代わりとして実行されるようになります。

リソース マネージャは、トランザクションの代わりとして初めて作業を行う際に、トランザクション マネージャを呼び出すことでトランザクションに "エンリスト" します。トランザクションの処理中、トランザクション マネージャはトランザクションにエンリストしている各リソース マネージャを追跡します。

通常、アプリケーションは Commit トランザクション メソッドを使用してトランザクションを完了します。完了できなかった場合、アプリケーションは Abort トランザクション メソッドを呼び出し、トランザクションの動作を取り消します。アプリケーションが失敗した場合は、MS DTC がトランザクションをアボート (中止) します。

アプリケーションがトランザクションの作業を正常に完了できたときは、MS DTC を呼び出してトランザクションを "コミット ( 許可 )" します。すると、MS DTC は "2 フェーズ ** コミット ** プロトコル" を使用して、エンリストしているすべてのリソース マネージャをコミットさせます。この 2 フェーズ コミット プロトコルによって、すべてのリソース マネージャがトランザクションをコミットすること、またはアボートすることが保証されます。第 1 フェーズでは、MS DTC は個々のリソース マネージャに対してコミットの "準備" ができているかどうかをたずねます。すべての参加者が "はい" と応答したら第 2 フェーズに移行し、すべての参加者にコミット メッセージをブロードキャスト (一斉送信) します。どれか 1 つでもトランザクションが失敗した場合、またはリソース マネージャが準備要求への応答に失敗した場合、あるいはリソース マネージャが "いいえ" で応答した場合には、MS DTC はすべてのリソース マネージャに対してトランザクションがアボートされたことを通知します。

トランザクション マネージャは、ほとんどのデータベース システムにおいて重要な構成要素となっており、一部のオペレーティング システムではオプションの構成要素となっていることもあります。トランザクションは分散アプリケーションにとって欠かせない存在といえるでしょう。トランザクションは、COM のモジュール型プログラミングを補うモジュール型実行機能を提供します。このような理由から、Microsoft では Microsoft Windows 95 および Microsoft Windows NT の両方のオペレーティング システムに対応したトランザクション管理ソフトウェアを実装しています。

トランザクションの概念を COM と結び付けるためには画期的な試みが必要でした。従来のトランザクション システムでは、インストールや管理に相当な技能が必要でした。MS DTC と Microsoft オペレーティング システムとの統合では、インストール、管理、そして使用の自動化が試みられ、新しいクライアント/サーバー、オブジェクト指向、およびビジュアル管理環境を実現するために、多くの概念や技術を再開発する必要がありました。

初回リリース版の MS DTC は 1 個のリソース マネージャ、つまり Microsoft SQL Serverと連携動作します。また、Encina、Top End、TUXEDO などのいくつかのトランザクション処理監視プログラムとも連携します。MS DTC は OLE トランザクション インターフェイスを実装していますが、OLE トランザクション インターフェイスはすべてパブリックであるため、どのリソース マネージャも OLE トランザクション リソース マネージャになることが可能です。今後、Microsoft その他のソフトウェア企業から、分散オブジェクト システム、トランザクション型ファイル システム、トランザクション キュー システム、ワークフロー管理システムといった、さまざまなリソース マネージャが追加される予定です。

ACID プロパティ

トランザクションは ACID (原子性 (Atomicity)、一貫性 (Consistency)、分離性 (Isolation)、持続性 (Durability)) と呼ばれるプロパティを提供します。

原子性
トランザクションはコミットされるかアボートされるかのどちらか一方です。トランザクションがコミットされると、その結果はすべて有効になります。トランザクションがアボートされると、その結果はすべて取り消されます。たとえば、オブジェクトの名前変更では、新しい名前が作成されて古い名前が削除される (コミット) か、または何も変更されません (アボート)。

一貫性
トランザクションはシステム状態を正しく遷移する操作であり、状態に矛盾がないことを保証します。たとえば、二重リンク リストに要素を追加すると、4 つの前方ポインタおよび後方ポインタがすべて更新されます。

分離性
複数のトランザクションが同時に発生した場合、トランザクションどうしはほかの不完全なトランザクションの更新とは隔離され、それらの更新によって一貫した状態が形成されることはありません。このようなプロパティは "シリアライザビリティ ( 直列可能性 )" と呼ばれることがあります。たとえば、一貫性の二重リンク リストの例で 2 つ目のトランザクションが介入した場合、2 つ目のトランザクションからは挿入前または挿入後のリストにアクセスできますが、必ず完了した変更状態だけにアクセスできます。

持続性
トランザクションがいったんコミットされれば、その結果はシステム障害が発生したとしても有効になります。たとえば、原子性の名前変更の例では、仮にシステムに障害が発生してコミット完了の直後にリブートしたとしても、オブジェクトには新しい名前が付いています。

BeginTransaction および Commit の各トランザクション メソッドを使用して、どこからどこまでの処理をひとまとめの処理として扱い、一貫した遷移を区切るのかについては、アプリケーションに任されています。トランザクション型のリソース マネージャは、管理対象のオブジェクトの遷移についてその一貫性、分離性、そして持続性を実現します。MS DTC は、複数のコンピュータ間で分散していることが多い複数のリソース マネージャを伴うトランザクションを管理します。MS DTC はトランザクション オブジェクトを作成し、リソース マネージャ間におけるトランザクションの移行を追跡します。そして、これらのトランザクションを原子的で持続性のあるものにするために 2 フェーズ コミット プロトコルを実装します。

実行のシナリオ

エンド ユーザーの観点から見たトランザクションについては既に説明しました。トランザクションは、コミットまたはアボートのどちらか一方にされる ACID プロパティを持った実行単位です。コミットされたトランザクションの結果は持続性を持ち、アボートされたトランザクションの結果は取り消されます。ACID プロパティの実装は、アプリケーション プログラマ、リソース マネージャ、そしてトランザクション マネージャがお互いに協力し合って実現されます。これらの参加者のそれぞれの役割について具体的に見てみることにしましょう。

アプリケーション プログラマの観点から見たトランザクション

アプリケーション プログラマから見たトランザクションのモデルは、アプリケーションの実行が成功するか失敗するかというきわめて単純なものです。アプリケーションはトランザクション オブジェクトを取得して、トランザクションを開始します。それ以降の作業はすべてトランザクション オブジェクトに関連付けられます。プログラムが一貫した状態に達したら、Commit トランザクション メソッドを呼び出します。コミットが成功すれば、トランザクションは持続性のあるものとしてコミットされます。コミットが失敗した場合はトランザクションはアボートされます。プログラムがトランザクションを完了できないことを検知すると、Abort トランザクション メソッドを呼び出して、トランザクションの結果を取り消すことができます。これによって、複雑な障害の場合でも簡単に後始末処理が行えます。

トランザクションをコミットする前にアプリケーションが失敗した場合には、トランザクション マネージャがトランザクションをアボートし、エンリストしている各リソース マネージャに対してトランザクションの結果を取り消すよう指示します。コンピュータまたはリソース マネージャに障害が起きた場合にも、トランザクションはアボートされます。トランザクションのコミットが正常に完了すれば、仮にその後に障害が発生したとしても、リソース マネージャとトランザクション マネージャによって、トランザクションの結果が持続性のあるものであることが保証されます。

リソース マネージャの観点から見たトランザクション

リソース マネージャは、初めて処理を行うときに自分のローカルなトランザクション マネージャにアクセスして、自分の存在を宣言します。次に、リソース マネージャはアプリケーションからの実行要求を待ちます。実行要求が新しいトランザクション オブジェクトとともに着信すると、リソース マネージャはそのトランザクションにエンリストします。このエンリストによって、トランザクションがコミットまたはアボートされるときにリソース マネージャがトランザクション マネージャからコールバックを受け取ることが保証されます。このあと、リソース マネージャはトランザクションの要求を実行します。たとえば、リレーショナル データベース内でレコードの挿入、削除、更新などを行います。リソース マネージャでは、リソースに関するこのようなトランザクション作業の取り消しややり直しができるように、必要な情報を常に保持しています。これには多くの方法がありますが、データの複数のバージョンを保持する方法か、または変更操作のログ (ジャーナル) を保持する方法の 2 種類が一般的です。

アプリケーションがトランザクションをコミットすると、トランザクション マネージャは 2 フェーズ コミット プロトコルを開始します。最初に、トランザクション マネージャはエンリストしている各リソース マネージャに対してトランザクションのコミットの準備ができているかどうかをたずねます。リソース マネージャは必ず "コミットの準備ができている" 必要があります。つまり、トランザクションのコミットまたはアボートのどちらかを実行するために、リソース マネージャ自身が準備を整えます。

通常、リソース マネージャは古いデータと新しいデータを安定した記憶域に記録しています。そのためシステムに障害が発生した場合でも復旧できます。リソース マネージャが正しく準備できない場合はその旨をトランザクション マネージャに伝え、トランザクション マネージャはトランザクションをアボートします。リソース マネージャが正しく準備できた場合は、その旨をトランザクション マネージャに伝え、トランザクションをコミットするかまたはアボートするかというトランザクション マネージャの決定を待ちます。

準備が整ったリソース マネージャは、トランザクション マネージャからのコミットまたはアボートのコールバックを受け取るまで必ず待機します。ほとんどのトランザクションはコミットされますが、アボートされるトランザクションも少数ながら存在します。通常、準備とコミット全体のプロトコルは 1 秒未満で完了します。仮にシステムや通信に障害が発生した場合、コミットまたはアボートの通知の到着に数分あるいは数時間もかかることがあります。この間、リソース マネージャはトランザクションの結果について "不定" な状態にあり、リソース マネージャにはトランザクションがコミットされたかまたはアボートされたかはわかりません。リソース マネージャはトランザクションについて "不定" な状態にある間、トランザクションのロックによって変更されたデータを保持しており、したがってそれらの変更はほかのトランザクションとは分離されます。

ここまでの説明では、障害のない環境において分散トランザクションがどのようにして原子的にされるのかを示しました。ここで、リソース マネージャで障害が発生したときに、MS DTC の助けを借りてどのようにトランザクションを原子的で持続性のあるものにするのかについて考えてみましょう。仮にリソース マネージャで障害が起きて再起動した場合、リソース マネージャは管理しているリソースのうち、コミットされた状態にあるものを構築し直す必要があります。再構築後は、コミットされたトランザクションの結果がすべて反映され、アボートされたトランザクションの結果がまったくないような状態にする必要があります。リソース マネージャで障害が起きると、エンリストしているトランザクションのうち、障害前に準備が完了したものまたはコミットされたものを除くすべてのトランザクションがアボートされます。リソース マネージャは再起動するときに、エンリストしているトランザクションのうち不定な状態にあるものについて、その結果をトランザクション マネージャに問い合わせます。すると、トランザクション マネージャは不定な状態にあるトランザクションの個々の結果をリソース マネージャに通知し、それを受けてリソース マネージャはそれらのトランザクションを適宜コミットまたはアボートします。

以上のことから、2 フェーズ コミット プロトコルとリソース マネージャとの連携動作によって、トランザクションが原子的で持続性のあるものになることがわかります。

トランザクション マネージャの観点から見たトランザクション

トランザクション マネージャはトランザクション オブジェクトのマネージャであり、トランザクション オブジェクトを作成して、それらの原子性と持続性を管理します。アプリケーションからは BeginTransaction メソッドを呼び出すことで、トランザクション オブジェクトを作成するようトランザクション マネージャに指示します。

リソース マネージャは、初めてトランザクションに参加するときにトランザクション マネージャを呼び出してトランザクションにエンリストします。トランザクション マネージャは、トランザクションにエンリストしているリソース マネージャを追跡します。この後、アプリケーションがトランザクションをコミットまたはアボートするか、あるいはトランザクションがリソース マネージャまたは障害によってアボートされます。

Commit と Abort はトランザクション型オブジェクトにおける付加的なトランザクション メソッドです。トランザクションのコミットを要求されたときは、トランザクション マネージャは 2 フェーズ コミット プロトコルを開始します。第 1 フェーズでは、トランザクション マネージャはエンリストしているすべてのリソース マネージャに準備を要求します。第 2 フェーズでは、トランザクション マネージャはトランザクションがコミットされたかアボートされたかをリソース マネージャに伝えます。2 フェーズ コミット プロトコルは、読み取り専用最適化やコミット転送最適化など多数の最適化機能を備えています。MS DTC はこれらの最適化の一部を実装していますが、提供する原子性と持続性の機能はまったく同じです。

トランザクション マネージャはディスク上の安全な記憶域に "ログ" を保持しています。このログはトランザクション イベントを記録するシーケンシャル ファイルです。トランザクション マネージャはトランザクションの開始、エンリスト、およびコミットの決定をログに記録します。通常の処理では、トランザクション マネージャはログに対して書き込みのみを行っていますが、トランザクション マネージャで障害が発生した場合には、トランザクションの最新の状態を再構築するためにログを読み取ります。つまり、トランザクション マネージャはログを使用することで自身の状態を持続性のあるものにしています。

また、トランザクション マネージャはトランザクションを管理するための操作インターフェイスも備えています。トランザクション マネージャは、システムのパフォーマンス モニタを使用して表示できるパフォーマンス カウンタを維持し、システムのイベント ビューアで表示できる操作上の重要なイベントをシステム ログに記録しています。さらに、SQL Enterprise Manager と統合されているグラフィカルな管理インターフェイスも備えています。このインターフェイスを使用すると、オペレータはシステムの設定やトランザクションの表示、不定な状態のトランザクションのアボートまたはコミットを実行できます。

分散トランザクション

これまでの説明では、すべてのアプリケーションとリソース マネージャが 1 台のコンピュータ上に存在すると仮定していました。MS DTC は 2 台以上の Windows システムに分散されたトランザクションもサポートしています。各システムにはローカルのトランザクション マネージャが置かれます。すべてのアプリケーションとリソース マネージャは、各自のローカルのトランザクション マネージャとやり取りします。トランザクション マネージャはこれらと連携して、複数のシステムにまたがるトランザクションを管理します。

トランザクションが新しいシステムに初めて送信されると (トランザクションを伴った要求が初めてそのシステムに着信すると)、その要求に関与している 2 つのシステムの間でリレーションシップが確立されます。要求元システムはローカルのトランザクション マネージャに対し、トランザクションが要求先システム上のトランザクション マネージャに対して "送信" リレーションシップを持つことを通知します。同様に、要求先システムはローカルのトランザクション マネージャに対し、トランザクションが要求元システム上のトランザクション マネージャに対して "受信" リレーションシップを持つことを通知します。

これらの送受信のリレーションシップにより、トランザクション マネージャのリレーションシップを表すツリーが形成されます。このツリーのことをトランザクションの "コミット ** ツリー" と呼びますが、エンリストしているリソース マネージャもまた、このコミット ツリーのメンバーとなり、ローカルのトランザクション マネージャに対して送受信のリレーションシップを持ちます。

分散トランザクションがコミットまたはアボートされると、コミット ツリー上から準備、コミット、およびアボートのメッセージが外部に発信されます。ツリーのどのノードにおいても、第 1 フェーズで送信された準備要求を受け入れる前であればいつでもトランザクションをアボートできます。ノードの準備が完了すると、コミット コーディネータからトランザクションのコミットまたはアボートの指示があるまで、ノードは準備完了および不定な状態のままになります。コミット ツリーのルートのトランザクション マネージャはグローバルな "コミット ** コーディネータ" となり、トランザクションをコミットするかまたはアボートするかを決定します。コミット コーディネータが不定な状態になることは決してありません。

コンピュータに障害が発生して再起動した場合、そのコンピュータのトランザクション マネージャは不定な状態にあるすべてのトランザクションの結果を判断します。トランザクション マネージャは自身のログ ファイルを読み取り、自分自身がコミット コーディネータとなったトランザクションの結果を判断します。ほかのシステムから送信された受信トランザクションについては、トランザクション マネージャは自身のログ ファイルを読み取り、そのトランザクションの結果が以前に通知されていたかどうかを判断します。不定な状態のままの受信トランザクションについては、トランザクション マネージャはその結果を知るために受信側のトランザクション マネージャに問い合わせます。同時に、トランザクション マネージャはほかのトランザクション マネージャに送られた不定な状態の送信トランザクションに関して、それらのトランザクション マネージャからの問い合わせにも応答します。このようなプロトコルは、トランザクション マネージャとリソース マネージャが再起動時に従うプロトコルとほぼ同じです。トランザクション マネージャは不定な状態にある各トランザクションの結果を調べるとともに、リソース マネージャからの問い合わせに対してトランザクションの結果を通知します。

不定な状態にあるトランザクションの処理は、分散トランザクションの場合は特に厄介です。システムや通信に障害が発生した場合、これらの不定な状態のトランザクションが長い時間放置されたままになることがあります。トランザクションが不定な状態にある間、そのトランザクションによって変更されたリソースはロックされたままであり、ほかからは利用できません。MS DTC では、あまりに長時間不定な状態にあるトランザクションについて、システム オペレータがそれらを解決できる手段を提供しています。オペレータはコミット コーディネータの存在するシステムでグラフィカル管理インターフェイスを使用し、トランザクションの結果を判断できます。また、不定な状態にあるシステムで同じくグラフィカル管理インターフェイスを使用し、不定な状態のトランザクションを強制的にコミットまたはアボートできます。システムが再接続するとき、MS DTC はオペレータによるこれらの動作を検出し、一貫性のない動作とみなしてフラグを立てます。

概念のまとめ

トランザクションは、ACID (原子的であり (Atomic)、一貫性のある (Consistent)、分離された (Isolated)、持続性のある (Durable)) と呼ばれるプロパティを持つ実行モジュールであり、COM のプログラム モジュール構造を補うものです。Microsoft 分散トランザクション コーディネータ (MS DTC) は、各コンピュータで独自にトランザクションを管理するトランザクション マネージャを提供します。アプリケーションは BeginTransaction によりトランザクション マネージャを呼び出してトランザクションを "開始" します。BeginTransaction はトランザクション オブジェクトを返します。アプリケーションはトランザクション オブジェクトをリソース マネージャへの要求に付加します。リソース マネージャは、トランザクションの処理を初めて開始するときにトランザクションにエンリストします。一貫性のある状態遷移が完了すると、アプリケーションは Commit トランザクション メソッドを使用してトランザクションの "コミット" をトランザクション マネージャに要求します。アプリケーションがトランザクションを完了できない場合は、Abort トランザクション メソッドを使用してトランザクションをアボートします。アプリケーションまたは参加しているリソース マネージャで障害が発生した場合には、MS DTC がトランザクションをアボートします。

MS DTC では "2 フェーズ ** コミット" アルゴリズムが使用されます。このアルゴリズムでは、(1) エンリストしている各リソース マネージャに対してトランザクション マネージャがコミットの "準備" を要求し、(2) すべての準備が正常に完了するとトランザクション マネージャがコミットの決定をブロードキャストします。どれか 1 つのリソース マネージャで準備ができない場合は、トランザクション マネージャはトランザクションに関与している全参加者にアボートの決定をブロードキャストします。リソース マネージャは準備中の間、トランザクションがコミットされたかアボートされたかが分からない "不定な" 状態に置かれます。トランザクション マネージャはシーケンシャルな "ログ" を保持しているため、自身のコミットまたはアボートの決定が持続性のあるものになります。リソース マネージャまたはトランザクション マネージャで障害が発生した場合には、再接続時に不定な状態のトランザクションの結果について各マネージャが適切に判断します。

分散トランザクションの場合は、各コンピュータでローカルなトランザクション マネージャが置かれます。トランザクションが複数のコンピュータで動作すると、トランザクション マネージャは "送信" および "受信" の各トランザクションを追跡します。各トランザクション マネージャは、自身のコンピュータ上のローカルなリソース マネージャのために、すべてのエンリスト、準備、コミット、およびアボートの呼び出しを実行します。複数のコンピュータに分散されたトランザクションをコミットするときは、トランザクション マネージャはすべての送信側トランザクション マネージャに対して、準備、コミット、およびアボートのメッセージを送信します。分散トランザクションに関してトランザクション マネージャが不定な状態にあるときは、トランザクション マネージャはその結果を受信側のトランザクション マネージャに問い合わせます。ルートのトランザクション マネージャが不定な状態になることは決してありません。トランザクションがあまりに長い時間不定な状態に置かれている場合、システム オペレータはそのトランザクションを強制的にコミットまたはアボートできます。

Microsoft SQL Server の最新情報については、弊社の World Wide Web (https://www.microsoft.com/japan/sql/) を参照してください。

著作権等について

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

© 1996 Microsoft Corporation. All rights reserved.

Microsoft、Windows 、Windows NT Server、Microsoft SQL Server、BackOffice は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。

Encina は、Transarc Corp. の登録商標です。Tuxedo は、Novell, inc. の登録商標です。