JP2007509409A

JP2007509409A - ネットワーク上のトランザクション処理ファイルオペレーションのための方法およびシステム

Info

Publication number: JP2007509409A
Application number: JP2006536567A
Authority: JP
Inventors: ヤナマダバラププラディープ; パディカシシール; セシュラマンバラン; ヴェルマスレンドラ; カーギルジョン; ラクチュールヤコブ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-10-24
Filing date: 2004-07-22
Publication date: 2007-04-12
Anticipated expiration: 2024-07-22
Also published as: AU2010236079A1; AU2010236080A1; JP4769191B2; MXPA05006606A; US20050091187A1; KR101087415B1; WO2005045738A3; AU2010236080B2; KR20060108204A; CN1826593A; AU2004279166A8; RU2005115972A; AU2004279166A1; EP2453373A3; JP2011134351A; JP5307845B2; WO2005045738A2; CN100465937C; RU2380749C2; US7231397B2

Abstract

ネットワーク上でトランザクション処理リモートファイルオペレーションを実行するシステムは、クライアントおよびサーバを含む。このクライアントとサーバは、それぞれトランザクションマネージャ（ＴＭ）とファイルシステム（ＦＳ）を含む。クライアントはリダイレクタ（ＲＤＲ）も含むが、サーバはサーバアプリケーション（ＳＲＶ）を含む。ＲＤＲは、リモートトランザクション処理ファイルオペレーションを求める要求を受信する。それに応答して、ＲＤＲはこの要求からトランザクションを検索する。ＲＤＲは、ＴＭを使用してサーバに送信するためにこのトランザクションをマーシャリングすることができる。ＲＤＲは、ネットワーク上でトランザクションをサーバに対して送信する。ＳＲＶコンポーネントは、トランザクションを受信し、次いでサーバのＴＭおよびＦＳはこのトランザクションを使用してファイルオペレーションを実行する。次いで、サーバはネットワークを介してファイルオペレーション結果をクライアントに対して戻す。

Description

以下に説明する様々な実施形態は、一般にネットワーク通信に関し、より詳細には、それだけには限定されないが、ネットワーク上のトランザクション処理ファイルオペレーションを可能にするための方法およびシステムに関する。

トランザクションは、長い間、データベースおよびトランザクション処理システムによって提供されてきている。トランザクションは、いくつかのオペレーションを１つの原始的オペレーションに、すなわち個々のオペレーションの結果がともに有効か、または共倒れとなるというオペレーションのグループに一緒にグループ分けすることによって、アプリケーションプログラマにとって望ましい簡略化された失敗モデルを提供する。

もし、ただ１つのオペレーションが失敗する場合には、そのグループ中におけるすべてのオペレーションの効果は、そのトランザクションに関連するオペレーション数にかかわらず、「元に戻され（ｕｎｄｏｎｅ）」、あるいはロールバックされる。オペレーションの間のこの連帯（ｓｏｌｉｄａｒｉｔｙ）は、失敗の数がいくつの場合においても適用され、結局のところ各トランザクション処理システムは、これらのオペレーションのすべてが適用されている、あるいは、これらのオペレーションのいずれも適用されていないという２つの状態の内の、どちらか一方の状態に至る。

記載される様々な実施形態の態様によれば、ネットワーク上でファイルオペレーションをトランザクション処理する方法およびシステムが提供される。一態様によれば、コンピューティングプラットフォーム（すなわち、クライアント）は、ネットワークを介して、別のコンピューティングプラットフォーム（すなわち、サーバ）上のファイルに遠隔でアクセスすることができる。この態様によれば、これらクライアントおよびサーバはそれぞれ、ＴＭ（ｔｒａｎｓａｃｔｉｏｎｍａｎａｇｅｒトランザクションマネージャ）およびＦＳ（ｆｉｌｅｓｙｓｔｅｍファイルシステム）を含んでいる。このクライアントは、ＲＤＲ（ｒｅｄｉｒｅｃｔｏｒリダイレクタ）も含んでいるが、このサーバは、ＳＲＶ（ｓｅｒｖｅｒｃｏｍｐｏｎｅｎｔサーバコンポーネント）を含んでいる。

動作中においては、ＲＤＲは、リモートトランザクション処理ファイルオペレーション（ｒｅｍｏｔｅｔｒａｎｓａｃｔｅｄｆｉｌｅｏｐｅｒａｔｉｏｎ）の要求を受信する。この要求に応答して、ＲＤＲはこの要求からのトランザクションについて調べ、（例えば、一実施形態におけるこのＴＭによって）サーバへ送信するためにこのトランザクションをマーシャリングする。次いでＲＤＲは、ネットワーク上でこのトランザクション情報（例えば、一実施形態においてはマーシャリングブロブ（ｍａｒｓｈａｌｂｌｏｂ））をサーバに送信する。ＳＲＶはトランザクション情報を受信し、次いでサーバのＴＭおよびＦＳは、トランザクション情報を使用してファイルオペレーションを実施する。次いで、サーバはネットワークを介してファイルオペレーションの結果をクライアントに返送する。

他の態様においては、ＲＤＲは、１つのファイルに対して複数のリモートファイルオペレーショントランザクションがオープンであるようにすることができる。ＲＤＲがトランザクション処理リモートファイルオペレーションを求める新しい要求を受信するとき、ＲＤＲは、リモートファイルの「ダーティ（ｄｉｒｔｙ）」バージョン（すなわち、書き込まれているバージョン）が、クライアント上で知られているかどうかを判定する。次いで、ＲＤＲはファイルについて元のバージョンの代わりに、新しい要求に対するダーティバージョンを使用する。一部の実施形態においては、ＲＤＲは、１つのトランザクション処理されたライトオペレーションが所与のファイルについて一時にオープンであることを可能にするだけである。

さらに他の態様においては、ＲＤＲは、トランザクション処理されたリモートファイルオペレーションを求める新しい要求は、クライアント上ですでに知られているファイル情報を使用することができるかどうかを判定する。この同じファイル情報を使用することができる場合に、ＲＤＲは、このファイル情報のもう１つのコピーを記憶する代わりにこの同じファイル情報を使用する。

さらに他の態様においては、ＲＤＲは、所与のリモートファイルについてのトランザクションに便宜的ロックを関連づけることができる。一実施形態においては、このロックは、ローカルサーバがファイルにアクセスすることを妨げないが、サーバに、ロックが解除されているというメッセージをクライアントに対して送信させる。次いで、トランザクション処理リモートファイルオペレーションを求める新しい要求が、クライアント中にすでにキャッシュされているファイル情報を使用することができるかどうかを判定するに際し、ＲＤＲは所与のファイルについてロックが解除されたかどうかを検査することができる。

非限定的で非網羅的な実施形態について、以下の図を参照しながら説明する。別に指定をしていない限り、様々な図面全体にわたって、同一の参照番号は同一の要素を示している。

実施例のネットワーク環境
前述のように、トランザクションは、データベースおよびトランザクション処理システムにおいて使用されてきているが、以下の実施形態においては、トランザクションは、リモートファイルオペレーションのために使用される。図１は、クライアントがネットワーク１０１を介してクライアント上でファイルオペレーションをトランザクション処理することができるシステム１００を示している。図１の実施例のネットワーク環境においては、クライアント装置と呼ぶこともできる複数のクライアントコンピューティングデバイス１０５、１１０、１１５、および１２０が、ネットワーク１０１を介して少なくとも１つのサーバ装置１２５に結合されている。ネットワーク１０１は、有線ネットワークおよび／または無線ネットワークを含むことができる様々な従来のネットワークトポロジおよびタイプのいずれをも表すことが意図されている。ネットワーク１０１はさらに、パブリックプロトコルおよび／または独自開発プロトコルを含めて、様々な従来のネットワークプロトコルのうちのいずれをも利用することができる。ネットワーク１０１は、例えばインターネット、ならびに場合によっては１つまたは複数のＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋローカルエリアネットワーク）、ＷＡＮ（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋワイドエリアネットワーク）などの少なくとも一部分を含むことができる。

クライアント装置１０５は、それだけには限定されないが、デスクトップＰＣ（ｐｅｒｓｏｎａｌｃｏｍｐｕｔｅｒパーソナルコンピュータ）、ワークステーション、メインフレームコンピュータ、インターネットアプライアンス、およびゲーミングコンソール（ｇａｍｉｎｇｃｏｎｓｏｌｅ）を含めて様々な従来のコンピューティングデバイスのうちのいずれも含むことができる。さらに、ネットワーク１０１に関連するクライアント装置は、有線リンクおよび／または無線リンクによってネットワーク１０１と情報をやりとりすることができるＰＤＡ（ｐｅｒｓｏｎａｌｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ携帯型個人情報端末）１１０、ラップトップコンピュータ１１５、およびセルラ電話１２０などを含むことができる。さらにまた、１つまたは複数のクライアント装置１０５、１１０、１１５、および１２０は、これら同じタイプのデバイス、または代わりの異なるタイプのデバイスを含むことができる。

サーバ装置１２５は、コンピューティングデバイス１０５、１１０、１１５および１２０に対して、様々なデータおよび／または機能のうちのいずれも提供することができる。このデータは、パブリックに利用可能であり、あるいは代わりに制限されることもあり、例えばあるユーザだけに制限され、または適切な料金が支払われる場合にしか利用可能でないなどのこともある。

サーバ装置１２５は、ネットワークサーバ、およびアプリケーションサーバ、またはその両者による組合せのうちの少なくとも１つである。サーバ装置１２５は、コンテンツのソースとなる任意のデバイスであり、クライアント装置１０５、１１０、１１５および１２０は、このようなコンテンツを受信する任意のデバイスを含んでいる。したがって、ピアツーピアネットワークにおいて、このコンテンツのソースとなるこのデバイスは、サーバ装置と呼ばれ、このコンテンツを受信するデバイスは、クライアント装置と呼ばれる。両方のタイプのデバイスは、本明細書中で説明される実施形態の例に従って、オペレーティングシステムおよびアプリケーションを含めて、ソフトウェアプログラムをロードし実行することが可能である。さらに、データおよび機能は、クライアント装置１０５、１１０、１１５および１２０の間で共有することができる。すなわち、サービス装置１２５だけが、各クライアント装置に対するデータおよび／または機能のソースであるというわけではない。

データソース１３０または１３５において、オペレーティングシステムおよびアプリケーションを含めてソフトウェアプログラムが、実行するためにサーバ装置１２５またはクライアント装置１０５、１１０、１１５、および１２０のうちのどれか１つのために作成され、かつ／またはそのどれか１つに対して提供される。一貫性をもたせるために、以下の説明では、当技術分野において知られているように、単独または組合せのいずれでも、少なくともソフトウェアプログラム、オペレーティングシステム、およびアプリケーションのどれかを包含する「アプリケーション」について言及している。さらに、これらのアプリケーションは、データソース１３０からのものとしてオフラインで、または、データソース１３５からのものとしてオンラインで、サーバ装置１２５に対して配布される。さらにまた、これらのアプリケーションは、一般にサーバ装置１２５またはデータソース１３５からオンラインでクライアント装置１０５、１１０、１１５、および１２０に対して配布される。これらのオフラインによる配布のための手段および方法についても同様に知られている。

以下で説明する様々な実施形態によれば、共にデバイス１０５、１１０、１１５、１２０、１２５における、またはその間にあるデータおよび機能の少なくとも１つの配布は、トランザクションとして実装することができる。より詳細には、トランザクションは、図１の実施例のように、デバイス１０５、１１０、１１５、１２０、１２５のうちの１つの内部においてまたはネットワーク環境の中において、１つの原子的オペレーションとして同期してまたは非同期で実行されるオペレーションのグループである。このネットワーク上で実施されるトランザクション処理リモートファイルオペレーションの実施例について、図２〜図７とともに以下にさらに詳細に説明する。

トランザクション処理リモートファイルオペレーション
図２は、図１におけるシステム１００中の（例えば、デバイス１０５、１１０、１１５、１２０、１２５から選択される）２つのデバイスのコンポーネントを示している。これらは、トランザクション処理リモートファイルオペレーションのためのクライアント２０２およびサーバ２０４として動作する。この実施形態においては、クライアント２０２もサーバ２０４も共に、あるバージョンのＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを使用している。他の実施形態においては、異なるオペレーティングシステムを使用することができる。

この実施形態においては、クライアント２０２は、アプリケーション２１２、Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ入出力）マネージャ２１４、ファイルシステム（ＦＳ）２１６、リダイレクタセレクタ（ｒｅｄｉｒｅｃｔｏｒｓｅｌｅｃｔｏｒ）２１８、トランザクションマネージャ（ＴＭ）２２２、およびリダイレクタ（ＲＤＲ）２２０を含んでいる。この実施形態において、サーバ２０４は、サーバコンポーネント（ＳＲＶ）２３４、Ｉ／Ｏマネージャ２１４Ａ、ＦＳ２１６ＡおよびＴＭ２２２Ａを含んでいる。この実施形態において、クライアント２０２およびサーバ２０４は、ネットワーク１００（図１）を介して互いに情報をやりとりすることができる。一部の実施形態においては、これらのコンポーネントは、ソフトウェアにより実装される。

この「Ｗｉｎｄｏｗｓ（登録商標）」の実施形態において、Ｉ／Ｏマネージャ２１４および２１４Ａ、ならびにＦＳ２１６および２１６Ａは、ＮＴＦＳ（ＮＴｆｉｌｅｓｙｓｔｅｍＮＴファイルシステム）によって実装され、リダイレクタセレクタ２１８は、ＭＵＰ（ｍｕｌｔｉｐｌｅＵＮＣｐｒｏｖｉｄｅｒ複数ＵＮＣプロバイダ）によって実装され、ここでＵＮＣは、ＵｎｉｆｏｒｍＮａｍｉｎｇＣｏｎｖｅｎｔｉｏｎ（汎用名前付け規則）の頭字語である。したがって、リダイレクタセレクタ２１８は、本明細書中においてＭＵＰ２１８とも呼ばれる。さらに、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのＲＤＲおよびＳＲＶは、（追加機能とともに）それぞれＲＤＲ２２０およびＳＲＶ２３４を実装する。このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのＲＤＲおよびＳＲＶに対する追加機能の一例については、以下で説明する。さらにまた、この実施形態において、ＴＭＭ２２２およびＴＭ２２２Ａは、この実施形態の例においてはカーネルレベルトランザクションマネージャとして実装され、以下にさらに詳細に説明する。他の実施例においては、異なるＩ／Ｏマネージャ、ファイルシステム、リダイレクタセレクタ、ＴＭ、および／またはＲＤＲを使用することもできる。

図３は、クライアント２０２とサーバ２０４の間のトランザクション処理リモートファイルオペレーション（図２）についての実施例の処理フローを示している。図２および図３を参照すると、トランザクション処理リモートファイルオペレーションは、一実施形態によれば、以下のように実施される。

ブロック３０２において、ＲＤＲ２２０は、サーバ２０４中に存在するファイルに対するトランザクション処理ファイルオペレーションを求める要求を受信する。典型的なファイルオペレーションは、新しいファイルを作成する工程、ファイルを読み取る工程、ファイルを書き込む工程、ファイルをコピーする工程、ファイルの名前を変更する工程などを含んでいる。この実施形態においては、トランザクション処理ファイルオペレーションを求める要求は、アプリケーション２１２によって生成さる。このアプリケーションは、図２に示すようにユーザレベルのアプリケーションである。この要求は、トランザクションコンテキストについてのフィールドを含む構造を使用する。この要求は、Ｉ／Ｏマネージャ２１４によって受信され、このＩ／Ｏマネージャは、この要求がローカルファイルに対するものか、それともリモートファイルに対するものかを判定する。この実施形態においては、Ｉ／Ｏマネージャ２１４は、このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの標準コンポーネントである。例えば、アプリケーション２１２は、（＼＼ｓｅｒｖｅｒ＼ｓｈａｒｅ＼ｓｕｂｄｉｒｅｃｔｏｒｙ＼ｆｉｌｅｎａｍｅの形式の）このＵＮＣネームを用いて、Ｉ／Ｏマネージャ２１４への呼び出しを介して、この要求を行うことができる。次いでＩ／Ｏマネージャ２１４は、この要求をＭＵＰ２１８に渡す。トランザクションについては複数のハンドルが存在し、所与のファイルについては複数のトランザクションが存在することができる。他方、この要求がこのクライアント上のファイルを求めるものである場合には、Ｉ／Ｏマネージャ２１４は、標準的な方法によって、この要求をＮＴＦＳ２１６に渡すはずである。

次いでＭＵＰ２１８は、この要求を実施するために必要とされるリダイレクタの位置を突き止める。このケースにおいては、このリダイレクタは、ＲＤＲ２２０である。この実施形態において、ＭＵＰ２１８は、このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの標準コンポーネントである。この実施形態においては、ＲＤＲ２２０は、このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムＲＤＲの１つのバージョンであり、追加部分を用いることにより、このＲＤＲは、ＴＭ２２２と対話してトランザクションを実施することができる。この追加部分は例えば、要求からトランザクション処理ファイルオペレーションについてのトランザクションコンテキストを検索し、トランザクション処理ファイルオペレーションについてのＦＣＢを割り当て、ネットワーク上でトランザクションをリモートデバイスに送信し、（ファイル識別子およびバージョン識別子を含めて）これらのトランザクション処理ファイルオペレーションについての応答を受信し、ＴＭ２２２の指示の下にトランザクションオペレーションを実施し、ＲＤＲ２２０がトランザクションの状態に関して通知され続けることができるようにするためのＴＭ２２２をリソースマネージャとしてエンリストする（ｅｎｌｉｓｔ）機能を含んでいる。一部の実施形態においては、ＲＤＲ２２０は、同時係属の同一出願人による「Transactional File System」という名称の２０００年３月３０日に出願の、米国特許出願第０９／５３９，２３３号明細書および米国出願番号［整理番号第ＭＳ１−１７８１ＵＳ］に説明されているように実装される。リソースマネージャとしてのエンリスト（ｅｎｌｉｓｔｉｎｇ）については以下で説明する。ＲＤＲ２２０は、このトランザクションをバッファリングするためのリソース、キャッシュマップ、ＦＣＢ（ｆｉｌｅｃｏｎｔｒｏｌｂｌｏｃｋファイル制御ブロック）、ＦＯＢＸ（ｆｉｌｅｏｂｊｅｃｔｅｘｔｅｎｓｉｏｎファイルオブジェクト拡張部分）、およびこのトランザクションおよび要求を処理するために必要な他の構造を含んでいる。

ブロック３０４において、ＲＤＲ２２０は、ＴＭ２２２からこのトランザクションを検索し、このトランザクションをクライアント２０４に送信するためにマーシャリングする。一実施形態においては、ＲＤＲ２２０は、ＴＭ２２２によって表示される（その実施形態について以下で説明している）ＡＰＩを呼び出すことによってこのトランザクションを検索し、トランザクションをサポートするように拡張されている１つのバージョンのＳＭＢプロトコルを使用して送信するためにこのトランザクション情報（例えば、マーシャリングブロブ）をフォーマットすることによってこのトランザクションをマーシャリングする。例示の一実施形態のＳＭＢ拡張部分については、表１〜表３とともに以下で要約している。ブロック３０６において、ＲＤＲ２２０は、矢印２３６で示すようにこのトランザクションおよびこの要求をサーバ２０４に対して送信する。ブロック３０８において、ＲＤＲ２２０は、サーバ２０４からこのファイルオペレーションの結果を受信する。例えば、サーバ２０４は、前述のファイルおよびバージョン識別子を含むこの要求に対する応答を送信する。この実施形態においては、ＳＲＶ２３４は、このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムＳＲＶの１つのバージョンである。追加機能部分を用いることにより、このＳＲＶは、トランザクション処理リモートファイルオペレーション中にファイルおよびバージョン識別子をクライアントに対して渡すことを含め、ネットワーク上でクライアントと対話してＳＭＢに対する拡張部分を使用してトランザクションを実施することができる。

図３Ａは、一実施形態におけるブロック３０２（図３）をさらに詳細に示している。ブロック３１２において、ＲＤＲ２２０は、この要求されたファイルオペレーションについてのトランザクションコンテキストを検索する。トランザクション処理リモートファイルをオープンする際に、ＲＤＲ２２０は、トランザクションがこの要求にすでに関連づけられているかどうかを判定する。例えば、一実施形態において、トランザクションはそれをスレッド（ｔｈｒｅａｄ）にアタッチすることによって要求に関連付けられるが、他の実施形態においては、異なる方法を使用してトランザクションを要求に関連づけることができる。一実施形態においては、ＲＤＲ２２０は、この要求がそれに関連づけられたトランザクションハンドルを有するかどうかを調べるために検査することによってこのオペレーションを実施する。関連づけられたトランザクションハンドルを有する場合には、この要求は、その既存のトランザクションに加え（ｊｏｉｎ）られる。有していない場合には、ＲＤＲ２２０は、非トランザクション処理要求に対する標準的な方法でこの要求を処理する。

次いで、ＲＤＲ２２０は、この要求にＦＣＢを割り当てる。前述のように、複数の要求を有する複数のトランザクションが、所与のファイルをオープンすることもある。したがって、ブロック３０２（図３）の一実施形態においては、ＲＤＲ２２０が既存のＦＣＢをこの要求に対しても使用できるかどうかについて判定するブロック３１４が、実行される。この実施形態において、ＲＤＲ２２０は、検査して、この要求のファイル（すなわち、パスネーム）およびこの要求を作るスレッドに関連するこのトランザクションコンテキストが、既存のＦＣＢのこれらとマッチングするかどうかを調べる。例えば、第２の要求の処理中に、この同じファイルの２つの書込みオペレーションが、同じトランザクション中で要求されたとする場合には、この第１の要求のために既にＦＣＢが存在しているはずである。両方のオペレーションが共に書込みオペレーションであるので、この同じＦＣＢを両者に対して使用することができる。

ブロック３１４において、ＲＤＲ２２０が、ＦＣＢが同じトランザクションコンテキストならびに同じファイル（すなわち、パスネーム）および同じバージョンと共に存在すると判定する場合には、ブロック３１６において、既存のＦＣＢがこの要求に対して使用される。一部の実施形態において、ＲＤＲ２２０は、最新バージョンを有するＦＣＢを使用することになる。例えば、ファイルの読取りオペレーションがこの同じファイルのコミットされていない書込みオペレーションに続く場合、ＲＤＲ２２０は、この書込みオペレーションが現在使用しているファイルのこのバージョンを使用することになる。このアプローチによって、キャッシングのさらに効率的な使用が可能になる。

しかし、ブロック３１４において、この要求に対する既存のＦＣＢを使用することができない場合には、ブロック３１８においてＲＤＲは、この要求に対して新しいＦＣＢを作成する。代替的な実施形態においては、新しいＦＣＢが、要求ごとに作成される。

図４は、この同じファイルに対するコミットされない複数のトランザクション処理要求の一例を示している。図４に示すように、オペレーション４０１は、ファイルの読取りオペレーションを求める要求に対応する。すなわち、このファイルオペレーションは、「読取りのためにオープンする」オペレーションである。オペレーション４０１は、ハンドルＨ１と、このハンドルに関連付けられたトランザクションＴ１を有する。ＲＤＲ２２０（図２）が要求するこのファイルのバージョンは、バージョンＡとして示される。これがこのファイルに対しての最初のコミットされないトランザクションであると想定すると、バージョンＡは、サーバ２０４（図２）から読み出され、クライアント２０２（図２）中にキャッシュされる。

後の時刻において、オペレーション４０２がこの同じファイルに対して要求される。この例においては、オペレーション４０２も読取りオペレーションであり、ハンドルＨ２およびトランザクションＴ２を有する。このトランザクションは、オペレーション４０１のトランザクションとは異なるので、ＲＤＲ２２０は、この場合にもサーバ２０４からこのファイルのバージョンＡが読み出される。

この例においては、次いでオペレーション４０３が、オペレーション４０２と同じトランザクションにおいてこの同じファイルに対して要求される。したがって、オペレーション４０３はハンドルＨ３を有し、トランザクションＴ２に結合（ｊｏｉｎ）される。しかし、この例においては、オペレーション４０３は書込みオペレーションであり、したがってＲＤＲ２２０は、このファイルのバージョンＢをローカルに記憶している（例えば、キャッシュしている）。バージョンＢは、時として「ダーティバージョン」と呼ばれることがある。

次いでオペレーション４０４が、オペレーション４０２および４０３と同じトランザクションにおいて、この同じファイルに対して要求される。したがって、オペレーション４０４はハンドルＨ４を有し、これもまたトランザクションＴ２に結合される。この例においては、オペレーション４０４は読取りオペレーションである。この実施形態においては、ブロック３１４（図３Ａ）の結果により、ＲＤＲ２２０は、オペレーション４０４に対するバージョンＢを記憶しており、おそらくはキャッシュしていることになる。

次いで、オペレーション４０５が、異なるトランザクションにおいてこの同じファイルに対して要求される。したがって、オペレーション４０５はハンドルＨ５を有し、新しいトランザクションＴ３に関連付けられる。このトランザクションは、以前のオペレーションのトランザクションとは異なるので、一実施形態において、ＲＤＲ２２０は、この場合にもこのファイルのバージョンＡをサーバ２０４から読み出す。他の実施形態においては、ＲＤＲ２２０はサーバ２０４（図２）を調べなくても、依然としてバージョンＡが現行バージョンであることを認識しており、この「ローカル」バージョンＡを使用する。例えば、この代替的な実施形態では、便宜的ロックを使用してサーバ２０４中に存在するこのファイルのどのような新しいバージョンについても知ることができるようになる。すなわち、ＲＤＲ２２０は、サーバ２０４上のファイルに対する書込みを妨げることのない便宜的ロックを、このファイルに関連付けることができるが、サーバ２０４は、このロックが解除されたことをＲＤＲ２２０に信号で伝えるようにする。このようなケースにおいては、次いでＲＤＲ２２０は、バージョンＡはもはや最新のバージョンではないことを知るはずである。さらに他の実施形態においては、ＲＤＲ２２０は、サーバ２０４に照会してこのファイルの最新バージョンを決定し、次いでこの最新のバージョンに関連付けられた既存のＦＣＢを再使用することができる。

次いで、オペレーション４０６において、トランザクションＴ２がコミット（ｃｏｍｍｉｔ）される。これは、サーバ２０４上でこのバージョンを変更する効果を有する。サーバ２０４上に記憶されるこの新しいバージョンは、バージョンＣとして示される。前述したように、ＲＤＲ２２０は、すべてのリモートトランザクション中にリソースマネージャとしてエンリストするので、ＲＤＲ２２０は、サーバ２０４がこのファイルの新しいバージョンを有することを学習する。

次いで、オペレーション４０１と同じトランザクションにおいてこの同じファイルに対して、オペレーション４０７が要求される。したがって、オペレーション４０７はハンドルＨ６を有し、トランザクションＴ１に結合される。しかし、ＲＤＲ２２０はサーバ２０４上のこのファイルのバージョンＣを知っているので、ＲＤＲ２２０は、このオペレーションに対するバージョンＣを記憶しており、おそらくキャッシュしている。一部の実施形態においては、ＲＤＲ２２０は、サーバ２０４からバージョンＣを読み出す。

同様に、オペレーション４０５と同じトランザクションによってこの同じファイルに対して、オペレーション４０８が要求されるとき、オペレーション４０８はハンドルＨ７を有し、トランザクションＴ３に結合される。この場合にも、ＲＤＲ２２０がサーバ２０４上のこのファイルのバージョンＣについて知っているので、ＲＤＲ２２０は、このオペレーションに対するバージョンＣを記憶しており、おそらくキャッシュしている。

図５は、一実施形態に従って、クライアント２０２（図２）からのキャッシュされたデータがどのようにしてサーバ２０４（図２）にフラッシュされるの（すなわち、永続的に記憶される）かを示している。図２および図５を参照すると、クライアント２０２は、一実施形態によれば、以下で説明するようにサーバ２０４にデータをフラッシュする。

ブロック５０２において、このデータを生成するアプリケーションは、呼出しを行うか、あるいはこのトランザクションをコミットする要求を発行する。この呼出しまたは要求は、ＴＭ２２２に渡される。それに応答して、ＴＭ２２２は、（この実施例のトランザクションマネージャに関して以下で説明する）プリプリペア通知（Ｐｒｅ−ｐｒｅｐａｒｅＮｏｔｉｆｉｃａｔｉｏｎ）を生成する。

この実施形態において、ＲＤＲ２２０は、ブロック５０４に示すようにＴＭ２２２からこのプリプリペア通知を受信する。それに応答してＲＤＲ２２０は、このネットワークを介してこのデータをＳＲＶ２３４に対してフラッシュする。ＳＲＶ２３４は、次にこのデータをＮＴＦＳ２１６Ａに渡す。これらのオペレーションは、ブロック５０６によって示される。一部の実施形態においては、サーバ２０４のＴＭ２２２Ａは、いつこのプリプリペアオペレーションが完了するかについてＲＤＲ２２０に信号で伝える。ブロック５０４および５０６は、（実施例のトランザクションマネージャに関して以下で説明する）プリペア（Ｐｒｅｐａｒｅ）オペレーションが実施される以前に、サーバ２０４に書き込むべきクライアント２０２からのデータが、サーバ２０４上に存在するようにするのを助ける。

ブロック５０８において、ＲＤＲ２２０は、（実施例のトランザクションマネージャに関して以下で説明する）プリペア通知をＴＭ２２２から受信する。一実施形態においては、ＲＤＲ２２０は、このプリペア通知に応答してプリペア通知メッセージをサーバ２０４に送信し、このプリペア通知は、ＴＭ２２２Ａに渡される。次にＴＭ２２２Ａは、このプリペア通知をＮＴＦＳ２１６Ａに渡す。これらのオペレーションは、ブロック５１０および５１２によって示される。このプリペア通知は、クライアント２０２およびサーバ２０４が、このデータをコミットし、またはロールバックすることができるような方法で、このデータを記憶するようにする。一部の実施形態においては、サーバ２０４のＴＭ２２２Ａは、ＲＤＲ２２０にいつこのプリペアオペレーションが完了するかを信号で伝える。次いで、このデータは、ブロック５１４で示すように、標準の２相コミットオペレーション（例えば、このトランザクションをコミットし、または、中止するオペレーション）を使用して処理される。

以上では、トランザクションマネージメントは、別々のＴＭコンポーネント（すなわち、ＴＭ２２２およびＴＭ２２２Ａ）を使用して実施されるものとして説明しているが、他の実施形態においては、このトランザクションマネージメントインフラストラクチャは、このファイルシステムインフラストラクチャに一体化することができる。さらに、このような一体化された実施形態においては、これらのトランザクションメッセージ（例えば、以下で説明するようにプリプリペア（ＰｒｅＰｒｅｐａｒｅ）、プリペア（Ｐｒｅｐａｒｅ）、コミット（Ｃｏｍｍｉｔ）、アボート（Ａｂｏｒｔ）など）は、この伝送チャネル上をファイルメッセージと共に流れる。

実施例のトランザクションマネージャ
図６は、一実施形態による、トランザクションを実施する際に使用されるコンポーネントを示している。特定のトランザクションを構成するオペレーションのグループは、少なくとも当業者には「原子性（ａｔｏｍｉｃｉｔｙ）」、「一貫性（ｃｏｎｓｉｓｔｅｎｃｙ）」、「隔離性（ｉｓｏｌａｔｉｏｎ）」、および「永続性（ｄｕｒａｂｉｌｉｔｙ）」を含む頭字語「ＡＣＩＤ」として知られている特性を、全体として有している。より詳細には、トランザクションの各オペレーションからもたらされるデータの更新は、すべて不変であるか、あるいはどれも不変でなく（原子性）、トランザクションは、基礎をなすデータを一貫した状態にし（一貫性）、トランザクション更新の効果は、全体のトランザクションが不変となるまでは他の同時に実行されるオペレーションから見えず（隔離性）、またトランザクションに対する結果が決定された後は、この結果は決して変化しないことが保証される（永続性）。

図６のカーネルレベルのトランザクションマネージメントの実施例は、複数の装置に関与する分散トランザクションの実施例を対象としており、トランザクションに期待される「ＡＣＩＤ」特性を保持している。さらに、図６の実施例は、カーネルオブジェクトを参照しているが、この実施例は、決してカーネルオブジェクトによって実装されるトランザクションだけに限定されるものではない。より詳細には、本明細書中で説明するトランザクションは、カーネルオブジェクト以外のオブジェクトによっても実装することができ、また異なるタイプのトランザクションマネージャによっても実装することができる。

図６において、クライアントアプリケーション６００に対応するトランザクションは、少なくとも第１のデバイス上のトランザクションマネージャ６０５、ならびに第２のデバイス上のクライアントアプリケーション６００Ｂおよびトランザクションマネージャ６３５を利用している。クライアントアプリケーション６００Ｂは、クライアントアプリケーション６００に関連付けられている。互いに情報をやりとりするトランザクションマネージャ６０５および６３５は、全体のトランザクションおよびリソースについての状態情報を保持し、さらにクライアントアプリケーションと関連するＲＭ（ｒｅｓｏｕｒｃｅｍａｎａｇｅｒリソースマネージャ）の間で相互作用またはプロトコルを調整することができるカーネルオブジェクトの集合体とすることができる。

図６の実施例におけるＲＭ６２５およびＲＭ６３０を含めてリソースマネージャは、データを永続的状態に記憶することができる少なくとも１つの基礎をなすリソースの状態を保持する。このようなリソースの非排他的な実施例は、データベースおよびメッセージキュー（ｍｅｓｓａｇｅｑｕｅｕｅ）を含んでいる。図６の実施形態の例の第１のデバイスにおいて、ＲＭ６２５はリソース６２７に対応し、ＲＭ６３０はリソース６３２に対応し、第２のデバイスにおいて、ＲＭ６５５はリソース６５７に対応する。

図６に示すように、第１のデバイス上のトランザクションマネージャ６０５は、以下のカーネルオブジェクト：ＴＸ（ｔｒａｎｓａｃｔｉｏｎｏｂｊｅｃｔトランザクションオブジェクト）６１０、ＲＭＯ（ｒｅｓｏｕｒｃｅｍａｎａｇｅｒｏｂｊｅｃｔリソースマネージャオブジェクト）６１５、およびＥＮ（ｅｎｌｉｓｔｍｅｔｏｂｊｅｃｔエンリストメントオブジェクト）６２０を含んでおり、第２のデバイス上のトランザクションマネージャ６３５は、以下のカーネルオブジェクト：ＴＸ６４０、ＲＭＯ６４５、およびＥＮ６５０を含んでいる。ＴＸは特定のトランザクションを表し、このトランザクションに参加するプロセスによってオープンにすることができる。

ＲＭＯは、特定のトランザクションに参加するリソースを表す。トランザクションへのＲＭＯによる参加は、２相コミットメッセージを受信することを含んでいる。さらに、ＲＭＯは永続的であり、その結果、この対応するトランザクションマネージャは、どのトランザクションの結果が対応するＲＭに伝送されるかを知っている。代わりに、ＲＭＯが過渡的なこともあり、したがって、失敗を超えて永続的なＲＭＯを管理することなく、クライアントアプリケーションがトランザクション通知のストリームに加入することができるようになる。

ＥＮは、トランザクションとリソースマネージャとの間の関係を表す。リソースマネージャは、ＥＮ上にエンリストメントを作成することによってＥＮがトランザクションに参加することになることを示す。ＲＭＯが、特定のトランザクションに関して（ＰｒｅｐａｒｅやＣｏｍｍｉｔなどの）オペレーションを実施するように要求されているときには、ＲＭＯは、ＥＮを使用して参加を示す。リソースマネージャは、特定のトランザクションに関して複数のＥＮを有することもできる。

以下のように、カーネル環境に対して、トランザクションが正常にすべての適切なファイルをアップデートするようにするために実装される２相コミットプロトコルが、図６および図７の実施例を参照しながら説明される。特に、クライアントアプリケーション６００が、第１のデバイス上のトランザクションマネージャ６０５に対応するカーネルオブジェクトをオープンし、ＳＲＶ２３４（図２）が、第２のデバイス上のトランザクションマネージャ６３５に対応するカーネルオブジェクトをオープンした後に、「プリペア（ｐｒｅｐａｒｅ）」フェーズ７００が開始され、７０５において、このトランザクション中の各ＲＭには、対応するトランザクションマネージャからの「プリペア」命令が送信される。このように警告を受けて、７１０において、ＲＭはリソースデータを永続的状態にすることによってプリペアを行い、その結果、各リソース中のこのデータは、「コミットされ」または「ロールバックされる」ことが可能になる。プリペアが行われると、７１５において、ＲＭはこの対応するトランザクションマネージャのＴＸに対して確認メッセージを送信する。

「コミット」フェーズ７２０は、このトランザクションが解決すると実施され、それによって７２５においてこのトランザクションマネージャのＴＸは、各関連付けられたＲＭに対して「コミットされ」または「アボート／ロールバックされた」トランザクション結果を送信する。次いで、ＲＭは、この結果を関連付けられたログに記録し、この基礎となるリソースデータは、このトランザクション結果に従ってコミットされ、あるいはロールバックされる。代替的な実施形態においては、このトランザクションについてのデータが永続的でない揮発性のエンリストメントを可能とすることができ、したがってこのデータは、ログ記録もされず、また復元もされない。

カーネルレベル上のトランザクションマネージメントは、それだけには限定されないが
Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎ３２（登録商標）アプリケーションプログラミングインターフェースおよびＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを含めてシステムアーキテクチャに適用可能なＡＰＩ（ａｐｐｌｉｃａｔｉｏｎｐｒｏｇｒａｍｉｎｔｅｒｆａｃｅアプリケーションプログラムインターフェース）を利用することによって実装することができる。本明細書中で説明しているＡＰＩは、ハンドルベースのインターフェースを介して表示され、「ハンドル」は、ＡＰＩを対象とするオブジェクトを参照する。さらに、非同期式のオペレーションが明示的に要求されない限り、各カーネルオブジェクト上、特にＴＸおよびＲＭＯ上のオペレーションは、同期式である。さらにまた、トランザクションの異なる実施形態に対応するオペレーションは、本明細書中で説明している１つまたは複数のＡＰＩの様々な組合せによって実装することができる。すなわち、一部の実施形態では、本明細書中で説明しているＡＰＩのすべてを使用することができるが、他の実施形態では、それらの様々な組合せを使用することができる。

ＴＸカーネルオブジェクト上でオペレーションを実装するＡＰＩ、およびこのＡＰＩの機能の対応する記述が、以下に提供される（この関連するルーチンのさらに詳細な記述も、以下にさらに提供される）。

・ＰｒｅｐｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔ：「フェーズ０」の処理としても知られており、ＴＸがすべての関連するＲＭに対してプリプリペアメッセージを送信することを要求する。

・ＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔ：ＴＸがすべてのエンリストされたＲＭに対してプリペア要求を送信することを要求する。

・ＣｒｅａｔｅＴｒａｎｓａｃｔｉｏｎ：新しいＴＸをオープンする。

・ＯｐｅｎＴｒａｎｓａｃｔｉｏｎ：既存のＴＸをオープンする。

・ＣｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎ：ＴＸがコミットされることを要求する。

・ＲｏｌｌｂａｃｋＴｒａｎｓａｃｔｉｏｎ：ＴＸがこのトランザクションをアボートまたはロールバックすることを要求する。

・ＳａｖｅｐｏｉｎｔＴｒａｎｓａｃｔｉｏｎ：ＴＸがこのトランザクションの状態を保存することを要求する。

・ＧｅｔＴｒａｎｓａｃｔｉｏｎＩｎｆｏ：このＴＸについての情報を検索する。

・ＳｅｔＴｒａｎｓａｃｔｉｏｎＩｎｆｏ：このＴＸについての情報を設定する。

ＲＭＯカーネルオブジェクト上でオペレーションを実装するために利用されるＡＰＩ、およびこのＡＰＩの機能の対応する記述が、以下に提供される（この関連するルーチンのさらに詳細な記述も、以下にさらに提供される）。

ＣｒｅａｔｅＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：リソースを表す新しいＲＭＯを作成する。

ＯｐｅｎＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：既存のＲＭＯをオープンする。

ＤｅｓｔｒｏｙＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：ＲＭＯを破壊し、したがってＲＭＯを非永続的なものにする。

ＧｅｔＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏ：ＲＭＯについての情報を検索する。

ＳｅｔＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏ：ＲＭＯについての情報を設定する。

ＣｒｅａｔｅＥｎｌｉｓｔｍｅｎｔ：ＲＭＯをトランザクションに参加させ、関連した通知を検索する。

ＧｅｔＮｏｔｉｆｉｃａｔｉｏｎＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：使用可能なＲＭ通知を照会し戻す。

トランザクションに参加した後、ＲＭＯカーネルオブジェクトによってＴＸカーネルオブジェクト上でオペレーションを実装するために利用されるＡＰＩ、およびこのＡＰＩの機能の対応する記述が、以下に提供される（この関連するルーチンのさらに詳細な記述も、以下にさらに提供される）。

・ＰｒｅＰｒｅｐａｒｅＣｏｍｐｌｅｔｅ：対応するトランザクションマネージャが要求するときに、ＲＭがプリプリペアを完了していることを示す。

・ＰｒｅｐａｒｅＣｏｍｐｌｅｔｅ：対応するトランザクションマネージャが要求するときに、ＲＭがトランザクションのプリペアを完了していることを示す。

・ＲｏｌｌｂａｃｋＣｏｍｐｌｅｔｅ：対応するトランザクションマネージャが要求するときに、ＲＭが実行されたトランザクション作業のロールバックを完了していることを示す。

・ＣｏｍｍｉｔＣｏｍｐｌｅｔｅ：対応するトランザクションマネージャが要求するときに、ＲＭがトランザクション作業のコミットを完了していることを示す。

残念ながら、トランザクションマネージメントを実装するために利用されるＴＸ、ＲＭＯ、およびＥＮに関連するＡＰＩは、様々なセキュリティ攻撃に対して１つまたは複数のカーネルオブジェクトをさらすこともある。例えば、悪意のあるまたは不正なＲＭが、トランザクション中にそれ自体をエンリストしてファンクション呼出しに決して応答しないことによってサービス拒否攻撃を引き起こし、あるいは、代わりにトランザクションアボートを強制することができる。したがって、図６をまた参照すると、さらなる例示の実施例は、安全なカーネルレベルの分散トランザクションを対象としている。

図６の実施形態の一例はさらに、各カーネルオブジェクトの少なくとも１つに対してＡＣＬ（ａｃｃｅｓｓｃｏｎｔｒｏｌｌｉｓｔアクセスコントロールリスト）を含むことができるセキュリティデスクリプタ（ｓｅｃｕｒｉｔｙｄｅｓｃｒｉｐｔｏｒ）を適用することにより、ぜい弱なカーネルオブジェクトに対するセキュリティソリューションを提供する。

第１のデバイスにおいては、ＡＣＬ６６０はＴＸ６１０に適用され、ＡＣＬ６６５はＲＭＯ６１５に適用され、ＡＣＬ６７０はＥＮ６２０に適用される。第２のデバイスにおいては、ＡＣＬ６７５はＴＸ６４０に適用され、ＡＣＬ６８０はＲＭＯ６４５に適用され、ＡＣＬ６８５はＥＮ６５０に適用される。

ＡＣＬは、特定のユーザまたはユーザグループが特定のオブジェクト上で行使することを許可または拒否される「権利（ｒｉｇｈｔ）」を定義する。より詳細には、図８の実施例ＡＣＬ８１０に示すように、カーネルオブジェクトに適用またはアタッチされるＡＣＬは、対応するＳＩＤ（ｓｅｃｕｒｉｔｙｉｄｅｎｔｉｆｉｅｒセキュリティ識別子）および対応する１組の権利を含む少なくともＡＣＥ（ａｃｃｅｓｓｃｏｎｔｒｏｌｅｎｔｒｙアクセス制御エントリ）を含んでいる。図８のＡＣＥエントリ１〜１２は、それぞれ対応するＳＩＤ１〜１２、および対応するＲＩＧＨＴ１〜１２を含んでいる。

ＳＩＤ１〜１２は、このＡＣＬが適用されるカーネルオブジェクト上でオペレーション、または一連のオペレーションを実装しようと試みることができるユーザまたはユーザグループを識別する。ＲＩＧＨＴ１〜１２は、このＳＩＤによって識別されるユーザまたはユーザグループがこの各カーネルオブジェクト上で実施することができるオペレーションまたは一連のオペレーションを指定し、さらにこの識別されたユーザまたはユーザグループへのこのようなオペレーションまたは複数のオペレーションのアクセス可能性を指定する。すなわち、ＲＩＧＨＴ１〜１２は、識別されたユーザまたはユーザグループが、指定されたオペレーションを実施することが許可されること、あるいは、この指定されたユーザまたはユーザグループが、指定されたオペレーションを実施することが禁止されることを示すことができる。

以下は、ＴＸに対して適用されるＡＣＬにおいてＲＩＧＨＴ１〜１２が指定することができるオペレーションの例のリストであり、このオペレーションの機能の記述が後に続いている。ＲＩＧＨＴ１〜１２はさらに、この対応するＳＩＤによって識別されるユーザまたはユーザグループに対してＴＸ上でこのオペレーションが許可または拒否されることを指定する。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＱＵＥＲＹ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＴＸについての情報を獲得する。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＳＥＴ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＴＸについての情報を設定する。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＥＮＬＩＳＴ：このトランザクション中のＴＸ上にエンリストする。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＣＯＭＭＩＴ：ＴＸに関連するすべてのデータアップデートを永続的にする。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＲＯＬＬＢＡＣＫ：ＴＸ上でこのオペレーションをアボート、すなわちロールバックする。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＰＲＯＰＡＧＡＴＥ：ＴＸから別のオブジェクトへとデータを伝送する。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＳＡＶＥＰＯＩＮＴ：このトランザクションの最新ポイントを保存する。

・ＴＲＡＮＳＡＣＴＩＯＮ＿ＭＡＲＳＨＡＬ：このトランザクションに関するデータを別のデバイスへと伝送する。

以下は、ＲＭＯに対して適用されるＡＣＬにおいてＲＩＧＨＴ１〜１２が指定することができるオペレーションの例のリストであり、このオペレーションの機能の記述が後に続いている。ＲＩＧＨＴ１〜１２はさらに、この対応するＳＩＤによって識別されるユーザまたはユーザグループに対してＲＭＯ上でこのオペレーションが許可または拒否されることを指定する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＱＵＥＲＹ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＲＭＯについての情報を獲得する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＳＥＴ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＲＭＯについての情報を設定する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＲＥＣＯＶＥＲ：トランザクションの失敗の瞬間におけるトランザクションの状態を決定する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＥＮＬＩＳＴ：トランザクションにおいてＲＭＯをエンリストする。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＧＥＴ＿ＮＯＴＩＦＩＣＡＴＩＯＮ：トランザクションマネージャからのトランザクションの解決に応じて通知を受信する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＲＥＧＩＳＴＥＲ＿ＰＲＯＴＯＣＯＬ：このトランザクションにおいてＲＭＯがサポートするプロトコルを登録する。

・ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＣＯＭＰＬＥＴＥ＿ＰＲＯＰＡＧＡＴＩＯＮ：トランザクションの解決に従ってリソースを設定する。

以下は、ＥＮに対して適用されるＡＣＬにおいてＲＩＧＨＴ１〜１２が指定することができるオペレーションの例のリストであり、このオペレーションの機能の記述が後に続いている。ＲＩＧＨＴ１〜１２はさらに、この対応するＳＩＤによって識別されるユーザまたはユーザグループに対してＥＮ上でこのオペレーションが許可または拒否されることを指定する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＱＵＥＲＹ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＥＮについての情報を獲得する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＳＥＴ＿ＩＮＦＯＲＭＡＴＩＯＮ：ＥＮについての情報を設定する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＲＥＣＯＶＥＲ：トランザクションの失敗の瞬間におけるエンリストメントの状態を決定する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＲＥＦＥＲＥＮＣＥ：エンリストメントキーを取得し、参照（または逆参照）する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＳＵＢＯＲＤＩＮＡＴＥ＿ＲＩＧＨＴＳ：このトランザクションをロールバックし、通知に応答する。

・ＥＮＬＩＳＴＭＥＮＴ＿ＳＵＰＥＲＩＯＲ＿ＲＩＧＨＴＳ：トランザクション中でプリプリペアオペレーション、プリペアオペレーション、または上位ロールバックオペレーションを開始するなど、上位トランザクションマネージャが実施するはずのオペレーションを実施する。

したがって、各カーネルオブジェクトＴＸ、ＲＭＯ、およびＥＮはそれぞれそれに適用されるＡＣＬを有することができる。このように、ＡＰＩがこれらのカーネルオブジェクトのそれぞれ１つの上にあるオペレーションを開始しようと試みるときに、このＡＰＩが起源とするユーザまたはユーザグループに対して、このオペレーションが許可または拒否されるかどうかを判定して、このＡＣＬに従う必要がある。

より詳細には、オペレーションを実施するためのハンドルがオープンされるとき、このＡＰＩに対応するユーザまたはユーザグループはこのＡＣＬ中のＳＩＤに対して検査され、許可されたオペレーションのリストが生成され、このＡＰＩによって指定されるこのオペレーションは所与のハンドル上のこのＳＩＤに対して許可されたオペレーションに対して検査される。

カーネルオブジェクトの間のトランザクションマネージメントをセキュリティ保護し、セキュリティパラメータを強要する代替的な実施形態は、このＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム用のセキュリティモデルによるトランザクションに参加することができるカーネルオブジェクトにセキュリティデスクリプタを適用する工程を含んでいる。

上述のように、これらのＡＰＩは、ハンドルベースのインターフェースとして表示され、このインターフェースを利用してこのセキュリティモデルを実装する。以上でリストアップしたＴＸカーネルオブジェクト上でオペレーションを実装するこれらのＡＰＩのより詳細な記述が、以下に含まれている。これらの記述は、このルーチン、対応する引数、およびリターン値の記述を含んでいる。

PreprepareEnlistment
（IN PHANDLE TransactionHandle；
IN PHANDLE ResourceManagerHandle）。

・このルーチンは、すべての関連するＲＭに対してプリプリペア要求（Ｐｒｅ−Ｐｒｅｐａｒｅｒｅｑｕｅｓｔ）を発行することによってトランザクションが「プリプリペアされる」ことを要求する。プリプリペアは、このトランザクションが、下流のＲＭがもはや変更を受け入れることができないというプリペア状態（Ｐｒｅｐａｒｅｄｓｔａｔｅ）に入る以前に、キャッシュに似た特性を有するＲＭにそのキャッシュを、可能であれば他のＲＭに対してフラッシュする機会を許可する。

・このルーチンが呼び出されず、トランザクション参加者がフェーズ０の処理を要求している場合、プリペア（Ｐｒｅｐａｒｅ）が受信されるときに要求されるように、プリプリペア要求が発行される。しかし、ＰｒｅｐｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔが存在しない場合には、キャッシュに似たＲＭを含む一部の構成では、分散シナリオにおいて、不必要なトランザクションロールバックが引き起こされることもある。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：プリプリペアすべきトランザクションを示すハンドルを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：このトランザクションをプリプリペアしている上位−ＴＭ／ＣＲＭに対してハンドルを与える。この上位−ＴＭ／ＣＲＭだけが、このトランザクション上でＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔ、ＳｕｐｅｒｉｏｒＣｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎ、およびＳｕｐｅｒｉｏｒＲｏｌｌｂａｃｋＴｒａｎｓａｃｔｉｏｎを呼び出すことが可能になる。

・リターン値：

PrepareEnlistment
（IN PHANDLE TransactionHandle、
IN PHANDLE ResourceManagerHandle）；
・このルーチンは、すべてのその関連付けられたＲｅｓｏｕｒｃｅＭａｎａｇｅｒに対してプリペア要求（Ｐｒｅｐａｒｅｒｅｑｕｅｓｔ）を発行することによって、トランザクションが「プリペアされる」ことを要求する。この要求は、２相コミットプロトコルを開始する。

・ＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔを発行するトランザクション参加者は、トランザクションオブジェクトをシステムまたはアプリケーションがクラッシュしても生き残ることになる永続的状態にする。このような参加者は、どのようなタイプの失敗の後にもこのトランザクション上でリカバリ（ｒｅｃｏｖｅｒｙ）を実施して、結果を送付する。この要件を満たすのに失敗すると、リソースのリーク、ならびに矛盾したトランザクションの結果がもたらされることもある。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：プリペアすべきトランザクションについてのハンドルを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：このトランザクションをプリペアしているＴＭに対して、ハンドルを与える。このトランザクションが（ＰｒｅｐｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔに対するコールを介して）プリプリペアされている場合には、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅは、ＰｒｅｐｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔに対する呼出し中で使用された上位−ＴＭ／ＣＲＭとマッチングする。さらに、このＡＰＩをコールする上位−ＴＭ／ＣＲＭだけが、このトランザクション上でＳｕｐｅｒｉｏｒＣｏｍｍｉｔｔｒａｎｓａｃｔｉｏｎおよびＳｕｐｅｒｉｏｒＲｏｌｌｂａｃｋＴｒａｎｓａｃｔｉｏｎを呼び出すことが許可されることになる。

・リターン値：

CreateTransaction
（OUT PHANDLE TransactionHandle、
IN ULONG DesiredAccess
OPTIONAL；
IN POBJECT_ATTRIBUTES ObjectAttributes
OPTIONAL；
IN ULONG CreateOptions
OPTIONAL；
IN PHANDLE ResourceManagerHandle
OPTIONAL；
IN NOTIFICATION_MASK NotificationMask
OPTIONAL；
IN LPVOID TransactionKey
OPTIONAL）。

・このルーチンは、新しいトランザクションオブジェクトを作成し、この新しいオブジェクトにハンドルを戻す。

・代わりに（ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅパラメータが指定される場合）、このルーチンは、それが正常に作成された後に、このトランザクション上で「ジョイン（Ｊｏｉｎ）」オペレーションを実施する。

クライアントは、ＣｌｏｓｅＨａｎｄｌｅＡＰＩを使用してこのトランザクションハンドルをクローズする。この最後のトランザクションハンドルが、いずれかがこのトランザクション上でＣｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎを呼び出すことなくクローズする場合には、このトランザクションは、暗黙的にロールバックされる。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：この新しいトランザクションに対するハンドルを受信することになるロケーションにポインタを与える。

ＤｅｓｉｒｅｄＡｃｃｅｓｓ：この所望のアクセスレベルを指定するマスクを与える。この有効なアクセスマスクの選択肢には、以下のものがある。：
ＳＹＮＣＨＲＯＮＩＺＥこのハンドル上で同期オペレーションを実施することができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＣＯＭＭＩＴこのハンドルを使用してトランザクションをコミットすることができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＰＲＥＰＡＲＥこのハンドルを使用してトランザクションをコミットすることができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＲＯＬＬＢＡＣＫこのハンドルを使用してトランザクションをアボートすることができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＳＡＶＥＰＯＩＮＴこのハンドルを使用してこのトランザクションについてのセーブポイントを作成することができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＪＯＩＮこのハンドルを使用してこのトランザクションをＲＭとして加えることができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＲＥＡＤ＿ＡＴＴＲＩＢＵＴＥＳトランザクションに関連する属性を読み取ることができる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＷＲＩＴＥ＿ＡＴＴＲＩＢＵＴＥＳトランザクションに関連する属性を書き込むことができる。

ＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅｓ：オプションのオブジェクト属性構造に、ポインタを与える。

ＣｒｅａｔｅＯｐｔｉｏｎｓオプションのトランザクションフラグを与える。有効な作成フラグ選択肢は以下を含んでいる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＣＲＥＡＴＥ＿ＰＲＥＳＵＭＥＤ＿ＮＯＴＨＩＮＧ「何も想定しない（ｐｒｅｓｕｍｅｄｎｏｔｈｉｎｇ）」トランザクションを作成する。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：指定されたトランザクションについての通知を受信するＲｅｓｏｕｒｃｅＭａｎａｇｅｒにハンドルを与える。

ＮｏｔｉｆｉｃａｔｉｏｎＭａｓｋ：このＲｅｓｏｕｒｃｅＭａｎａｇｅｒがこのトランザクションに関して受信したい通知を指定する。

ＴｒａｎｓａｃｔｉｏｎＫｅｙ：このＲＭがこのトランザクションについての任意の通知とともに受信をしたい不明瞭なポインタ値を指定する。このＲＭは、このポインタ値を使用して通知をこのＲＭのアドレス空間中のあるオブジェクトに関連づけることができ、それによって通知が行われるたびにルックアップを実行する必要をなくすることができる。

・リターン値：

OpenTransaction
（OUT PHANDLE TransactionHandle、
IN ACCESS_MASK DesiredAccess、
IN POBJECT_ATTRIBUTES ObjectAttributes、
IN PHANDLE ResourceManagerHandle
optional、
IN NOTIFICATION_MASK NotificationMask
optional、
IN LPVOID TransactionKey
optional）；
・このルーチンは、既存のトランザクションオブジェクトを調べ、ハンドルをこのトランザクションに戻す。この呼出し元は、ＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅｓのＯｂｊｅｃｔＮａｍｅフィールド中においてＧＵＩＤのストリング表現を指定する。

・代わりに（このＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅパラメータが指定される場合）、このルーチンはまた、それがオープンされた後にこのトランザクション上で「ジョイン」オペレーションを実施する。

・クライアントは、ＣｌｏｓｅＨａｎｄｌｅＡＰＩを使用してこのトランザクションハンドルをクローズする。この最後のトランザクションハンドルが、どれかがこのトランザクション上でＣｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎをコールすることなくクローズする場合には、このトランザクションは、暗黙的にロールバックされたトランザクションである。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このオープンオペレーションが成功する場合に、このトランザクションに対するハンドルを受信することになるロケーションにポインタを与える。

ＤｅｓｉｒｅｄＡｃｃｅｓｓ：この所望のアクセスレベルを指定するマスクを与える。

ＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅｓ：オプションのオブジェクト属性構造にポインタを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：この指定されたトランザクションについての通知を受信するＲｅｓｏｕｒｃｅＭａｎａｇｅｒにハンドルを与える。

ＮｏｔｉｆｉｃａｔｉｏｎＭａｓｋ：このＲｅｓｏｕｒｃｅＭａｎａｇｅｒがこのトランザクションに関して受信することができる通知を指定する。

ＴｒａｎｓａｃｔｉｏｎＫｅｙ：このＲＭがこのトランザクションについての任意の通知とともに受信したい不明瞭なポインタ値をオプション的に指定する。このＲＭは、このポインタ値を使用して通知をこのＲＭのアドレス空間中のあるオブジェクトに関連づけることができ、それによって通知が行われるたびにルックアップを実行する必要をなくすることができる。

・リターン値：

CommitTransaction
（IN PHANDLE TransactionHandle
IN ULONG CommitOptions Optional）；
・このルーチンは、ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅに関連するこのトランザクションがコミットされることを要求する。オープンまたは作成されている任意のトランザクションハンドルは、Ｔｒａｎｓａｃｔｉｏｎ＿ＣｏｍｍｉｔＤｅｓｉｒｅｄＡｃｃｅｓｓを用いてコミットすることができる。トランザクションの作成者だけがそれをコミットすることが可能であることを提示する制約は、存在していないからである。

・問題のトランザクションが、以前にＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔ要求を発行していない場合に、２相コミットプロトコルは、すべてのエンリストされたＲＭ上で開始することができる。この呼出しは、このクライアントによって発行されている１相コミット要求と考えることができる。

・このトランザクションが以前にＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔを介してプリペアされている場合には、このルーティング（ｒｏｕｔｉｎｇ）は、呼び出されない。ＰｒｅｐａｒｅＥｎｌｉｓｔｍｅｎｔを呼び出したＲＭだけが、このルーチンＳｕｐｅｒｉｏｒＣｏｍｍｉｔＴｒａｎｓａｃｔｉｏｎを使用して、このトランザクション状態を解決することができる。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：コミットすべきトランザクションを示すハンドルを与える。

ＣｏｍｍｉｔＯｐｔｉｏｎｓ：ＣＯＭＭＩＴ＿ＲＥＴＡＩＮＩＮＧトランザクションがコミットされることになる。

・リターン値：

RollbackTransaction
（IN PHANDLE TransactionHandle、
IN SAVEPOINT SavePoint Optional、
IN ROLLBACK_REASON RollbackReason Optional）；
・このルーチンは、ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅに関連するこのトランザクションをロールバックすることを要求する。このオプションのＳａｖｅＰｏｉｎｔが指定され、有効なセーブポイントである場合、このロールバックは、部分的なロールバックでもよい。ＮＵＬＬのＳａｖｅＰｏｉｎｔ引数は、このトランザクションが完全にロールバックまたはアボートされるべきことを示す。オプションのＲｏｌｌｂａｃｋＲｅａｓｏｎ構造を与えることができる。これは、トランザクションオブジェクト中に保持されることになり、ＧｅｔＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓａｃｔｉｏｎに対する呼出しを介して関心のあるトランザクション参加者は検索することができる。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：ロールバックすべきトランザクションを示すハンドルを与える。

ＳａｖｅＰｏｉｎｔ：どこまでトランザクションの状態をロールバックすべきかを示すＳａｖｅＰｏｉｎｔネームを与える。

ＲｏｌｌｂａｃｋＲｅａｓｏｎ：ロールバックリーズン（ｒｏｌｌｂａｃｋｒｅａｓｏｎ）を与える。

・リターン値：

SavePointTransaction
（IN PHANDLE TransactionHandle、
IN ULONG SavePointFlags Optional、
OUT LPSAVEPOINT SavePoint）；
・このルーチンは、「セーブポイント」がＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅに関連付けられたトランザクションについて生成されることを要求する。このセーブポイントは、後続のロールバック要求に対するターゲットとして使用される。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：セーブポイントを確立すべき対象のトランザクションを示すハンドルを与える。

ＳａｖｅＰｏｉｎｔＦｌａｇｓ：このセーブポイントの生成に影響を及ぼす１組のフラグをオプション的に与える。

ＳａｖｅＰｏｉｎｔ：セーブポイント識別子が記憶されるロケーションにポインタを与える。

・リターン値：

QueryInformationTransaction
（IN HANDLE TransactionHandle、
IN TRANSACTION_INFORMATION_CLASS
TransactionInformationClass、
OUT PVOID
TransactionInformation、
IN ULONG
TransactionInformationLength、
OUT PULONG ReturnLength Optional);
・このルーチンは、ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅによって表されるトランザクションオブジェクトについての要求された情報を戻す。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：情報が要求されているトランザクションを示すハンドルを与える。

ＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ：このトランザクションオブジェクトについてのどのクラスの情報が要求されているかを示す。

ＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ：要求されているこのトランザクション情報が記憶されるバッファに対してポインタを与える。

ＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＬｅｎｇｔｈ：ＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎによってポイントされるバッファの長さを示す。

ＲｅｔｕｒｎＬｅｎｇｔｈ：このＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎバッファに書き込まれる情報の長さを受信することになるロケーションにポインタを与える。

・リターン値：

SetInformationTransaction
（IN HANDLE TransactionHandle、
IN TRANSACTION_INFORMATION_CLASS
TransactionInformationClass、 IN PVOID
TransactionInformation、
IN ULONG
TransactionInformationLength）；
・このルーチンはＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅによって表されるこのトランザクションオブジェクトについてこの要求された情報を設定する。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：どの情報が修正されることになるかをこのトランザクションに示すハンドルを与える。

ＴｒａｎｓａｃｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ：要求されるこのトランザクション情報が記憶されるバッファにポインタを与える。

・リターン値：

以下は、以上でリストアップした、ＲＭＯカーネルオブジェクト上でオペレーションを実装するＡＰＩのより詳細な記述を含んでいる。これらの記述は、このルーチン、対応する引数、およびリターン値の記述を含んでいる。

CreateResourceMnager
（OUT PHANDLE ResourceManagerHandle、
IN ACCESS_MASK DesiredAccess
Optional、
IN POBJECT_ATTRIBUTES ObjectAttributes、
IN ULONG CreateOptions
Optional、
IN RM_NOTIFICATION_ROUTINE NotificationRoutine
Optional）；
・このルーチンは、リソースを表す新しいＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトを作成する。

・ＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトは、このＲＭが参加したという、トランザクションに関するＴＭ通知についてのエンドポイントとしての役割も果たす。ＲＭは、ＧｅｔＮｏｔｉｆｉｃａｔｉｏｎＲｅｓｏｕｒｃｅＭａｎａｇｅｒを呼び出すことによってこれらの通知を要求する。

・ＲｅｓｏｕｒｃｅＭａｎａｇｅｒは、通常は永続的なオブジェクトであり、すなわちこのオブジェクトは、（システムまたはＲＭの）あらゆる失敗の後に再オープンされ、リカバリを実施する必要がある。ＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトの過渡的なバージョンは、このオプションＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＮＯ＿ＲＥＣＯＶＥＲＹを指定することによって作成することができる。過渡的なＲＭは、リカバリを実施するように義務づけられておらず、また許可されてもいない。このリカバリ不可能なＲＭオプションにより、この十分複雑なログ記録をとるプリペアを実装する必要なしに、またリカバリを実施することもなしに、アプリケーションまたはＲＭはトランザクションの進行（例えば、ＰＲＥＰＲＥＰＡＲＥ、ＰＲＥＰＡＲＥ、ＣＯＭＭＩＴ）についての通知を受信できるようになる。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：この新しいＲｅｓｏｕｒｃｅＭａｎａｇｅｒに対するハンドルを受信することになるロケーションにポインタを与える。

ＤｅｓｉｒｅｄＡｃｃｅｓｓ：所望のアクセスレベルを指定するマスクを与える。有効なアクセスマスクの選択肢を以下に示す。：
ＳＹＮＣＨＲＯＮＩＺＥ：ハンドル上でオペレーションを同期させる。

ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＤＥＳＴＲＯＹ：このリソースマネージャを破壊する。

ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＲＥＡＤ＿ＡＴＴＲＩＢＵＴＥＳ：リソースマネージャに関連する属性を読み取る。

ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＷＲＩＴＥ＿ＡＴＴＲＩＢＵＴＥＳ：リソースマネージャに関連する属性を書き込む。

ＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅｓ：この新しいＲＭオブジェクトについての属性を指定する。この属性は、ＲＭネームを含んでいる。

ＣｒｅａｔｅＯｐｔｉｏｎｓ：この作成されたオブジェクトについてのオプションを指定する。

ＲＥＳＯＵＣＥＭＡＮＡＧＥＲ＿ＮＯ＿ＲＥＣＯＶＥＲＹ：ＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトは、非永続的であり、リカバリを実施しない。

ＲＥＳＯＵＣＥＭＡＮＡＧＥＲ＿ＣＯＭＭＵＮＩＣＡＴＩＯＮ：ＲｅｓｏｕｒｃｅＭａｎａｇｅｒは、他のコンピュータに対してどのように通信を行うかを知っている。ＲｅｓｏｕｒｃｅＭａｎａｇｅｒを使用してトランザクションをマーシャリングまたはアンマーシャリングする（ｕｎｍａｒｓｈａｌｌ）ことができる。

ＲＥＳＯＵＲＣＥＭＡＮＡＧＥＲ＿ＣＬＵＳＴＥＲ＿ＲＥＣＯＶＥＲＹ：ＲｅｓｏｕｒｃｅＭａｎａｇｅｒは、失敗している可能性のあるファイルをログ記録した結果をどのようにして読み取り、このクラスタ中の他のノードに送付するべきかを知っている。ＲｅｓｏｕｒｃｅＭａｎａｇｅｒを使用してクラスタ中のトランザクションをリカバリすることができる。

ＮｏｔｉｆｉｃａｔｉｏｎＲｏｕｔｉｎｅ：通知がこのＲｅｓｏｕｒｃｅＭａｎａｇｅｒにとって使用可能であるときに呼び出すべき通知ルーチンを指定する。

・リターン値：

OpenResourceManager
（OUT PHANDLE ResourceManagerHandle、
IN ACCESS_MASK DesiredAccess
Optional、
IN POBJECT_ATTRIBUTES ObjectAttributes、
IN ULONG OpenOptions
Optional、
IN RM_NOTIFICATION_ROUTINE NotificationRoutine、
Optional）。

・このルーチンは、名前によって既存のＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトをオープンする。ターゲットのＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトが永続的であるが、現在オープンされていない場合、このオブジェクトは最初に「リカバリする」状態にあり、リカバリされる必要がある。リカバリが完了した後に、ＲｅｃｏｖｅｒｙＣｏｍｐｌｅｔｅＲｅｓｏｕｒｃｅＭａｎａｇｅｒを呼び出す必要がある。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：既存のＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトに対するハンドルを受信することになるロケーションにポインタを与える。

ＤｅｓｉｒｅｄＡｃｃｅｓｓ：このオブジェクトに対する所望のアクセスを指定するマスクを与える。

ＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅｓ：この新しいＲＭオブジェクトについての属性を指定する。

ＯｐｅｎＯｐｔｉｏｎｓ：このオブジェクトについてのオプションを指定する。有効なオプションは、以下を含んでいる。

ＲＥＳＯＵＲＣＥ＿ＭＡＮＡＧＥＲ＿ＤＥＴＡＩＬＥＤ＿ＲＥＣＯＶＥＲＹ＿ＮＯＴＩＦＩＣＡＴＩＯＮＳ：このリソースマネージャは、通常のリカバリ通知の代わりに、（通信エンドポイントについての追加の情報を伴う）詳細なリカバリ通知を受信する。

ＮｏｔｉｆｉｃａｔｉｏｎＲｏｕｔｉｎｅ：通知が、このＲｅｓｏｕｒｃｅＭａｎａｇｅｒにとって使用可能であるときに、呼び出されることになる通知ルーチンを指定する。

・リターン値：

DestroyResourceManager
（IN PHANDLE ResourceManagerHandle）；
・このルーチンは、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトを破壊し、それがもはや永続的でないようにする。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：破壊すべきＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトを指示するハンドルを与える。

・リターン値：

QueryInformationResourceManager
（IN HANDLE ResourceManagerHandle、
IN RESOURCEMANAGER_INFORMATION_CLASS
ResourceManagerInformationClass、
OUT PVOID ResourceManagerInformation、
IN ULONG
ResourceManagerInformationLength、
OUT PULONG ReturnLength Optional)。

・このルーチンは、ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅによって表されるＲＭＯについてのこの要求された情報を戻す。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：情報が要求されているこのＲｅｓｏｕｒｃｅＭａｎａｇｅｒを示すハンドルを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎＣｌａｓｓ：このＲｅｓｏｕｒｃｅＭａｎａｇｅｒオブジェクトについてのどのクラスの情報が要求されているかを示す。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎ：要求されるこのＲｅｓｏｕｒｃｅＭａｎａｇｅｒ情報が記憶されることになるバッファにポインタを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎＬｅｎｇｔｈ：ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎによってポイントされるバッファの長さを示す。

ＲｅｔｕｒｎＬｅｎｇｔｈ：ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎバッファに書き込まれる情報の長さを受信するロケーションにポインタを与える。

・リターン値：

SetInformationResourceManager
（IN HANDLE ResourceManagerHandle、
IN RESOURCEMANAGER_INFORMATION_CLASS
ResourceManagerInformationClass、
IN PVOID ResourceManagerInformation、
IN ULONG ResourceManagerInformationLength）；
・このルーチンはＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅによって表されるＲＭＯについてのこの要求された情報を設定する。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：情報が修正されているこのＲｅｓｏｕｒｃｅＭａｎａｇｅｒを示すハンドルを与える。

ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎ：要求されるこのＲｅｓｏｕｒｃｅＭａｎａｇｅｒ情報が記憶されるバッファにポインタを与える。

・リターン値：

CreateEnlistment
（IN PHANDLE ResourceManagerHandle、
IN PHANDLE TransactionHandle、
IN NOTIFICATION_MASK NotificationMask、
IN LPVOID TransactionKey Optional);
・このルーチンは、ＲＭＯを特定のトランザクションに結合（ｊｏｉｎｔ）させ、それに関連した通知を受信する。

・このＣｒｅａｔｅＥｎｌｉｓｔｍｅｎｔ呼出しは、べき等（ｉｄｅｍｐｏｔｅｎｔ）であり、ＲＭはこのルーチンを複数回呼び出して、そのＮｏｔｉｆｉｃａｔｉｏｎＭａｓｋまたはＴｒａｎｓａｃｔｉｏｎＫｅｙを変更することができる。ＣｒｅａｔｅＥｎｌｉｓｔｍｅｎｔに対する後続の呼出しは、このトランザクション上で新しいエンリストメントを作成せずに通知マスクおよびトランザクションキーを置換する。

・ＮｏｔｉｆｉｃａｔｉｏｎＭａｓｋを使用して通知が複数回受信されることを要求することができる。例えば、ＰＲＥＰＲＥＰＡＲＥ通知を受信するＲＭは、ＪｏｉｎＴｒａｎｓａｃｔｉｏｎを呼び出し、ＰＲＥＰＲＥＰＡＲＥフラグを指定することによって別の通知を要求することができる。したがって、ＲＭは、複数のＰＲＥＰＲＥＰＡＲＥ要求を受信することができる。このような要求は拒絶されることもあり、このトランザクションが、この要求された通知が受信されているはずのポイントを以前に進んでいる場合には、これは望ましいこともある。例えば、あるＲＭが既にＰＡＲＥに通知されているときに、ＰＲＥＰＲＥＰＡＲＥを要求することは認められない。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：ＲＭにハンドルを供給してこの指定されたトランザクションについての通知を受信する。

ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このＲＭが参加することを望むトランザクションに対してハンドルを与える。

ＮｏｔｉｆｉｃａｔｉｏｎＭａｓｋ：ＲＭがこのトランザクションに関して受信したいと思う通知を指定する。有効なマスクは、以下のようになっており、これらは一緒にＯＲをとることもできる。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＭＡＳＫ＿ＲＭ：ＲＭ（ＰＲＥＰＡＲＥ、ＣＯＭＭＩＴ、ＲＯＬＬＢＡＣＫ、ＳＡＶＥＰＯＩＮＴ）が望む一般の通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＭＡＳＫ＿ＣＲＭ：ＣＲＭまたは上位ＴＭ（ＰｒｅＰｒｅｐａｒｅ＿Ｃｏｍｐｌｅｔｅ、ＰｒｅｐａｒｅＣｏｍｐｌｅｔｅ、ＣｏｍｍｉｔＣｏｍｐｌｅｔｅ、ＲｏｌｌｂａｃｋＣｏｍｐｌｅｔｅ、ＳａｖｅｂａｃｋＣｏｍｐｌｅｔｅ）が望む一般の通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＰＲＥＰＲＥＰＡＲＥ：ＰｒｅＰｒｅｐａｒｅに対する通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＰＲＥＰＡＲＥ：ＰＲＥＰＡＲＥに対する通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＣＯＭＭＩＴ：ＣＯＭＭＩＴに対する通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＲＯＬＬＢＡＣＫ：ＲＯＬＬＢＡＣＫに対する通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＰＲＥＰＲＥＰＡＲＥ＿ＣＯＭＰＬＥＴＥ：ＰＲＥＰＲＥＰＡＲＥが完了しているという通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＰＲＥＰＡＲＥ＿ＣＯＭＰＬＥＴＥ：ＰＲＥＰＡＲＥが完了しているという通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＣＯＭＭＩＴ＿ＣＯＭＰＬＥＴＥ：ＣＯＭＭＩＴが完了しているという通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＲＯＬＬＢＡＣＫ＿ＣＯＭＰＬＥＴＥ：ＲＯＬＬＢＡＣＫが完了しているという通知。

ＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＹ＿ＳＡＶＥＰＯＩＮＴ＿ＣＯＭＰＬＥＴＥ：ＳＡＶＥＰＯＩＮＴが完了しているという通知。

ＴｒａｎｓａｃｔｉｏｎＫｅｙ：ＲＭがこのトランザクションについての任意の通知とともに受信したいと思う不明瞭なポインタ値を指定する。このＲＭは、このポインタ値を使用して通知をこのＲＭアドレス空間中のあるオブジェクトに関連づけ、それによって通知が行われるたびにルックアップを実施する必要をなくすることができる。

・リターン値：

GetNotificationResourceManager
（IN PHANDLE ResourceManagerHandle、
IN PTRANSACTION_NOTIFICATION TransactionNotification、
IN PLARGE_INTEGER Timeout Optional);
・どれかが使用可能な場合、このルーチンは、ＲＭ通知を照会し、戻す。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒＨａｎｄｌｅ：通知を戻す対象のＲｅｓｏｕｒｃｅＭａｎａｇｅｒを示すハンドルを与える。

ＴｒａｎｓａｃｔｉｏｎＮｏｔｉｆｉｃａｔｉｏｎ：この第１の使用可能な通知で満たすべきＴＲＡＮＳＡＣＴＩＯＮ＿ＮＯＴＩＦＩＣＡＴＩＯＮ構造にポインタを与える。

Ｔｉｍｅｏｕｔ：使用可能になる通知を待ちながら、それ以降、呼出し側はブロックしたいと考える時刻を与える。このタイムアウトが満了するときに何も使用可能でない場合には、この呼出し側は、ＳＴＡＴＵＳ＿ＴＩＭＥＯＵＴと共に戻る。

・リターン値：

以上でリストアップした、トランザクションに参加した後にＲＭＯカーネルオブジェクトによってＴＸカーネル上でオペレーションを実装するこれらのＡＰＩのより詳細な記述が、以下に含まれている。この記述は、このルーチン、対応する引数、およびリターン値を含んでいる。

PrePrepareComplete
（IN PHANDLE EnlistmentHandle）；
・このルーチンは、このＫＴＭが要求するときに、ＲＭがトランザクションのプリプリペア処理（別名「フェーズ０」）を完了していることを示す。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このプリプリペアオペレーションが完了しているトランザクションを示すハンドルを与える。

・リターン値：

PrepareComplete
（IN PHANDLE EnlistmentHandle）；
・このルーチンは、ＫＴＭが要求するときに、このＲＭがトランザクションのプリペアを完了していることを示す。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このプリペアオペレーションが完了しているトランザクションを示すハンドルを与える。

・リターン値：

RollbackComplete
（IN PHANDLE EnlistmentHandle）；
・このルーチンは、要求されたように、ＲＭがトランザクションによって実施される作業のロールバックを正常に完了していることを示す。ＲＭが、要求されたようにこのトランザクションを正常にロールバックすることができない場合には、ＲＭは、ＲｏｌｌｂａｃｋＴｒａｎｓａｃｔｉｏｎを介して完全なロールバックを求める要求を発行すべきである。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このロールバックオペレーションが完了しているトランザクションを示すハンドルを与える。

・リターン値：

CommitComplete
（IN PHANDLE EnlistmentHandle）；
・このルーチンは、要求されたように、ＲＭが、トランザクションによって実施される作業のコミットを完了していることを示す。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このコミットオペレーションが完了しているトランザクションを示すハンドルを与える。

・リターン値：

さらに、伝搬ルーチン（ｐｒｏｐａｇａｔｉｏｎｒｏｕｔｉｎｅ）をこのカーネルオブジェクトについて提供することができる。このようなルーチンの実施例を以下に示す。

RegisterProtocolAddressInformation
（IN HANDLE ResourceManager、
IN PROTOCOL_ID ProtocolId、
IN ULONG ProtocolInformationSize、
IN PVOID ProtocolInformation Optional)。

・このルーチンは、リソースマネージャを特定のプロトコルに対する通信リソースマネージャとして登録する。このルーチンはまた、情報のブロブをこのプロトコルに関連づける。ただ１つのリソースマネージャしか、所与のマシン上のあるプロトコルに対して登録をすることができない。

・引数：
ＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：登録中のリソースマネージャにハンドルを与える。

ＰｒｏｔｏｃｏｌＩｄ：このプロトコルを識別するＧＵＩＤ。

ＰｒｏｔｏｃｏｌＩｎｆｏｒｍａｔｉｏｎＳｉｚｅ：ＰｒｏｔｏｃｏｌＩｎｆｏｒｍａｔｉｏｎのサイズ。

ＰｒｏｔｏｃｏｌＩｎｆｏｒｍａｔｉｏｎ：このプロトコルに関連するオプションのブロブ。

・リターン値：

MarshallTransaction
（IN PHANDLE TransactionHandle、
IN ULONG NumberOfProtocols、
IN PPROTOCOL_ID ProtocolArray、
IN ULONG BufferLength、
IN PVOID Buffer、
OUT PULONG BufferUsed Optional)。

・このルーチンは、ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅに対応するこのトランザクションの表現がバッファ中に直列に配列されることを要求する。

ＮｕｍｂｅｒＯｆＰｒｏｔｏｃｏｌｓ：このプロトコルアレイのサイズを示す。

ＰｒｏｔｏｃｏｌＡｒｒａｙ：このトランザクションをマーシャリングするために使用することができるプロトコルを指定するＰＲＯＴＯＣＯＬ＿ＩＤ（ＧＵＩＤ）のアレイ。このアレイは、プリファランス（ｐｒｅｆｅｒｅｎｃｅ）によって順序づけすべきである（このアレイ中の第１のプロトコルは、優先のプロトコルであり、第２のプロトコルは、第２最優先のプロトコルであるなど）。

ＢｕｆｆｅｒＬｅｎｇｔｈ：使用可能なバッファの長さを与える。

Ｂｕｆｆｅｒ：このトランザクションの直列配列を記憶すべきバッファにポインタを与える。

ＢｕｆｆｅｒＵｓｅｄ：バッファ中に書き込まれる実際のバイトを記憶すべきロケーションにポインタを与える。

・リターン値：

GetProtocolAddressInformation
（IN ULONG AddressBufferSize、
OUT PVOID AddressBuffer、
OUT PULONG AddressBufferUsed Optional）。

・このルーチンは、このマシン上ですべての登録済みのプロトコルを表現する情報が、ＡｄｄｒｅｓｓＢｕｆｆｅｒ中で、直列に配列されることを要求する。次いでこの情報を別のマシンに渡し、これをＰｕｓｈＴｒａｎｓａｃｔｉｏｎに対する引数として使用してＡｄｄｒｅｓｓＩｎｆｏｒｍａｔｉｏｎが生成されるマシンに対してトランザクションを転送（ｐｕｓｈ）することができる。

・引数：
ＡｄｄｒｅｓｓＢｕｆｆｅｒＳｉｚｅ：使用可能なバッファの長さを与える。

ＡｄｄｒｅｓｓＢｕｆｆｅｒ：使用可能なバッファの長さを与える。

ＡｄｄｒｅｓｓＢｕｆｆｅｒＵｓｅｄ：このトランザクションの直列配列が記憶されるバッファのロケーションにポインタを与える。

・リターン値：

PullTransaction
（OUT PHANDLE TransactionHandle、
IN ULONG NumberOfProtocols、
IN PCRM_PROTOCOL_ID ProtocolArray、
IN ULONG BufferLength、
IN PVOID Buffer）。

・このルーチンは、バッファ中の直列配列によって表現されるトランザクションが、トランザクションマネージャにより使用可能になることを要求する。このトランザクションが、登録済みのリソースマネージャのうちの１つによって正常に伝搬された後に、この新しいトランザクションオブジェクトに対するハンドルが戻される。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：この新しいトランザクションを表すハンドルが記憶されるべきところにポインタを与える。

ＰｒｏｔｏｃｏｌＡｒｒａｙ：このトランザクションをマーシャリングするために使用することができるプロトコルを指定するＰＲＯＴＯＣＯＬ＿ＩＤ（ＧＵＩＤ）のアレイ。このアレイは、プリファランスによって順序づけすべきである（このアレイ中の第１のプロトコルは、優先のプロトコルであり、第２のプロトコルは、第２最優先のプロトコルであるなど）。

Ｂｕｆｆｅｒ：このトランザクションの直列配列が記憶されるバッファにポインタを与える。

・リターン値：

PushTransaction
（IN HANDLE TransactionHandle、
IN ULONG NumberOfProtocols、
IN PCRM_PROTOCOL_ID ProtocolArray、
IN ULONG DestinationInfoLength、
IN PVOID DestinationInfo、
IN ULONG ResponseBufferLength、
OUT PVOID ResponseBuffer、
OUT PULONG ResponseBufferUsed Optional、
OUT PULONG PushCookie Optional)。

・このルーチンは、このトランザクションが、プッシュスタイルの伝搬を使用して宛先マシンに伝搬されることを要求する。プロトコルは、ＰｒｏｔｏｃｏｌＡｒｒａｙ中にリストされる順序で、成功するまで使用されることになる。この宛先マシンへ伝搬する際にどのプロトコルでもうまくいかない場合には、このルーチンはｆａｉｌｕｒｅを戻すことになる。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：このリモートマシンに伝搬すべきこのトランザクションオブジェクトにポインタを与える。

ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｅｎｇｔｈ：使用可能なＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｅｎｇｔｈの長さを与える。

ＤｅｓｔｉｎａｔｉｏｎＩｎｆｏ：この宛先についての「エンドポイント」情報が記憶されるバッファに対してポインタを与える。これは、この宛先マシン上のＧｅｔＰｒｏｔｏｃｏｌＡｄｄｒｅｓｓＩｎｆｏｒｍａｔｉｏｎに対する呼出から受信される出力とすることができる。

ＲｅｓｐｏｎｓｅＢｕｆｆｅｒＬｅｎｇｔｈ：使用可能なＲｅｓｐｏｎｓｅＢｕｆｆｅｒの長さを与える。

ＲｅｓｐｏｎｓｅＢｕｆｆｅｒ：このトランザクションの直列配列が記憶されるバッファにポインタを与える。

ＰｕｓｈＣｏｏｋｉｅ：このプッシュ要求を表すクッキーが記憶されることになるバッファにポインタを与える。

・リターン値：

GetPushTransactionBuffer
（IN HANDLE TransactionHandle、
IN ULONG PushCookie、
IN ULONG ResponseBufferLength、
OUT PVOID ResponseBuffer、
OUT PULONG ResponseBufferUsed Optional)。

・ＰｕｓｈＴｒａｎｓａｃｔｉｏｎに対する初期呼出しが、ＳＴＡＴＵＳ＿ＢＵＦＦＥＲ＿ＴＯＯ＿ＳＭＡＬＬリターンコードを受信した場合に、この呼出しを使用してＰｕｓｈＴｒａｎｓａｃｔｉｏｎに対する呼出しの出力を検索する。この場合には、呼出し側は、ＧｅｔＰｕｓｈＴｒａｎｓａｃｔｉｏｎＢｕｆｆｅｒをコールし、十分なバッファサイズで渡すことになる。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：この新しいトランザクションを表すハンドルが記憶されるロケーションにポインタを与える。

・リターン値：

PropagationComplete
（IN HANDLE EnlistmentHandle、
IN ULONG RequestCookie、
IN ULONG BufferLength、
IN PVOID Buffer）。

・トランザクションの伝搬を正常に完了した後に、このルーチンは、ＣＲＭによって呼出される。

・引数：
ＴｒａｎｓａｃｔｉｏｎＨａｎｄｌｅ：この新しいトランザクションを表すハンドルを記憶すべきロケーションにポインタを与える。

ＲｅｑｕｅｓｔＣｏｏｋｉｅ：どの要求が完了しているかを示すために、この元のＰＲＯＰＡＧＡＴＥ通知の引数中で受信されたこのＲｅｑｕｅｓｔＣｏｏｋｉｅを与える。

ＢｕｆｆｅｒＬｅｎｇｔｈ：使用可能なこのバッファの長さを与える。

・リターン値：

PropagationFailed
（IN HANDLE ResourceManagerHandle、
IN ULONG RequestCookie、
IN STATUS PropStatus）。

・ＣＲＭは、このルーチンを使用して要求されたときにこのトランザクションを伝搬することに失敗していることを示す。

・リターン値：

実施例のコンピューティング環境
図９は、一般的なコンピュータ環境９００を示しており、このコンピュータ環境を使用して本明細書中で説明している技術を実装することができる。このコンピュータ環境９００は、コンピューティング環境の一実施例にすぎず、コンピュータおよびネットワークアーキテクチャの利用範囲あるいは機能について、どのような限定も示唆するものではない。また、このコンピュータ環境９００は、この実施例のコンピュータ環境９００において示されたコンポーネントのうちのどの１つまたは組合せに関してもどのような依存性または要件を有するものとも解釈すべきではない。

コンピュータ環境９００は、コンピュータ９０２の形態の汎用コンピューティングデバイスを含んでいる。コンピュータ９０２のコンポーネントは、それだけには限定されないが、１つまたは複数のプロセッサまたは処理装置９０４と、システムメモリ９０６と、プロセッサ９０４を含めて様々なシステムコンポーネントをシステムメモリ９０６に結合するシステムバス９０８とを含むことが可能である。

システムバス９０８は、メモリバスまたはメモリコントローラ、周辺バス、アクセラレーティドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄｇｒａｐｈｉｃｓｐｏｒｔ）、および様々なバスアーキテクチャのうちのどれかを使用したプロセッサバスまたはローカルバスを含めて、いくつかのタイプのバス構造のうちの１つまたは複数のいずれかを表す。実施例として、このようなアーキテクチャは、ＩＳＡバス、ＭＣＡバス、ＥＩＳＡ（ＥｎｈａｎｃｅｄＩＳＡ拡張ＩＳＡ）バス、ＶＥＳＡ（ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓＳｔａｎｄａｒｄＡｓｓｏｃｉａｔｉｏｎビデオエレクトロニクス規格協会）ローカルバス、メザニンバスとしても知られているＰＣＩバス、ＰＣＩエクスプレス（Ｅｘｐｒｅｓｓ）バス、ＵＳＢ、ＳＤ（ＳｅｃｕｒｅＤｉｇｉｔａｌセキュアデジタル）バス、またはＩＥＥＥ１３９４バス、すなわちファイヤワイヤ（ＦｉｒｅＷｉｒｅ）を含んでいる。

コンピュータ９０２は、様々なコンピュータ読取り可能媒体を含むこともできる。このような媒体は、コンピュータ９０２によってアクセス可能な任意の入手可能な媒体とすることが可能であり、揮発性媒体も不揮発性媒体も、着脱可能媒体も着脱不能媒体も含んでいる。

システムメモリ９０６は、ＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙランダムアクセスメモリ）９１０などの揮発性メモリ、および／またはＲＯＭ（ｒｅａｄｏｎｌｙｍｅｍｏｒｙ読取り専用メモリ）９１２やフラッシュＲＡＭなどの不揮発性メモリの形態のコンピュータ読取り可能媒体を含んでいる。起動中などにコンピュータ９０２内の要素間で情報を転送する助けをする基本ルーチンを含むＢＩＯＳ（Ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ基本入出力システム）９１４は、ＲＯＭ９１２またはフラッシュＲＡＭに記憶される。ＲＡＭ９１０は、一般に処理装置９０４によって直ちにアクセス可能な、かつ／または現在操作されているデータおよび／またはプログラムモジュールを含んでいる。

コンピュータ９０２は、他の着脱可能／着脱不能の揮発性／不揮発性のコンピュータストレージ媒体を含むこともできる。実施例として、図９は、着脱不能の不揮発性の磁気媒体（図示せず）から読み取りそれに書き込むためのハードディスクドライブ９１６、着脱可能な不揮発性の磁気ディスク９２０（例えば、「フロッピー（登録商標）ディスク」）から読み取りそれに書き込むための磁気ディスクドライブ９１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、他の光媒体など着脱可能な不揮発性の光ディスク９２４から読み取りまたはそれに書き込みあるいはその両方を行うための光ディスクドライブ９２２を示している。ハードディスクドライブ９１６、磁気ディスクドライブ９１８、および光ディスクドライブ９２２は、それぞれ１つまたは複数のデータ媒体インターフェース９２５によってシステムバス９０８に接続されている。代わりに、ハードディスクドライブ９１６、磁気ディスクドライブ９１８、および光ディスクドライブ９２２は、１つまたは複数のインターフェース（図示せず）によってシステムバス９０８に接続することもできる。

これらのディスクドライブおよびこれらの関連するコンピュータ読取り可能媒体は、コンピュータ９０２用のコンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供する。この実施例では、ハードディスク９１６、着脱可能磁気ディスク９２０、および着脱可能光ディスク９２４が示されているが、磁気カセットまたは他の磁気ストレージデバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌｖｅｒｓａｔｉｌｅｄｉｓｋデジタル多用途ディスク）または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙｅｒａｓａｂｌｅｐｒｏｇｒａｍｍａｂｌｅｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ電気的消去可能プログラム可能読取り専用メモリ）など、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ読取り可能媒体を利用してこの実施例のコンピューティングシステムおよびコンピューティング環境を実装することもできることが理解されよう。

実施例としてオペレーティングシステム９２６、１つまたは複数のアプリケーションプログラム９２８、他のプログラムモジュール９３０、およびプログラムデータ９３２を含めて、任意数のプログラムモジュールをハードディスク９１６、磁気ディスク９２０、光ディスク９２４、ＲＯＭ９１２、および／またはＲＡＭ９１０に記憶することができる。このようなオペレーティングシステム９２６、１つまたは複数のアプリケーションプログラム９２８、他のプログラムモジュール９３０、およびプログラムデータ９３２（またはそれらの何らかの組合せ）のそれぞれは、前述の実施形態の例に従ってトランザクションを実行して、分散ファイルシステムをサポートする存在するコンポーネントのすべてまたは一部分を実装することができる。

ユーザは、キーボード９３４やポインティングデバイス９３６（例えば、「マウス」）などの入力デバイスを介してコマンドおよび情報をコンピュータ９０２に入力することができる。他の入力デバイス９３８（詳細には示さず）は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、および／またはスキャナなどを含むことができる。これらおよび他の入力デバイスは、システムバス９０８に結合された入出力インターフェース９４０を介して処理装置９０４に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインターフェースおよびバス構造によって接続することもできる。

モニタ９４２または他のタイプのディスプレイデバイスも、ビデオアダプタ９４４などのインターフェースを介してシステムバス９０８に接続することができる。モニタ９４２に加えて、他の出力周辺デバイスには、Ｉ／Ｏインターフェース９４０を介してコンピュータ９０２に接続することができるスピーカ（図示せず）やプリンタ９４６などのコンポーネントも含めることが可能である。

コンピュータ９０２は、リモートコンピューティングデバイス９４８など１台または複数台のリモートコンピュータに対する論理接続を使用してネットワーク環境で動作することが可能である。実施例として、リモートコンピューティングデバイス９４８は、ＰＣ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の共通ネットワークノードなどとすることが可能である。リモートコンピューティングデバイス９４８は、コンピュータ９０２に対して本明細書中で説明しているエレメントおよび特徴の多くまたはすべてを含むことができるポータブルコンピュータとして示されている。代わりに、コンピュータ９０２は、非ネットワーク環境でも同様に動作することができる。

コンピュータ９０２とリモートコンピュータ９４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）９５０および一般的なワイドエリアネットワーク（ＷＡＮ）９５２として示されている。このようなネットワーキング環境はオフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的なものである。

ＬＡＮネットワーキング環境中で実装されるとき、コンピュータ９０２は、ネットワークインターフェースまたはネットワークアダプタ９５４を介してローカルネットワーク９５０に接続される。ＷＡＮネットワーキング環境中で実装されるときには、コンピュータ９０２は、一般にワイドネットワーク９５２上で通信を確立するためのモデム９５６または他の手段を含んでいる。コンピュータ９０２に内蔵または外付けにすることができるモデム９５６は、Ｉ／Ｏインターフェース９４０または他の適切なメカニズムを介してシステムバス９０８に接続することができる。ここに示すネットワーク接続は実施例であり、コンピュータ９０２と９４８との間で少なくとも１つの通信リンクを確立する他の手段を使用することもできる。

コンピューティング環境９００と共に示すネットワーク環境などのネットワーク環境において、コンピュータ９０２に関連して示すプログラムモジュールまたはその一部分は、リモートメモリストレージデバイスに記憶することができる。実施例として、リモートアプリケーションプログラム９５８は、リモートコンピュータ９４８のメモリデバイス上に存在する。例示のために、アプリケーションまたはプログラム、およびこのオペレーティングシステムなど他の実行可能なプログラムコンポーネントは、本明細書中では個別のブロックとして示されているが、かかるプログラムおよびコンポーネントは、コンピューティングデバイス９０２の異なるストレージコンポーネント中にいろいろな時刻に存在し、このコンピュータの少なくとも１つのデータプロセッサによって実行されることが理解されよう。

様々なモジュールおよび技法は、１台または複数台のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な状況において本明細書中において説明することができる。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。これらのプログラムモジュールなどは、仮想マシンや他のジャストインタイムコンパイル実行環境などの中で、ネイティブコード（ｎａｔｉｖｅｃｏｄｅ）として実行し、またはダウンロードし実行することができる。一般に、プログラムモジュールの機能は、様々な実施形態において必要に応じて組み合わせ、または分散させることができる。

これらのモジュールおよび技法の実装は、コンピュータ読取り可能媒体の何らかの形態上に記憶し、またはその形態に渡って伝送することができる。コンピュータ読取り可能媒体は、コンピュータによりアクセスすることが可能な任意の使用可能な媒体とすることが可能である。実施例として、限定するものではないが、コンピュータ読取り可能媒体は、「コンピュータストレージ媒体」と「通信媒体」を含むことができる。

「コンピュータストレージ媒体」は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータなどの情報の記憶のための任意の方法または技術により実装される揮発性および不揮発性の、着脱可能および着脱不能の媒体を含んでいる。コンピュータストレージ媒体は、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、もしくは他の磁気ストレージデバイス、または所望の情報を記憶するために使用することができコンピュータによりアクセスすることが可能な他の任意の媒体を、含んでいる。

「通信媒体」は一般に、搬送波や他の搬送メカニズムなどの被変調データ信号の形で、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータを実施する。通信媒体は、任意の情報配信媒体も含んでいる。用語「被変調データ信号」は、信号中の情報を符号化するようにしてその信号中の１つまたは複数のその特性が設定あるいは変更された信号を意味する。非限定的な実施例にすぎないが、通信媒体には、有線ネットワークや直接配線接続などの有線媒体、並びに、音響、ＲＦ、赤外線、他の無線媒体などの無線媒体が含まれる。以上のうちの任意の組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれる。

本明細書全体を通して、「一実施形態（ｏｎｅｅｍｂｏｄｉｍｅｎｔ）」、「一実施形態（ａｎｅｍｂｏｄｉｍｅｎｔ）」または「実施形態の一例（ａｎｅｘａｍｐｌｅｅｍｂｏｄｉｍｅｎｔ）」と言及しているが、これらは、説明している特定の機能、構成、または特徴が本発明の少なくとも一実施形態中に含まれることを意味する。したがって、このようなフレーズの使用によって、ただ１つの実施形態を超えたものについて言及することができる。さらに、この説明される機能、構成、または特徴は、１つまたは複数の実施形態において適切な任意の方法で組み合わせることができる。

しかし、本発明は、１つまたは複数の特定の細部によらなくても、あるいは、他の方法、リソース、材料などを用いても実行することができることは当業者に理解されるだろう。他の事例においては、本発明の態様を単にあいまいにしてしまうことがないように、よく知られている構成、リソース、またはオペレーションを詳細に示さず、または説明していない。

本発明の実施形態の例および用途について例示し説明してきたが、本発明は上述の正確な構成およびリソースに限定されるものでないことを理解されたい。本明細書中に開示している本発明の方法およびシステムの構成、オペレーション、および細部において、請求している本発明の範囲を逸脱することなく、当業者にとって明らかな様々な修正、変更、および変形を行うことができる。

トランザクション処理リモートファイルオペレーションを使用することができるシステムの一実施例を示す図である。図１のシステムのクライアントおよびサーバのコンポーネントの一実施例を示す図である。図２のクライアントとサーバの間のトランザクション処理リモートファイルオペレーションについての実施例の処理フローを示す図である。図２のクライアントとサーバの間のトランザクション処理リモートファイルオペレーションについての実施例の処理フローを示す図である。図２のクライアントおよびサーバによる複数のリモートファイルアクセスの一実施例を示す図である。ネットワーク上のトランザクションの２相コミットを実施するための一実施例の処理フローを示す図である。トランザクション管理を実装するためのコンポーネントの一実施例を示す図である。カーネルレベルトランザクションについての一実施例処理フローを示す図である。セキュリティフィーチャの一実施例を示す図である。様々な実施形態による、本明細書中で説明される技法を実装するために使用することができる一般的なコンピュータ環境を示す図である

Claims

ローカルデバイスとリモートデバイスとの間でトランザクション処理リモートファイルオペレーションをサポートするシステムであって、
トランザクションマネージャと、
要求を受信して、前記リモートデバイス中に存在するファイルに対してファイルオペレーションを実行するリダイレクタであって、前記ローカルデバイスおよび前記リモートデバイスはネットワークに接続され、前記リダイレクタは、トランザクション内において前記ネットワーク上で前記リモートデバイスに前記要求を送信することと、
を備えることを特徴とするシステム。
前記トランザクションマネージャは、ファイルシステムに一体化されていないことを特徴とする請求項１に記載のシステム。
前記リダイレクタは、前記ファイルに関連付けられたファイルシステム識別子（Ｆｉｄ）およびバージョン識別子を含む、前記リモートデバイスからの受信ファイル情報であることを特徴とする請求項１に記載のシステム。
前記リダイレクタは、前記ファイルに関連付けられた前記Ｆｉｄ情報および前記バージョン識別子情報を含む、前記ファイルに関連付けられたファイル制御ブロック（ＦＣＢ）を選択的に作成することを特徴とする請求項３に記載のシステム。
前記リダイレクタは、既存のＦＣＢを前記要求に対して使用することができるかどうかを判定することを特徴とする請求項４に記載のシステム。
前記リダイレクタは、コミットされていないトランザクションに関連付けられた既存のＦＣＢを前記要求に対して使用することができるかどうかを判定することを特徴とする請求項５に記載のシステム。
前記リダイレクタは、既存のＦＣＢを前記要求に対して使用することができるかどうかについて判定する際に、前記要求についてのパスネームおよびトランザクションコンテキストを前記既存のＦＣＢに関連付けられたパスネームと比較することを特徴とする請求項５に記載のシステム。
前記トランザクションマネージャは、カーネルレベルトランザクションマネージャであることを特徴とする請求項１に記載のシステム。
前記リダイレクタは、前記リダイレクタにより要求されなかった前記ファイルについて実行されているファイルオペレーションに応答して、前記リモートデバイスが前記ローカルマシンに信号で伝えるべきことを、前記要求中に選択的に指示することを特徴とする請求項１に記載のシステム。
前記リダイレクタは、サーバメッセージブロック（ＳＭＢ）プロトコルに基づいたプロトコルを使用して前記トランザクションを要求と共に送信することを特徴とする請求項１に記載のシステム。
前記プロトコルは、非トランザクション処理リモートファイルオペレーションをサポートすることを特徴とする請求項１０に記載のシステム。
請求項１に記載のコンポーネントをその上に記憶していることを特徴とするコンピュータ読取り可能媒体。
ローカルデバイスとリモートデバイスとの間でトランザクション処理リモートファイルオペレーションをサポートするシステムであって、
前記ローカルデバイス中に存在するファイルについてトランザクション処理ファイルオペレーションを求める要求をリモートデバイスから受信するサーバコンポーネント（ＳＲＶ）と、
トランザクションマネージャと、
前記ＳＲＶコンポーネントおよび前記トランザクションマネージャに応答して、前記ファイルについて前記要求されたファイルオペレーションを実行するファイルシステムであって、前記ローカルデバイスおよび前記リモートデバイスは、ネットワークに接続されることと、
を備えること特徴とするシステム。
前記ＳＲＶコンポーネントは、前記ファイルに関連付けられたファイルシステム識別子（Ｆｉｄ）およびバージョン識別子を前記リモートデバイスに提供することを特徴とする請求項１３に記載のシステム。
前記トランザクションマネージャは、カーネルレベルトランザクションマネージャであることを特徴とする請求項１３に記載のシステム。
前記ファイルシステムは、前記リモートデバイスにより要求されなかった前記ファイルについて実行されているファイルオペレーションに応答して、選択的に、前記ＳＲＶコンポーネントが前記リモートデバイスに信号で伝えるようにすることを特徴とする請求項１３に記載のシステム。
前記ＳＲＶコンポーネントは、サーバメッセージブロック（ＳＭＢ）プロトコルに基づいたプロトコルを使用して、前記トランザクションを要求と共に送信することを特徴とする請求項１３に記載のシステム。
前記プロトコルは、非トランザクション処理リモートファイルオペレーションをサポートすることを特徴とする請求項１７に記載のシステム。
請求項１２に記載のコンポーネントをその上に記憶していることを特徴とするコンピュータ読取り可能媒体。
ローカルデバイス上でトランザクション処理リモートファイルオペレーションを実装する方法であって、
トランザクション処理リモートファイルオペレーションを求める要求を受信するステップと、
トランザクションを検索するステップと、
前記トランザクションをマーシャリングするステップと、
前記トランザクションを前記要求と共にネットワーク上でリモートデバイスに送信するステップと、
前記ファイルオペレーションからもたらされる情報を前記リモートデバイスから受信するステップと、
を備えることを特徴とする方法。
前記リモートデバイスから受信される情報は、ファイル識別子（Ｆｉｄ）およびバージョン識別子を含むことを特徴とする請求項２０に記載の方法。
トランザクション処理リモートファイルオペレーションを求める要求を受信する前記ステップは、
前記要求がリモートデバイス上のファイルオペレーションを求めるものかどうかを判定するステップと、
前記要求がリモートデバイス上のファイルオペレーションを求めるものである場合に前記要求に対する名前を提供するステップと、
前記ファイルに関連付けられた前記Ｆｉｄ情報および前記バージョン識別子情報を含む、前記ファイルに関連付けられたファイル制御ブロック（ＦＣＢ）を選択的に作成するステップと、
をさらに含むことを特徴とする請求項２１に記載の方法。
ＦＣＢを選択的に作成する前記ステップは、既存のＦＣＢを前記要求に対して使用することができるかどうかを判定するステップをさらに含むことを特徴とする請求項２２に記載の方法。
既存のＦＣＢを前記要求に対して使用することができるかどうかを判定する前記ステップは、前記既存のＦＣＢがコミットされていないトランザクションに関連付けられているかどうかを判定するステップをさらに含むことを特徴とする請求項２３に記載の方法。
既存のＦＣＢが前記要求に対して使用することができるかどうかを判定する前記ステップは、前記要求に対するパスネームおよびトランザクションコンテキストを前記既存のＦＣＢに関連付けられたパスネームと比較するステップをさらに含むことを特徴とする請求項２３に記載の方法。
前記方法は、カーネルモードで実行されることを特徴とする請求項２０に記載の方法。
前記ローカルデバイス以外のデバイスにより要求された前記ファイルについて実行されているファイルオペレーションに応答して、前記リモートデバイスが前記ローカルマシンに信号で伝えるべきことを前記要求中に選択的に指示するステップをさらに備えることを特徴とする請求項２０に記載の方法。
前記トランザクションは、サーバメッセージブロック（ＳＭＢ）プロトコルに基づいたプロトコルを使用して要求と共に送信されることを特徴とする請求項２０に記載の方法。
前記プロトコルは、非トランザクション処理リモートファイルオペレーションをサポートすることを特徴とする請求項２８に記載の方法。
トランザクション処理リモートファイルオペレーションを求める要求を受信するステップと、
トランザクションを検索するステップと、
前記トランザクションをマーシャリングするステップと、
前記トランザクションを前記要求と共にネットワーク上でリモートデバイスに送信するステップと、
前記ファイルオペレーションからもたらされる情報を前記リモートデバイスから受信するステップと、
を備えるオペレーションを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記リモートデバイスから受信される情報は、ファイル識別子（Ｆｉｄ）およびバージョン識別子を含むことを特徴とする請求項３０に記載のコンピュータ読取り可能媒体。
トランザクション処理リモートファイルオペレーションを求める要求を受信する前記ステップは、
前記要求がリモートデバイス上のファイルオペレーションを求めるものかどうかを判定するステップと、
前記要求がリモートデバイス上のファイルオペレーションを求めるものである場合に前記要求に対する名前を提供するステップと、
前記ファイルに関連付けられた前記Ｆｉｄ情報および前記バージョン識別子情報を含む、前記ファイルに関連付けられたファイル制御ブロック（ＦＣＢ）を選択的に作成するステップと、
をさらに含むことを特徴とする請求項３１に記載のコンピュータ読取り可能媒体。
ＦＣＢを選択的に作成する前記ステップは、既存のＦＣＢを前記要求に対して使用することができるかどうかを判定するステップをさらに含むことを特徴とする請求項３２に記載のコンピュータ読取り可能媒体。
既存のＦＣＢを前記要求について使用することができるかどうかを判定する前記ステップは、前記既存のＦＣＢがコミットされていないトランザクションに関連付けられているかどうかを判定するステップをさらに含むことを特徴とする請求項３３に記載のコンピュータ読取り可能媒体。
ローカルデバイスとリモートデバイスとの間でトランザクション処理リモートファイルオペレーションを実装する方法であって、
前記ローカルデバイス中に存在するファイルについてトランザクション処理ファイルオペレーションを求める要求をリモートデバイスから受信するステップであって、前記ローカルデバイスおよび前記リモートデバイスはネットワークに接続されていることと、
前記トランザクションの一部分となる前記要求されたファイルオペレーションを前記ファイルについて実行するステップと、
を備えることを特徴とする方法。
前記ファイルに関連付けられたファイルシステム識別子（Ｆｉｄ）およびバージョン識別子を前記リモートデバイスに提供するステップをさらに備えることを特徴とする請求項３５に記載の方法。
前記方法は、カーネルモードで実行されることを特徴とする請求項３５に記載の方法。
前記リモートデバイスにより要求されなかった前記ファイルについて実行されるファイルオペレーションに応答して、前記リモートデバイスに選択的に信号を伝えるステップをさらに備えることを特徴とする請求項３５に記載の方法。
前記ローカルデバイスと前記リモートデバイスは、サーバメッセージブロック（ＳＭＢ）プロトコルに基づいたプロトコルを使用して、前記ネットワーク上で選択的に情報をやりとりすることを特徴とする請求項３５に記載の方法。
前記プロトコルは、非トランザクション処理リモートファイルオペレーションをサポートすることを特徴とする請求項３９に記載の方法。
ローカルデバイス中に存在するファイルについてトランザクション処理ファイルオペレーションを求める要求をリモートデバイスから受信するステップであって、前記ローカルデバイスおよび前記リモートデバイスはネットワークに接続されていることと、
前記トランザクションの一部分となる前記要求されたファイルオペレーションを前記ファイルについて実行するステップと、
を備えるオペレーションを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記オペレーションは、前記ファイルに関連付けられたファイルシステム識別子（Ｆｉｄ）およびバージョン識別子を前記リモートデバイスに提供するステップをさらに備えることを特徴とする請求項４１に記載のコンピュータ読取り可能媒体。
前記オペレーションは、カーネルモードで実行されることを特徴とする請求項４１に記載のコンピュータ読取り可能媒体。
前記オペレーションは、前記リモートデバイスにより要求されなかった前記ファイルについて実行されるファイルオペレーションに応答して、前記リモートデバイスに選択的に信号を伝えるステップをさらに備えることを特徴とする請求項４１に記載のコンピュータ読取り可能媒体。
ネットワークに接続されたローカルデバイスとリモートデバイスの間でトランザクション処理リモートファイルオペレーションをサポートするシステムであって、
トランザクションを管理する手段と、
前記リモートデバイス中に存在するファイルについてファイルオペレーションを実行するためにトランザクションを伴う要求を前記リモートデバイスに送信する手段と、
を備えることを特徴とするシステム。
前記ファイルに関連付けられたファイルシステム識別子（Ｆｉｄ）およびバージョン識別子を含むファイル情報を前記リモートデバイスから受信する手段をさらに備えることを特徴とする請求項４５に記載のシステム。
前記ファイルに関連付けられた前記Ｆｉｄ情報および前記バージョン識別子情報を含む、前記ファイルに関連付けられたファイル制御ブロック（ＦＣＢ）を選択的に作成する手段をさらに備えることを特徴とする請求項４６に記載のシステム。
既存のＦＣＢを前記要求に対して使用することができるかどうかを判定する手段をさらに備えることを特徴とする請求項４７に記載のシステム。
コミットされていないトランザクションに関連付けられた既存のＦＣＢを前記要求に対して使用することができるかどうかを判定する手段をさらに備えることを特徴とする請求項４８に記載のシステム。
リダイレクタにより要求されなかった前記ファイルについて実行されているファイルオペレーションに応答して、前記リモートデバイスが前記ローカルマシンに信号を伝えるべきことを前記要求中に選択的に指示する手段をさらに備えることを特徴とする請求項４５に記載のシステム。
前記トランザクションマネージャは、ファイルシステムに一体化されていないことを特徴とする請求項１３に記載のシステム。
ネットワーク上でトランザクションファイルオペレーションを実行する際に使用する方法であって、
第１のコンピューティングプラットフォーム中に存在するトランザクションマネージャからプリプリペア通知を受信するステップと、
前記第１のコンピューティングプラットフォームから第２のコンピューティングプラットフォームに前記ネットワークを介してファイルオペレーションデータを提供するステップと、
前記第１のコンピューティングプラットフォーム中に存在する前記トランザクションマネージャからプリペア通知を受信するステップと、
前記プリペア通知を含む前記第２のコンピューティングプラットフォームに前記ネットワ−クを介してメッセージを提供するステップと、
を備えることを特徴とする方法。
ネットワ−ク上でトランザクション処理ファイルオペレーションを実行する際に使用する方法であって、
トランザクション情報を受信するステップと、
ファイルもしくはディレクトリを作成もしくはオープンするために、前記ネットワ−クに接続されたコンピューティングプラットフォームに対して、前記トランザクション情報および要求を前記ネットワ−クを介して送信するステップであって、前記要求は第１の構造を含み、前記第１の構造はトランザクションコンテキストを保持するフィールド並びに前記トランザクション情報の長さを保持するフィールドを含むことと、
を備えることを特徴とする方法。
前記要求に対する応答は、ファイルシステム識別子を保持するフィールド、並びに、バージョン識別子を保持するフィールドを含む第２の構造を備えることを特徴とする請求項５３に記載の方法。
前記ネットワ−クに接続された前記コンピューティングプラットフォームがトランザクション処理ファイルオペレーションをサポートするかどうかを示すフィールドを含む応答を受信するステップをさらに備えることを特徴とする請求項５３に記載の方法。
トランザクション情報、並びに、トランザクションが前記ファイルと共に使用されることを示すフィールドを含むファイルを見つける要求を、前記ネットワークを介して前記コンピューティングプラットフォームに送信するステップをさらに備えることを特徴とする請求項５３に記載の方法。
前記ネットワークに接続された前記コンピューティングプラットフォームからの、トランザクション状態変化に関する通知を提供するメッセージを前記ネットワ−クを介して受信するステップをさらに備えることを特徴とする請求項５３に記載の方法。
ネットワ−ク上でトランザクション処理ファイルオペレーションを実行する際に使用する方法であって、
第２のコンピューティングプラットフォームにおいて第１のコンピューティングプラットフォームからのプリプリペア通知を受信するステップと、
前記第２のコンピュータプラットフォーム中に存在するトランザクションマネージャに対して前記プリプリペア通知を提供するステップと、
前記第２のコンピューティングプラットフォームにおいて、前記ネットワークを介して、前記第１のコンピューティングプラットフォームからのファイルオペレーションデータを受信するステップと、
前記第２のコンピューティングプラットフォーム中に存在するファイルシステムに対して前記ファイルオペレーションデータを提供するステップと、
前記ネットワークを介して前記第１のコンピューティングプラットフォームからのプリペア通知を受信するステップと、
前記第２のコンピューティングプラットフォーム中に存在する前記トランザクションマネージャに前記プリペア通知を提供するステップと、
を備えることを特徴とする方法。