JP4543034B2 - 資源をロックする方法、プログラム及びシステム - Google Patents

Description

本発明は、ロックおよびトランザクションの管理を対象とする。

資源（たとえば、メモリ、ディスク・ドライブ、光ファイバ・チャネルなど）は、いくつかのアプリケーション間でしばしば共用される。たとえば、それぞれがクライアント・アプリケーションを動作させている、いくつかのクライアント・コンピュータでは、１組の資源をもつ同じサーバ・コンピュータにアクセスを行うことがある。特定の場合には、あるアプリケーションが、ある資源へのアクセスを、その資源に他のアプリケーションが同時にアクセスすることを許さずに行いたいことがある。たとえば、第１のアプリケーションが、データベース内のデータの更新を行いたい場合、その第１のアプリケーションは、そのデータベースにアクセスして更新することを、他のアプリケーションがそのデータベースの同じ部分の更新を潜在的に試みることのない状況で行いたいことがある。

資源への連続的なアクセスを保証するために、しばしばロックが使用される。アプリケーションは、資源へのロックを得ることによって、その資源へのアクセス権を得るのである。たとえば、第１のアプリケーションが、第１の資源に対するロックを得る場合、第２のアプリケーションは、第１の資源に対するアクセスを、第１の資源に対するロックを第１のアプリケーションが解放するまで、行うことができないはずである。

一部の場合では、クライアント・コンピュータにあるクライアント・アプリケーションからの要求を、サーバ・コンピュータにある第１のエージェントへと送ることができる。第１のエージェントは、その要求を第２のエージェントに渡すことができ、これが今度はその要求を第３のエージェントに渡すことができる。第１のエージェントは、第２のエージェントに対するクライアントとして働いており、第２のエージェントは、第３のエージェントに対するクライアントとして働いている。第３のエージェントは、その要求を処理し（たとえば、データを取り出す）、結果を第２のエージェントへと返すことができ、これがその結果を第１のエージェントへと返す。次いで、第１のエージェントは、その結果をクライアント・アプリケーションへと返す。この例では３つのエージェントを使用したが、ともに動作して要求を渡し結果を返す２つ以上のエージェントを、カスケーディング・エージェントと呼ぶことがある。

一部の場合では、そのカスケーディング・エージェントの組のエージェントそれぞれが、ある資源に対するロックを得る。しかし、あるエージェントがどのクライアント・アプリケーションのためにそのロックを得たのかを示すリンクはない。したがって、第１のエージェントが、あるクライアント・アプリケーションのための資源に対するロックを得ることは可能であるが、次いで第２のエージェントが第１のエージェントから要求を受け取り、その資源に対するロックを得ることを試みると、第２のエージェントはロックを拒否される。第１と第２のエージェントがどちらも、そのクライアント・アプリケーションのために同じ要求を処理しているのであるから、このどちらもがその資源をロックできるべきである。したがって、一部の従来型システムでは、カスケーディング・エージェントに対するロッキングをサポートしていない。

多重（multiple）ロックが、要求の処理のために必要となることがある。一部の従来型システムでは、クライアント・アプリケーションは、ある要求を処理するためにロックをすべて得る必要がある。たとえば、第１のアプリケーションに、第１および第２の資源へのアクセスが必要である場合、一部のシステムでは、第１のアプリケーションが、任意の処理の前に、どちらの資源に対するロックも必要とする。第１のアプリケーションが、第１の資源に対するロックを得ているが、第２のアプリケーションが第２の資源に対するロックを得ている場合、第１の資源は第２の資源に対するロックを待つ。

一部のシステムでは、クライアント・アプリケーションがロックを管理する必要がある。ロックのための規則は面倒であることがあり、これは、クライアント・アプリケーション内部の複雑さを増大させることになる。

さらに、一部のデータベース管理システムは、トランザクション・マネージャを含んでいる。こうしたトランザクション・マネージャでは、動作のログを取らずに、動作の結果のログを取っている。
"Specification for CIMOperations over HTTP," Version 1.1, May 2, 2002

当技術分野では、改良されたロッキングおよびトランザクション管理システムが必要となる。

ロックするための方法、システム、およびプログラムが提供される。第１の資源をロックするための第１の操作識別子をもつ要求の受け取りが行われる。前記第１の資源は前記第１の操作識別子によってロックされる。第２の資源を前記第１の操作識別子によってロックすべきであるか、または第２の操作識別子によってロックすべきであるかが、前記要求に対して実行すべき操作を前記要求が処理された後で完了できるかどうかに基づいて判定される。

追加の実施形態では、ロックするための方法、システム、およびプログラムが提供される。資源を第１の操作識別子によってロックするための要求の受け取りが行われる。前記資源が前記第１の操作識別子によってロックされているかどうかが判定される。前記資源が前記第１の操作識別子によってロックされていると判定された場合、前記要求は、前記資源が前記第１の操作識別子によってロックされているという標示をもつ応答を受け取る。前記資源が第２の操作識別子によってロックされていると判定された場合、前記ロック要求は拒否される。

さらなる実施形態では、デッドロック管理のための方法、システム、およびプログラムが提供される。第１の操作識別子による、第２の操作識別子によってロックされている資源に対するロック要求の拒否の標示の受け取りが行われる。前記ロック要求がロック・キュー・タイムアウト期間をもつキューに入れられる。前記ロック要求が前記ロック・キュー・タイムアウト期間内に、前記ロック要求をそこから処理できる前記キューの位置に達した場合、前記ロック要求が再発行される。

ここで説明する本発明の実施形態により、ロックおよびトランザクション管理システムのための方法、システム、およびプログラムが提供される。

したがって、本発明では、第１の態様において、ロックするための方法であって、第１の資源をロックするための第１の操作識別子をもつ要求を受け取るステップ、前記第１の資源を前記第１の操作識別子によってロックするステップ、および、第２の資源を前記第１の操作識別子によってロックすべきであるか、または第２の操作識別子によってロックすべきであるかを、前記要求に対して実行すべき操作を前記要求が処理された後で完了できるかどうかに基づいて判定するステップを含む方法が提供される。

好ましくは、第１の態様の方法は、前記第２の資源を前記第１の操作識別子によってロックすべきかどうかを判定するステップ、および、前記第２の資源を前記第１の操作識別子によってロックするステップをさらに含む。さらに、好ましくは、この方法は、前記第２の資源を第２の操作識別子によってロックすべきかどうかを判定するステップ、前記第２の操作識別子を得るステップ、および、前記第２の資源を前記第２の操作識別子によってロックするステップをさらに含む。

したがって、本発明では、第２の態様において、ロックするためのシステムであって、プロセッサと、前記プロセッサへアクセス可能なコンピュータ可読媒体と、（ｉ）第１の資源をロックするための第１の操作識別子をもつ要求を受け取るステップ、（ｉｉ）前記第１の資源を前記第１の操作識別子によってロックするステップ、および、（ｉｉｉ）第２の資源を前記第１の操作識別子によってロックすべきであるか、または第２の操作識別子によってロックすべきであるかを、前記要求に対して実行すべき操作を前記要求が処理された後で完了できるかどうかに基づいて判定するステップを、前記プロセッサに実行させる能力のあるコードを含むプログラム論理とを、含むシステムが提供される。

好ましくは、第２の態様のシステムでは、コードは、前記第２の資源を前記第１の操作識別子によってロックすべきかどうかを判定するステップ、および、前記第２の資源を前記第１の操作識別子によってロックするステップを、さらに前記プロセッサに実行させる能力をもつ。

さらに、好ましくは、コードは、前記第２の資源を第２の操作識別子によってロックすべきかどうかを判定するステップ、前記第２の操作識別子を得るステップ、および、前記第２の資源を前記第２の操作識別子によってロックするステップを、さらに前記プロセッサに実行させる能力をもつ。

したがって、本発明では、第３の態様において、コンピュータ可用媒体上に格納したコンピュータ・プログラム製品であって、第１の資源をロックするための第１の操作識別子をもつ要求を受け取るステップ、前記第１の資源を前記第１の操作識別子によってロックするステップ、および、第２の資源を前記第１の操作識別子によってロックすべきであるか、または第２の操作識別子によってロックすべきであるかを、前記要求に対して実行すべき操作を前記要求が処理された後で完了できるかどうかに基づいて判定するステップのための、コンピュータ可読プログラム手段を含む、コンピュータ・プログラム製品が提供される。

好ましくは、第３の態様のコンピュータ・プログラム製品は、前記第２の資源を前記第１の操作識別子によってロックすべきかどうかを判定するステップ、および、前記第２の資源を前記第１の操作識別子によってロックするステップのための、コンピュータ可読プログラム手段をさらに含む。さらに、好ましくは、第３の態様のコンピュータ・プログラム製品は、前記第２の資源を第２の操作識別子によってロックすべきかどうかを判定するステップ、前記第２の操作識別子を得るステップ、および、前記第２の資源を前記第２の操作識別子によってロックするステップのための、コンピュータ可読プログラム手段をさらに含む。

したがって、本発明では、第４の態様において、ロックするためのシステムであって、エージェントと、前記エージェントの制御する第１の資源と、前記エージェントの制御しない第２の資源と、前記第１の資源をロックするための第１の操作識別子をもつ要求を受け取る手段と、前記第１の資源を前記第１の操作識別子によってロックする手段と、前記第２の資源を前記第１の操作識別子によってロックすべきであるか、または第２の操作識別子によってロックすべきであるかを、前記要求に対して実行すべき操作を前記要求が処理された後で完了できるかどうかに基づいて判定する手段とを、含むシステムが提供される。

したがって、本発明では、第５の態様において、ロックするための方法であって、資源を第１の操作識別子によってロックするための要求を受け取るステップ、前記資源が前記第１の操作識別子によってロックされているかどうかを判定するステップ、前記資源が前記第１の操作識別子によってロックされていると判定された場合、前記要求に対して、前記資源は前記第１の操作識別子によってロックされているという標示で応答するステップ、および、前記資源が第２の操作識別子によってロックされていると判定された場合、前記ロック要求を拒否するステップを、含む方法が提供される。

好ましくは、第５の態様の方法において、前記資源が前記第１の操作識別子によってロックされているかどうかを判定するステップは、前記第１の識別子を、前記資源をロックするのに使用した操作識別子と突き合わせる（マッチングをとる）ステップをさらに含む。

したがって、本発明では、第６の態様において、ロックするためのシステムであって、プロセッサと、前記プロセッサへアクセス可能なコンピュータ可読媒体と、（ｉ）資源を第１の操作識別子によってロックするための要求を受け取るステップ、（ｉｉ）前記資源が前記第１の操作識別子によってロックされているかどうかを判定するステップ、（ｉｉｉ）前記資源が前記第１の操作識別子によってロックされていると判定された場合、前記要求に対して、前記資源は前記第１の操作識別子によってロックされているという標示で応答するステップ、および、（ｉｖ）前記資源が第２の操作識別子によってロックされていると判定された場合、前記ロック要求を拒否するステップを、前記プロセッサに実行させる能力のあるコードを含むプログラム論理とを、含むシステムが提供される。

好ましくは、第６の態様のシステムにおいて、前記資源が前記第１の操作識別子によってロックされているかどうかを判定する際、コードは、前記第１の識別子を、前記資源をロックするのに使用した操作識別子と突き合わせるステップを、前記プロセッサにさらに実行させる能力をもつ。

したがって、本発明では、第７の態様において、コンピュータ可用媒体上に格納したコンピュータ・プログラム製品であって、資源を第１の操作識別子によってロックするための要求を受け取るステップ、前記資源が前記第１の操作識別子によってロックされているかどうかを判定するステップ、前記資源が前記第１の操作識別子によってロックされていると判定された場合、前記要求に対して、前記資源は前記第１の操作識別子によってロックされているという標示で応答するステップ、および、前記資源が第２の操作識別子によってロックされていると判定された場合、前記ロック要求を拒否するステップのための、コンピュータ可読プログラム手段を含む、コンピュータ・プログラム製品が提供される。

好ましくは、第７の態様のコンピュータ・プログラム製品は、前記第１の識別子を前記資源をロックするのに使用した操作識別子と突き合わせるためのコンピュータ可読プログラム手段をさらに含む。

したがって、本発明では、第８の態様において、ロックするためのシステムであって、資源を第１の操作識別子によってロックするための要求を受け取る手段と、前記第１の識別子を前記資源をロックするのに使用した操作識別子と突き合わせることによって、前記資源が前記第１の操作識別子によってロックされているかどうかを判定する手段と、前記資源が前記第１の操作識別子によってロックされていると判定された場合、前記要求に対して、前記資源は前記第１の操作識別子によってロックされているという標示で応答する手段と、前記資源が第２の操作識別子によってロックされていると判定された場合、前記ロック要求を拒否する手段とを、含むシステムが提供される。

したがって、本発明では、第９の態様において、デッドロック管理のための方法であって、第１の操作識別子による、第２の操作識別子によってロックされている資源に対するロック要求の拒否の標示を受け取るステップ、前記ロック要求をロック・キュー・タイムアウト期間をもつキューに入れるステップ、および、前記ロック要求が前記ロック・キュー・タイムアウト期間内に前記ロック要求をそこから処理できる前記キューの位置に達した場合、前記ロック要求を再発行するステップを、含む方法が提供される。

好ましくは、第９の態様の方法は、前記ロック要求が前記ロック・キュー・タイムアウト期間内に許可されなかった場合、前記ロック要求を拒否するステップをさらに含む。

したがって、本発明では、第１０の態様において、デッドロック管理のためのシステムであって、プロセッサと、前記プロセッサへアクセス可能なコンピュータ可読媒体と、（ｉ）第１の操作識別子による、第２の操作識別子によってロックされている資源に対するロック要求の拒否の標示を受け取るステップ、（ｉｉ）前記ロック要求をロック・キュー・タイムアウト期間をもつキューに入れるステップ、および、（ｉｉｉ）前記ロック要求が前記ロック・キュー・タイムアウト期間内に前記ロック要求をそこから処理できる前記キューの位置に達した場合、前記ロック要求を再発行するステップを、前記プロセッサに実行させる能力のあるコードを含むプログラム論理とを、含むシステムが提供される。

好ましくは、第１０の態様のシステムにおいて、コードは、前記ロック要求が前記ロック・キュー・タイムアウト期間内に許可されなかった場合、前記ロック要求を拒否するステップを前記プロセッサにさらに実行させる能力をもつ。

したがって、本発明では、第１１の態様において、コンピュータ可用媒体上に格納したコンピュータ・プログラム製品であって、第１の操作識別子による、第２の操作識別子によってロックされている資源に対するロック要求の拒否の標示を受け取るステップ、前記ロック要求をロック・キュー・タイムアウト期間をもつキューに入れるステップ、および、前記ロック要求が前記ロック・キュー・タイムアウト期間内に前記ロック要求をそこから処理できる前記キューの位置に達した場合、前記ロック要求を再発行するステップのための、コンピュータ可読プログラム手段を含む、コンピュータ・プログラム製品が提供される。

好ましくは、第１１の態様のコンピュータ・プログラム製品は、前記ロック要求が前記ロック・キュー・タイムアウト期間内に許可されなかった場合、前記ロック要求を拒否するステップのための、コンピュータ可読プログラム手段をさらに含む。

したがって、本発明では、第１２の態様において、デッドロック管理のためのシステムであって、第１の操作識別子による、第２の操作識別子によってロックされている資源に対するロック要求の拒否の標示を受け取る手段と、前記ロック要求をロック・キュー・タイムアウト期間をもつキューに入れる手段と、前記ロック要求が前記ロック・キュー・タイムアウト期間内に前記ロック要求をそこから処理できる前記キューの位置に達した場合、前記ロック要求を再発行する手段とを、含むシステムが提供される。

次に、本発明の好ましい一実施形態の説明を、単なる例として、添付の図面を参照して行う。

ロックおよびトランザクション管理（ＬＴＭ、lock and transactionmanagement）システムが提供される。ＬＴＭシステムにより、「仮想化」および「仮想ストレージ装置」をサポートするためのロッキングの考慮すべき条件および要求が識別される。「仮想化」（virtualization）という用語は、物理ストレージ装置を、複数のネットワーク・ストレージ装置から、たとえば、単一のサーバ・コンピュータから集中的に管理される単一のストレージ装置と見えるものへとプーリングすることを指す。本発明の好ましい実施形態では、仮想化を、ＳＡＮ（storagearea network、ストレージ・エリア・ネットワーク）の一部として使用する。ＳＡＮ（storage area network）は、共用データ・ストレージ装置を、クライアント・コンピュータからアクセスされる、関連づけられているサーバ・コンピュータと相互接続する高速のネットワークまたはサブネットワークである。「仮想ストレージ装置」（virtualstorage device）という用語は、プールされているストレージ装置を指す。「仮想ストレージ・サービス」という用語は、プールされているストレージ装置の提供するサービス（たとえば、ロッキング）を指す。ＬＴＭシステムでは、ロック管理プロトコルを指定するほか、ロック・マネージャをサポートしている。

さらに、ＬＴＭシステムでは、トランザクション・マネージャをサポートしており、トランザクション管理のサポートに必要なロッキングを定義している。本発明の好ましい一実施形態では、ロック・マネージャは、ロッキング対応クライアントおよびロッキング対応エージェントのためのロッキング機能を提供し、ロック・マネージャ用の規則に従う「ロック管理サーバ」（lock management server）である。

本発明の好ましい一実施形態では、トランザクション・マネージャは、コミットまたはロールバックの処理のトランザクションおよび開始の実行を管理および制御する「トランザクション管理サーバ」（transaction management server）である。１つのトランザクションは、「ＡＣＩＤ」特性をもつ１件の操作である。すなわち、１つのトランザクションは、原子性をもち（Atomic）、一貫性（Consistent）のある結果を生み出し、隔離性をもち（Isolated）、耐久性をもつ（Durable）。手短に言えば、トランザクションとは、「まったく完了する」（allcompletes）か「まったく失敗する」（all fails）１件の操作であり、これは、システムまたはコンポーネントの障害にわたって保証される。１件の操作は、単一のクライアントからの一連のエージェント要求（または「動作」（actions））である。これは、「クライアント操作」（clientoperation）とも呼ぶことができる。トランザクション・マネージャの存在下では、操作はトランザクションになる。コミットとは、あるトランザクションの動作がすべて実行されることを保証するためのトランザクション機能である。ロールバックとは、トランザクションの諸動作を「アンドゥ」（undoing）するものであるトランザクション機能である。トランザクション・マネージャは、トランザクション・ログを管理し、これは、トランザクション情報の不揮発性レコードである。

ＬＴＭシステムのロッキングの背後にある哲学は、トランザクション関連のロッキングを定義し、その後でトランザクション・サポートのないロッキングを定義する、ということである。このトランザクション設計に基づいて、期待されることは、トランザクション・サポートのないロッキングにより、設計が厳格性のより低い設計に適合するように縮小されるということである。その意図は、トランザクション・サポートのないロッキングの縮小された実装が、トランザクション関連のロッキングの設計のサブセットであること、および、トランザクション・サポートのないロッキングの縮小された実装は、実際、トランザクション処理に拡張できる、ということである。

ＬＴＭシステムのロッキングでは、インテリジェンスをクライアントまたはエージェントの中にではなく、ロック管理サーバの中に置こうと試みる。このことの理由付けは、インテリジェンスが、複数ベンダのクライアントおよびエージェントにわたって分散しているよりも、局所化されている場合、機能を正しく（または少なくとも一貫性をもって）理解することがより容易になるという仮定に基づいている。

導入
ロック管理プロトコルの目的は、エージェントの分散ネットワークに対して動作する複数の、非協働的クライアントをサポートすることである。非協働的クライアント（noncooperating client）とは、互いに独立であり、資源に対して競合し、互いに独立に実行される複数のクライアントである。ロッキングを使用して、異種のＳＡＮ（storagearea network）内の複数のベンダからのクライアントからの潜在的に衝突する操作の管理が行われる。ロッキング機構に参加するクライアントは、その操作が、ＳＡＮ内で進行中である可能性のある他の操作と衝突しないことが保証されることになる。

ＬＴＭシステム内のロック管理は、複数の「サポートのレベル」をサポートするように設計されている。最も頑健なレベルが、「トランザクション」レベルのロッキングである。トランザクション・レベルのロッキングに対するサポートでは、「トランザクション・マネージャ」が存在することが要求される。次のレベルのサポートは、「隔離性」レベルのロッキングと呼ばれ、トランザクション・マネージャの存在は必要とされない。最後のレベルのサポートは、「クライアント制御」（client controlled）レベルのロッキングと呼ばれる。これらレベルのそれぞれは、その保証するＡＣＩＤ（原子性（Atomicity）、一貫性（Consistency）、隔離性（Isolation）、および耐久性（Durability））サポートによって特徴付けることができる。提供されているサポートを、次の表１に要約している。

原子性（Atomicity）
原子性とは、「操作」（operation）を完全に行うか、まったく行わないかを（ある操作が１つまたは複数のエージェントに対する複数の要求として定義されている場合に）指す。原子性に対するサポートには、操作が失敗するときに「操作」要求をアンドゥするための「ロールバック」能力が必要である。この理由で、原子性は「トランザクション」レベルのロッキングでサポートされており、トランザクション・マネージャによってロールバック・プロセスがサポート／駆動される。

「隔離性」および「クライアント制御」レベルのロッキングでは、原子性のサポートはサポートされずまたは必要ではない。その結果、これらのレベルは、トランザクション・マネージャがないところで動作することができる。

一貫性（Consistency）
一貫性は、「モデル」データを一貫した状態にしておくことを指す。一貫性は、トランザクション・レベルのロッキングでサポートされる。一貫性は、隔離性またはクライアント制御のレベルでは必ずしもサポートされない。本発明の好ましい一実施形態では、エージェントは、そのモデルに自己一貫性を確実にもたせることが期待される。しかし、あるエージェントのモデルが他のエージェントのそれと一貫性をもつことを保証するやり方はない。

ロールバックは、隔離性およびクライアント制御のレベルではサポートされていないため、「クロス・エージェント」モデルは、必ずしも一貫性をもつ状態にはおかれるわけではない。たとえば、クライアントがゾーンを変更し（たとえば、ファブリック要求）、ボリュームを新しいゾーンに再割り当て（たとえば、アレイ要求）する場合、これを、障害の場合には、「やりかけ」（half done）にしておくことができる。隔離性およびクライアント制御のレベルのロッキングでは、ＳＡＮモデルのレベルでの一貫性は、クライアントの責任に委ねられる。

隔離性（Isolation）
ロック管理のコンテキストにおいて、ＬＴＭシステムでは、操作は、単一のクライアントの代わりに開始する一連の関連するエージェント動作（または要求）と定義される。１つの動作は、あるエージェントに対する単一のクライアントからの単一の要求である。クライアント操作は、通常、様々なエージェント上の複数の動作（または要求）からなる。隔離性により、「操作」は、他の操作とシリアルに実行されているのと同様に見える。ＬＴＭシステム操作がコンカレントに実行される場合でさえ、「Ｏ」という各操作にとっては、他の操作は、操作「Ｏ」の前か操作「Ｏ」の後に、両方ではないが、実行されたように見える。これは、単に、他のＬＴＭシステム操作とコンカレントに実行されているＬＴＭシステム操作、またはＬＴＭシステムのロック管理の下にあるＣＩＭ（Common Information Model、共通情報モデル）操作が、それが実行中の唯一の操作であるのと同様に振る舞うことを意味する。ＣＩＭは、情報を管理するためのオブジェクト・モデルを作成するための標準である。オブジェクト・モデルは、ＳＡＮ（storagearea network）などのネットワーク資源のオブジェクト指向の表現である。ＣＩＭ標準は、ＤＭＴＦ（Distributed ManagementTaskForce），Ｉｎｃ．が提供している。ＣＩＭ標準についてのさらなる情報に関しては、"Specification for CIMOperations over HTTP," Version 1.1, May 2, 2002を参照されたい。以下ではこれをCIMspecificationと呼び、この文言によりその全体を参照により本明細書に組み込む。

隔離性では、ロックにより、動作がその操作の使用する情報を変更することを妨げることが要求される。隔離性は、トランザクションと隔離性のどちらのレベルのロッキングでもサポートされる。隔離性は、「クライアント制御」レベルのロッキングを使用しているときにはクライアント論理によって達成されるが、ロッキング機構自体は隔離性を保証するものではない。

隔離性のサポートでは、ロッキングの設計で、「読み取り」（Read）ロックの概念を、変更（Change）ロックとは別個のものとしてサポートしている。読み取りロックにより、クライアントは、変更するという明確な意図はないが、その値がそのクライアントの操作の進行する間は変わってほしくない資源を取っておくことができるようになる。たとえば、あるクライアントが、複数のストレージ・プールをスキャンしてボリュームを作成するための利用可能なスペースを探しており、このクライアントはそのボリュームをストレージ・プールのうちの１つから作成することになるとしよう。このクライアントは、ストレージ・プールのすべてに対する変更ロックを得るのではなく、このストレージ・プールのすべてに対する読み取りロックを得て、このクライアントの選択するストレージ・プール１個に対する変更ロックを発行することができる。

ロッキングでは、隔離性をサポートするために「読み取り」ロックをサポートしているが、ロッキングの設計では、あるクライアントがその情報の再読み込みまたは利用を行わないような場合のための「ダーティ・リード」（dirty reads）もサポートしている（読み取りが、読み取りロックが得られていない場合でも許される）。ダーティ・リードとは、ロック（すなわち、読み取りまたは変更）を獲得せずに情報をエージェントから取り出す任意のクライアント要求である。これは、読み取りが保護されていないため、ダーティ・リードと呼ばれる。同じ情報をその次に読み込んだ場合には、異なる結果がもたらされる可能性もある。

耐久性（Durability）
耐久性がある場合には、結果が実際に発生するのは、成功が返されたときである。「耐久性」の意義は、使用しているロッキングのレベルに応じて変わる。トランザクション・レベルのロッキングのコンテキストでは、耐久性は、クライアント操作が（成功にせよそうでないにせよ）完了したときに、結果が障害の前後で保証されることを意味する。これは、ロギングおよび２フェーズ・コミット・プロセスにより、エージェントすべてがコミット（またはロールバック）を確実に済ませるようにすることを意味する。２フェーズ・コミット・プロセスでは、第１のプロセスが他のプロセスに、そのプロセスがコミットの準備中であることを示す。他のプロセスのそれぞれは、コミットの準備を行う。次いで、第１のプロセスがコミットし、他のプロセスのコミットが行われる。ロギングでは、再起動時に、トランザクション・マネージャが、何が行われることになっていたかを決定し、それが実際に起きることを確認することができる。

耐久性は、「隔離性」または「クライアント制御」のレベルのロッキングのコンテキストでは、要求が満たされるのは、クライアントが成功の返り値を得るときであることを保証する。これは、ロック要求、ならびに、エージェント・モデル上の動作を含む。応答が得られていない要求は、行われていると仮定することができない（ただし完了していた可能性もある）。本質的に、クライアント・アプリケーションが仮定することができるのは、その操作が、最後の肯定応答の時点までは完了していた、ということである。

ロック／トランザクション管理の構成要素
ロック管理およびトランザクション管理の議論では、プロセスに参加するいくつもの構成要素がある。その構成要素を参照の便宜のためにここで要約する。

要素マネージャ（element manager）は、ＳＡＮ環境内の特定の装置を管理するための管理ツールである。ロッキングの設計のコンテキストでは、要素マネージャは、ロッキング非対応でありＣＩＭクライアントではないと仮定されている。要素マネージャは、ＣＩＭクライアントとしてコードされている場合には、ロッキング対応クライアントを規定する規則の下で取り扱われる。

ロック・マネージャ（lock manager）は、「ロック管理サーバ」とも呼ばれ、ロッキング対応クライアントおよびロッキング対応エージェントに対するロッキング関数を提供し、ロック・マネージャに関する規則に従う。

ロッキング対応エージェント（locking aware agent）は、エージェントに対するロッキング要求をサポートし、エージェントに対するロッキング規則をサポートするエージェントまたはオブジェクト・マネージャである。

ロッキング対応クライアント（locking aware client）は、資源のロッキングを行い、ロッキングに関するクライアント規則に従うクライアントである。

ロッキング非対応エージェント（locking unaware agent）は、ロッキング要求をサポートしないエージェントまたはＣＩＭオブジェクト・マネージャである。

ロッキング非対応クライアント（locking unaware client）は、ロッキングをまったく行わないクライアントである。

トランザクション・マネージャ（transaction manager）は、トランザクションの実行（および、コミットまたはロールバックの処理の開始）を管理および制御するサーバである。

スケーラビリティ上の理由から、ロック・マネージャおよびトランザクション・マネージャの設計は、こうした構成要素のそれぞれの複数のインスタンスに（複数のロック・マネージャおよび複数のトランザクション・マネージャを含めて）適応する。

設計原理
ロッキングがサポートするように設計される１組の設計原理がある。この設計原理のすべてが全レベルに適用されるわけではない。設計原理およびそれが適用されるロッキング・レベルを、次の表２に要約している。

複数の同時非協働的クライアントからの複数エージェントにまたがる操作の保護に関しては、ロッキング機構すべてで、非協働的クライアントにまたがってＳＡＮ内の管理情報へのアクセスを協調させることがサポートされる。必要となるロッキングのレベルは、クライアントで所望の機能に応じて変わり得るが、すべてのレベルのロッキングにより、クライアントは、クライアント操作の保護をロッキングによって行うことができるようになる。

ロッキング機構がロッキングを行わないクライアントまたは他の管理ツールに対処する能力は、現在ロッキングを行わない既存の管理ツールに対する譲歩である。このロッキング機構は、既存の管理ツールの取り扱いを、ロッキングを行うクライアントを保護する形で行うことができる。

エージェント全体よりも粒度の細かいロッキングを提供することにより、クライアントがエージェント全体よりも小さい粒度でロックできるようにすることによって、クライアントは、より高いコンカレンシを得られるようになる。

拡張可能なロッキング・アーキテクチャを定義することでは、拡張がＳＡＮ管理の進化する必要性を満たすことができるようなアーキテクチャが定義される。

ＳＮＩＡ（Storage Networking IndustryAssociation）およびＤＭＴＦ（Distributed Management TaskForce）を通して標準化可能なロッキング・アーキテクチャを定義することにより、このロッキング・アーキテクチャは、これをＣＩＭに関する標準への潜在的な拡張として使用可能にするという特別な（express）目的で、ＣＩＭの管理する環境というコンテキストで使用できるようになる。

カスケーディング・エージェントに対するサポートを提供することは、別の設計原理である。カスケーディング・エージェントサポートの視点からは、仮想化は、ＳＡＮ（storage area network）内の要素（たとえば、ストレージ装置）のカスケーディングを行うことを含む。カスケーディング・エージェントは、「より低レベル」のエージェントに対してはロック管理クライアントとしても働くロック管理エージェントである。ＬＴＭシステムにより、仮想化システムは、より低レベルのエージェントに対する動作を、クライアント操作の結果として行うことができるようになる。１つの動作は、あるエージェントに対する単一のクライアントからの単一の要求である。クライアント操作は、通常、様々なエージェント上の複数の「動作」からなる。特に、ＬＴＭシステムでは、カスケーディング・エージェントで、より低レベルのエージェント上の動作が、要求元（originating）クライアントと衝突しているかいないかが決定される。本発明の好ましい一実施形態では、カスケーディング・エージェントは、ロックの獲得をクライアントの代わりに、そのロックがクライアント要求を完了するのに必要である場合に行う。動作が、クライアント要求によってトリガされるが、クライアント要求を完了するのに必要ではない場合、カスケーディング・エージェントは、その動作をそれ自体のために実行してもよい。

「lock as you go」サポートにより、クライアントは、「lock asyou go」（その都度ロック）を行えるようになり、これは、クライアントが、ロックの獲得を、動作を実行すると決定するまで行う必要がないことを意味する。これにより、仮想システムは、より低レベルのエージェント上の機能を呼び出せることになる。また、「lockas you go」サポートにより、クライアントは、論理をコードするのにより大きな自由度が与えられる（たとえば、ストレージを検索し、見つかったときに、ロックを行い、次のステップに移る）。

スケーラブルな設計とは、すべてのレベルに関してロッキングをエンタープライズＳＡＮ構成の規模で設計するという設計原理を指す。これは、ロッキングの設計では、アーキテクチャ内の「ボトルネック」が回避され、このロッキングの設計をサポートするのに必要な通信が、ネットワークを圧倒してしまわないことを意味する。

クライアントの選ぶレベルのロッキングのサポートにより、クライアントでは、クライアント操作の性質、およびそれが何を達成しようとしているかを理解する。このロッキングの設計では、クライアントの選ぶロッキング・レベルがサポートされる。

クライアントの「インテリジェンス」の利用を抑え、インテリジェンスのロック・マネージャまたはエージェントへの配置を有利にすることにより、有用な作業を抑制しないようなクライアント向け規則がサポートされる。クライアント向け規則はあまりに複雑なものではない。隔離性およびトランザクションのレベルのロッキングでは、well-behavedな（開発の作法を守った）クライアントの激しい利用が回避される。クライアントには、従う必要のある規則は少ししかなく、クライアントの取る、正しい振る舞いに違反する動作は、実施される。「隔離性」および「トランザクション」のレベルのロッキングを使用中のロッキング対応クライアントでは、ロッキングを正しく行っているかどうかについて悩む必要がない。ロッキングが動作するか、または、ロッキング・システムが、そのクライアントがロッキング・プロトコルに違反しているときに通知することになるかである。

このクライアントの「インテリジェンス」の利用を抑えるというロッキングの特徴は、ロック・マネージャおよびロック管理エージェントに対して影響を及ぼす。ロック・マネージャは規則および規則の実施のほとんどを取り扱う。しかし、この設計原理は、クライアント制御レベルのロッキングには適用されない。

トランザクション管理への拡張のための設計により、隔離性レベル（およびある程度まで、クライアント制御レベル）のロッキングは、クライアントの再設計を行わずに、トランザクション・レベルのロッキングへと拡張可能である。すなわち、隔離性レベルのロッキングは、万一、トランザクション・マネージャがクライアントの後退（receding）が最小限であるロッキング環境内にある場合、トランザクション機能を手に入れることができる。本発明の好ましい一実施形態では、この設計原理はトランザクション・レベルのロッキングには適用されない。

デッドロック・ハンドリングおよびエラー状況からの回復を伴う簡単なロッキング機構を提供することも、１つの設計原理である。デッドロックが起きるは、２つ以上のクライアントが、２つ以上の資源（たとえばオブジェクト）のロックをある順序で試みたことから、どちらのクライアントも、どちらもが互いを待っているためにその操作を完了できなくなるときである。「クライアント制御」レベルのロッキングの目的は、ロッキングの比較的単純な展開に適応することである。これは、デッドロック・ハンドリング、および、エラー状況における定義済みの回復状態をサポートする機構を含む。本発明の好ましい一実施形態では、この設計原理は、クライアント制御レベルのロッキングに適用される。

「Unlock as you go」サポートは、最小限のロッキング環境のサポートを意図するロッキング・プロトコルである。すなわち、保持されるロックおよびロックの保持されている持続時間を最小化するロッキングである。「Unlockas you go」とは、クライアントがシステムに対して、クライアントの獲得している資源を解放する準備ができたときに通知できるという意味である。本発明の好ましい一実施形態では、これは、隔離性の特性およびトランザクション処理を犠牲にするが、クライアント論理に基づく穏当な動作である。したがって、この設計により、非トランザクション・アプリケーションが「Unlockas you go」を行えるようになる。本発明の好ましい一実施形態では、この設計原理は、クライアント制御レベルのロッキングに適用される。

ＡＣＩＤ特性すべてをサポートできるロッキング機構を提供することとは、そのロッキング機構により、トランザクション・マネージャに伴うロッキング要件をサポートしていることを意味する。本発明の好ましい一実施形態では、ＡＣＩＤ特性すべてをサポートできるロッキング機構を提供することは、ロック・マネージャがトランザクション・マネージャの役割を代行しなければならないこと、またはロック・マネージャがすべての場合に（単にトランザクション環境で）トランザクション・ロッキングをサポートする必要があることを意味するものではない。本発明の好ましい一実施形態では、この設計原理は、トランザクション・レベルのロッキングに適用される。

障害にまたがるレジリアントなロッキング機構を提供することは、別の設計原理である。トランザクション処理をサポートするために、ロッキング機構は、障害の場合には回復することができる。これは、トランザクション・マネージャとの組み合わせで行うことができる。障害がクライアント操作の途中で起きた場合は、ロックされている資源へのアクセスは、適当な回復プロセスが適用できるまで妨げられる。

回復の確認が済むと、ロックはすべて、そのクライアントが保持するどのロックかが失われた場合に備えて、解放される。いくつかの障害条件が設計では考慮されるが、これは、ロック管理サーバ、ロック・エージェント、ロック・クライアント、およびそれらの間の通信の障害を含む。本発明の好ましい一実施形態では、この設計原理は、トランザクション・レベルのロッキングに適用される。

エージェントの仮定
このロッキングの設計が、管理要求に対する装置サポートに関して行ういくつかの仮定がある。こうした仮定は、装置の設計およびエージェント提供者とそのサポートする装置の間の関係に固有のものである。こうした仮定は、エージェント動作の振る舞いを理解するのに有用であり、ロッキング機構が効果を有するのに必要である。

本発明の好ましい一実施形態では、装置は、そのメタデータを一貫性のある状態にしておくように設計される。本発明の好ましい一実施形態では、ストレージ装置は、メタデータを一貫性のない状態にしておくような動作を許していない。たとえば、ディスク・アレイでは、その状態が、ストレージが失われるようなものにしておかれる（たとえば、使用済みとマークするがどのボリュームにも割り当てない）ことはない。同様に、ディスク・アレイでは、その状態が、ストレージが不用意に２つの異なるボリュームへとマッピングされるようなものにしておかれることはない。また、この仮定は、その装置用のＣＩＭエージェントがそのデータに一貫性をもたせることを、そのモデルを装置内のメタデータと同期させ続けることによって行うことを意味する。

本発明の好ましい一実施形態では、ロッキング対応エージェントおよび装置には、ロッキング非対応クライアントを扱うときに、要求１つずつのロックが伴う。ロッキング非対応クライアントは、ロッキングをまったく行わないクライアントである。このことは、装置内ではロッキング対応になっていることを意味する。すなわち、ロッキング対応エージェントは、ロックが得られていない場合には、クライアント要求を実行するために必要なロック（または均等物（equivalent）、たとえば、ラッチ）を得る。しかし、そのロックは、クライアント要求が実行されると、すぐに解放される。このことは、その装置が、ロッキングを行うクライアントと衝突する「要素マネージャ」アクションを妨げるために（単なるエージェントではなく）ロッキング対応になっていることを意味する。

参照モデル
図１に、構成図の形で、本発明の好ましい実施形態による、４つの異なる役割を含むロッキングおよびトランザクション管理のための参照モデルを示している。

参照モデルは、ロッキング対応クライアント１１０を含む。ロッキング非対応クライアントについては、下で詳細に論じる。ロッキング対応クライアント１１０は、所望するロッキングのレベルの選択を行う。ロッキング対応クライアント１１０は、これを行うために、たとえば、BeginTransaction要求（これは下でさらに詳細に説明する）のトランザクション・マネージャへの発行を、ロッキング対応クライアント１１０がトランザクション・レベルのロッキングを望んでいる場合に行う。トランザクション・マネージャでは、トランザクション（すなわち、トランザクション管理の制御下で実行中のクライアント操作）のコミットまたはロールバックの協調を管理する。本発明の好ましい一実施形態では、このトランザクション・マネージャを、独立のトランザクション管理サーバ１２０として説明する。本発明の好ましい一実施形態では、トランザクション・マネージャは、クライアント・アプリケーションと同じシステム上にともに常駐していていてもよい。通常、システムごとに、ロッキング対応クライアントを動作させる１つのトランザクション・マネージャがある。トランザクション・マネージャでは、クライアント・アプリケーションの取る動作（たとえば、クライアント要求）およびそのトランザクションのロールバックを行うのに必要な「逆」（reverse）の動作のログを維持している。

ロッキング対応クライアント１１０は、隔離性またはクライアント制御のレベルのロッキングを望む場合には、トランザクション管理サーバ１２０への要求を省略し、たとえば、下でさらに詳細に説明するGetOperationId要求で直接ロック・マネージャへと向かって、その操作のための操作識別子（「操作ＩＤ」（operation id）または「OperationId」）を得る。本発明の好ましい一実施形態では、このロック・マネージャは、ロック管理サーバ１３０であり、ロック管理サーバ１３０と同じロック管理グループ内の１組のロック管理エージェント１４０Ａ．．．Ｎからのロックの獲得の協調を行う。図面では、参照を簡単にするため、図中の要素の複数の複製（copies）を、同じ符号（referencenumber）と１個の記号で参照することがある（たとえば、１１０Ａから１１０Ｎ、ここではＮは要素のＮ番目の複製を表す）。たとえば、ロック管理エージェント１４０Ａ、１４０Ｂ、および１４０Ｎは、ロック管理エージェント１４０Ａ．．．Ｎとして参照されることになる。

ロック管理グループは、ロック管理サーバおよび１つまたは複数のエージェントを含む。１つまたは複数のロック管理サーバ１２０が、したがって、１つまたは複数のロック管理部ループが、その環境内にあってもよい。ロック管理サーバ１３０は、それぞれ、１組のロック管理エージェント１４０Ａ．．．Ｎに関するロッキングの管理を、そのロック管理グループ内で行う。管理者は、ロック管理サーバ１３０およびロック管理グループを必要なだけセットアップして、スケーラビリティ要件をサポートすることができる。ロック管理サーバ１３０は、キューイングがサポートされている場合には、ロック・キューイングを行うことができる。

ロック管理エージェント１４０Ａ．．．Ｎは、ロック管理エージェント１４０Ａ．．．Ｎの管理する装置または複数の装置に関するロッキングを行う。すなわち、資源に対する実際のロックの獲得と保持は、エージェントのレベルで行われる。特定の実施形態では、ロック管理エージェント１４０Ａ．．．１４０Ｎでは、キューイングを行わない。その代わりに、ロック管理エージェント１４０Ａ．．．１４０Ｎは、ロックの許可および拒否を行い、ロック管理サーバ１３０がロック要求のキューイングを管理する。ロック管理エージェント１４０Ａ．．．１４０Ｎは、ロック管理サーバ１３０から解放を命じられるまでロックの保持を行う。

こうした役割のそれぞれ（ロッキング対応クライアント１１０、トランザクション管理サーバ１２０、ロック管理サーバ１３０、およびロック管理エージェント１４０Ａ．．．Ｎ）では、クライアントの要求するロッキングのレベル（すなわち、トランザクション、隔離性、またはクライアント制御）に基づいて諸機能を実行する。

ロッキングに関する参照モデルは、次のものを含むいくつかのロッキング環境を考慮に入れている。すなわち、トランザクション・レベルのロッキングをサポートする、トランザクション・マネージャのあるロッキング環境、隔離性とクライアント制御のどちらのレベルのロッキングも含む、トランザクション・マネージャのないロッキング環境、および、ロッキングのレベルのうちの所与のどれかのサポートも含む、ロッキング非対応クライアントに対するサポートである。

トランザクション・マネージャのあるロッキングの参照モデル
図２に、本発明の好ましい実施形態による、トランザクション・マネージャ２２０のあるロッキング環境を示している。トランザクション・ロッキングに関する参照モデルは、環境内の１つまたは複数のトランザクション・マネージャ、ならびに、ロック管理サーバを含む。

ロッキング対応クライアント−１ ２１０は、トランザクション・マネージャ２２０、ロック管理サーバＡ２４０、およびロック管理サーバＢ２６０に接続されている。ロック管理グループＡ２３０は、ロック管理サーバＡ２４０、ロッキング・エージェントＷ２４２、およびロッキング・エージェントＸ２４４を含む。ロック管理グループＢ２５０は、ロック管理サーバＢ２６０、ロッキング・エージェントＹ２６２、およびロッキング・エージェントＺ２６４を含む。ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４は、ロッキング対応エージェントである。本発明の好ましい一実施形態では、ＣＩＭエージェントによって、ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４が実装されている。

トランザクションの開始および終了は、クライアントにあるクライアント・アプリケーションの定義するように行われる。言及を簡単にするために、クライアント・アプリケーションの行う動作は、クライアントの行う、と言うことにする。図２では、トランザクションが開始されるのは、ロッキング対応クライアント−１ ２１０にあるクライアント・アプリケーションが、たとえば、BeginTransaction要求をトランザクション・マネージャ２２０に送るときである。トランザクション・マネージャ２２０は、トランザクションを「作成」（creates）し、そのトランザクションの識別のための操作ＩＤを返す。

本発明の好ましい一実施形態では、操作ＩＤは、ロック管理グループおよびトランザクション・マネージャ全体にわたって一意である。したがって、操作ＩＤは、第１の部分がその操作ＩＤをトランザクション・マネージャが生成したかどうかの標示、第２の部分がロック管理グループ名またはトランザクション・マネージャ名、最後の部分がロック管理グループまたはトランザクション・マネージャのコンテキスト内での一意な番号であるような複合した鍵とすることができる。すなわち、操作ＩＤは、Ｔ：Ａ：番号という形をとる（ここでＴはブール値、Ａはロック管理グループまたはトランザクション・マネージャの名前、「番号」は一意な整数である）。

トランザクション・マネージャ２２０の行うロギングおよび保持されるロックは、操作ＩＤのコンテキスト内にあることになる。あるトランザクションの最初のログ・エントリは、そのトランザクションの出現（existence）である（たとえば、開始（begin）トランザクション）。

ロッキング対応クライアント−１ ２１０がトランザクション操作ＩＤを得た後、ロッキング対応クライアント−１ ２１０により、ロッキング対応クライアント−１ ２１０が変更を意図している資源のロックが行われる。また、ロッキング対応クライアント−１ ２１０により、ロッキング対応クライアント−１ ２１０が読み込み、またロッキング対応クライアント−１ ２１０がその操作中に不変のままであることを望む資源のロックが行われる。ロッキング対応クライアント−１ ２１０が発行を意図する変更操作（すなわち、データを変更する操作）では、ロッキング対応クライアント−１ ２１０から、この変更を実行するコマンドが、トランザクション・マネージャ２２０へとロギングのために送られ、ロック要求の発行が、ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４へとロック管理サーバＡ２４０、Ｂ２６０を介して行われる。ロッキング対応クライアント−１ ２１０では、この変更要求のほかに、「逆」の動作が、トランザクション・マネージャ２２０がこの操作のロールバックを行う必要のある場合に備えて、トランザクション・マネージャ２２０へと提供される。

トランザクション・マネージャ２２０では、変更要求と、動作が元に戻せる（reversible）変更要求に対する「逆」の動作のログを記録する。変更要求の動作が元に戻せない場合は、その動作はこのトランザクションの範囲外にあると見なされる。

トランザクションの終了は、３つのイベントのうちの１つによって決定される。すなわち、ロッキング対応クライアント−１ ２１０がトランザクション・マネージャ２２０へと発行するコミット、ロッキング対応クライアント−１ ２１０がトランザクション・マネージャ２２０へと発行するロールバック、または、そのトランザクション中の構成要素（たとえば、ロッキング対応クライアント−１ ２１０またはトランザクション・マネージャ２２０）のどれかの障害条件である。

トランザクションの完了が成功する前に、トランザクション中の構成要素のどれかの障害が起きると、ロールバックが起きる。本発明の好ましい一実施形態では、ある構成要素が障害を起こしているかどうかを決定するために、ハートビート関数を使用する。

本発明の好ましい一実施形態では、トランザクション・マネージャ２２０は、クライアント・システム上に常駐する機能とすることもでき、またはトランザクション・マネージャ２２０は、ロック管理サーバＡ２４０またはＢ２６０と組み合わせることもできる。

このロッキングの設計は、サーバがそのロック管理グループ２３０、２５０の範囲内でロックを行う場合でも、ロックの協調のための「サーバ間」（server to server）通信をサポートするように拡張可能である。本発明の好ましい一実施形態では、この協調により、ロック管理フェイルオーバおよび協調したデッドロック検出がサポートされる。デッドロック検出とは、２つ以上のクライアント間にデッドロックが存在することを発見する行為（act）を指す。しかし、ロック・キュー・タイムアウト（すなわち、ロック要求がロック・キュー内に留まることのできる期間）がある場合には、サーバ間通信は必要にならない。ロック・キューイングがある場合、ロックがキューイングされる（queued）と言われるのは、あるロック要求の結果ロック衝突が生じる場合であり、エージェントまたはロック・マネージャでは、要求のキューイングが、衝突しているロックが解放されるまで行われる。ロック・キューイングにより、操作の完了が、操作中に遭遇したロック衝突のある場合でも可能になる。衝突しているロックがまったく解放されない場合、この状況をデッドロックと呼ぶ。ロック衝突が起きると言われるのは、クライアントが、別のクライアントのすでに（明示的にせよ暗黙にせよ）ロックしている資源に対するロックを要求するときである。暗黙ロッキングとは、あるエージェントの行った動作の結果として暗黙のうちに獲得されるロックを指す。

トランザクション・マネージャのないロッキングの参照モデル
図３に、本発明の好ましい実施形態による、トランザクション・マネージャのないロッキング環境を示している。トランザクション・マネージャをもたない環境でのロッキングは、「隔離性」レベルにあるとすることも、または「クライアント制御」レベルにあるとすることもできる。

図３に示すロッキング環境では、ロッキング対応クライアント２１０、ロック管理サーバＡ２４０、Ｂ２６０、およびロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４が、ロッキング可能（locking capable）である。ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４は、ロック管理グループＡ２３０、Ｂ２５０に割り当てられており、これらは、ロック管理サーバＡ２４０、Ｂ２６０がそれぞれ管理を行う。

このロッキング環境では、クライアントは、操作を始めるにあたって、操作ＩＤをロック管理サーバＡ２４０またはＢ２６０に要求し、隔離性レベルまたはクライアント制御レベルで動作するという意図の宣言を行う（たとえば、ロッキング対応クライアント−１ ２１０）。ロック管理グループＡ２３０、Ｂ２５０内のエージェントを使用するつもりのクライアントは、操作ＩＤを、ロック管理サーバＡ２４０またはＢ２６０に要求することもできる。ロッキング対応クライアント−１ ２１０が、操作ＩＤを、ロック管理サーバＡ２４０に要求すると仮定すると、ロック管理サーバＡ２４０が、その操作に関する制御サーバとなるが、この操作ＩＤは、ロック管理サーバＢ２６０へアクセスするときにも使用されるはずである。操作ＩＤを得るのは、その操作について１度である。

隔離性とクライアント制御のレベルのどちらのロッキングでも、ロッキング対応クライアント２１０では、ロッキング対応クライアント２１０の使用したいと望む資源（たとえば、オブジェクト）のロックを、ロッキング対応クライアント２１０がロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４に対して動作を行う前に行う。ロッキング対応クライアント２１０は、適切なロック管理グループ（Ａ２３０またはＢ２５０）のロック管理サーバ（Ａ２４０またはＢ２６０）へのロック要求の発行を、ロッキング対応クライアント２１０に割り当てられた操作ＩＤを用いて行う。ロック管理サーバＡ２４０、Ｂ２５０では、ロック要求を受け取り、そのロック要求をロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４へと渡し、そのロック要求が操作ＩＤによって保持されているものとして記録する。ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４では、そのロックを許可（grant）するか、またはそのロックを拒否する。キューイングは、必要である場合には、ロック管理サーバＡ２４０、Ｂ２６０で行われる。本発明の好ましい一実施形態では、ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４は、ロックを拒否した場合、「timeon queue」値を戻すが、これは、ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４では、どれだけの時間ロック要求がキュー上に留まることを許すかを決定するものである。

キューイングされた要求がキューの先頭に来た場合は、そのロックを獲得するためのロック要求が、ロッキング・エージェントＷ２４２、Ｘ２４４、Ｙ２６２、Ｚ２６４へと再発行され、そのロックを獲得した場合、ロッキング対応クライアント−１ ２１０には、ロック要求が許可されたことが通知される。

キューイングされた要求が、キューの先頭に来る前に「タイムアウト」した場合は、ロッキング対応クライアント−１ ２１０には、ロック要求が拒否されたことが通知される。ロック管理サーバＡ２４０、Ｂ２６０は、本発明の好ましい一実施形態では、トランザクション・マネージャではないため、一方的に（unilaterally）ロックを解放することはない。特に、ロックは、ロッキング対応クライアント−１ ２１０の動作が、何らかの「ロールバック」または操作回復処理を実現させるのに必要である。

このロッキングの設計は、ロック管理サーバＡ２４０、Ｂ２６０が、そのロック管理グループＡ２３０、Ｂ２５０の範囲内でロックを行う場合でも、ロックの協調のための「サーバ間」（server to server）通信をサポートするように拡張可能である。本発明の好ましい一実施形態では、ロックの協調により、ロック管理フェイルオーバおよび協調したデッドロック検出がサポートされる。しかし、ロック・キュー・タイムアウトがある場合には、サーバ間通信は必要にならない。

ロッキング非対応クライアント・サポート
図４に、本発明の好ましい一実施形態による、ロッキング非対応クライアント−２ ２７０のあるロッキング環境を示している。特に、図４には、「隔離性」または「クライアント制御」のレベル用のロッキング環境を示している。図４では、ロッキング・エージェントＸ２４４は、装置Ｘ２８０に接続されており、また、これが要素マネージャ・クライアント２９０に接続されている。要素マネージャ・クライアントは、特別なタイプのロッキング非対応クライアントである。「トランザクション」レベルのロッキングに対しても考察は同じであり、このためトランザクション・マネージャは図４の図には示していない。

本発明の好ましい一実施形態では、ロッキング非対応クライアント−２ ２７０は、ロッキング非対応ＣＩＭクライアントである。本発明の好ましい一実施形態では、ロッキング非対応ＣＩＭクライアントであるロッキング非対応クライアントは、（ロッキング対応エージェントを含む）ＣＩＭエージェントを経由する。ロッキング非対応クライアント２７０では、ロッキング・エージェントＷ２４２、Ｘ２４４の管理要求を、ロックを要求せずに行う。そのような場合、ロッキング・エージェントＷ２４２、Ｘ２４４は、要求された動作がＣＩＭで表現されるオブジェクト・モデルへの変更を含む場合、その要求の持続期間（duration）に対する「一時的ロック」（temporary lock）（または「ラッチ」（latch））を得ようと試みる。特に、あるオブジェクトにＣＩＭオブジェクト・パスによって到達する場合には、そのオブジェクトはアクセスの前にロックされる。

ラッチとは、単一の要求を処理するプロセスで、あるエージェントの獲得する一時的な「ロック」である。本発明の好ましい一実施形態では、ラッチの解放は、要求の完了に遅れることなく行われ、ラッチは外部的には設計されていない（すなわち、ラッチは、ロックと異なり、どのようなＣＩＭインターフェース中でも参照されない）。しかし、ラッチは、動作を行う間、一時的に資源を保持するためにエージェントで使用することができる。クライアント要求が読み取り動作であった場合には、ロックは必要とならない（たとえば、その要求は非ロック読み取り（no lock read）として扱われる）。更新要求は（ロッキング対応クライアントの保持するロックが理由で）妨げられる可能性もある。しかし、読み取り動作が妨げられることはない。

考慮すべき特別な場合が、要素マネージャ２９０の場合である。多くの要素マネージャは書き直されることはないであろうとの仮定の下では、要素マネージャがどのようにロッキング対応クライアントとやり取りを行うかを理解することは、特に重要である。要素マネージャは、ロッキング対応環境の「外側」を実行するように準備される。要素マネージャを、ロック管理が存在する場合にはこれを利用するようにコードすることは望ましいかもしれないが、必須であるわけではない。

ロッキング非対応要素マネージャ・クライアント２９０は、装置Ｘ２８０にアクセスするとき、ＣＩＭエージェント構造をなんら経由せずにこれを行うことができる。したがって、ロッキング非対応要素マネージャ・クライアント２９０は、要素マネージャ・クライアント２９０とロッキング対応クライアント−１ ２１０の間のやり取りを実際に管理する際、ロッキング非対応要素マネージャ・クライアント２９０は、装置Ｘ２８０の責任の対象となる。装置Ｘ２８０が従う規則は、これらのものである。すなわち、（１）要素マネージャ・クライアント２９０の発行する読み取り動作は、「非ロック」（ダーティ）読み取りとして扱うことができ、（２）ロッキング対応クライアント−１ ２１０からのロック動作を妨げることになる要素マネージャ・クライアント２９０の動作の担当する資源に対する「ラッチ」を得ることができる。ロッキング対応クライアント−１ ２１０の保持するロックと衝突することになるはずの、要素マネージャ・クライアント２９０の書き込み動作は、拒否される。実際、要素マネージャ・クライアント２９０からの書き込みには、書き込み動作の持続期間に対する変更ロックが伴う。

ロック可能な資源
ロックにより、クライアント（すなわち、クライアント・アプリケーション）要求の主体となる資源（または複数の資源）が予約される。たとえば、あるクライアントがボリュームの変更を希望する場合、そのクライアントにより、そのボリュームがロックされる。このロッキングの設計の１つの重要な部分は、相互運用の基礎となる機能（すなわち、要求）を理解することであり、その資源をロックするために必要なものは、その要求の実行を可能にするために予約される。これと関連する別の問題は、クライアント要求が「作成」（create）である場合に、何がロックされるかである。すなわち、問題は、クライアントが、まだ存在していないものをどうやってロックするのかということである。ボリュームを作成する場合では、クライアントが、そのボリュームが作成されるストレージ・プールをロックすることが妥当であるかも知れない。しかし、これでは、その作成するボリュームをロックするのかどうかという問題は、依然として未解決のままである。最後に、どのようにしてロックを識別するかという問題がある。ロックした資源を一意に表すには、ひと工夫必要である。こうしたトピックのそれぞれを、次のセクションで扱う。

ロッキングの粒度（Granularity）
このロッキングの設計では、ロッキングの粒度が可能になっている。しかし、ロッキングでは、オブジェクト・モデルのあらゆる要素を明示的にロックすることは必要ではない。クライアントは、発行するつもりの要求が直接に影響する資源すべてをロックすることになる。たとえば、ボリュームを作成することには、ボリュームを作成するストレージ・プールに対するロックが必要になる。論理ユニット番号（ＬＵＮ、Logical Unit Number）のマッピングおよびマスキングの要求を行うことには、参照すべきボリューム、ポート、およびホスト・イニシエータ（hostinitiators）をロックすることが必要になる。これは、ロッキングに対するクライアントの見方である。

クライアントの見方に加えて、エージェントの見方がある。エージェントの視点からは、ロッキングの目的は、クライアントが要求を実行できるようにする資源を予約することである。したがって、エージェントは、ロック衝突が理由でクライアント要求が拒否されないようにするために十分な資源のロックを行う。本発明の好ましい一実施形態では、エージェントは、クライアントの要求をサポートするのに必要な資源すべてをロックし、エージェント・モデルの完全性（integrity）を維持することになるが、これは、カスケーディング・ロッキングを意味する。

何をロックすることが必要かに関して曖昧性がある場合はいつでも、エージェントではロックを高次のロックへとエスカレートさせる可能性がある。特に、エージェントが、「エージェント・ロック」へとエスカレートする可能性もある。同様に、クライアントが「エージェント・ロック」を要求するかもしれない。エージェント・ロックは、管理されている装置に対するコンピュータ・システム・インスタンスをロックすることによって実現される。

ロッキング対応クライアントの必要最小限のサポートは、「エージェント・ロック」である。すなわち、どのようなロック要求もエージェント・ロックまでエスカレートさせることができる。

カスケーディング・ロック
エージェントが、そのロッキングの実装において考慮することの必要な、カスケーディング効果がある。このロッキングの設計では、このカスケーディング効果を、あるオブジェクトをロックすることにより、そのオブジェクトが基づいている複数のオブジェクト（すなわち、ＣＩＭ環境内のインスタンス）のロックが効果的に行われるようなものとして定義している。図５には、本発明の特定の実施形態によるカスケーディング・ロッキングを示している。仮想化エージェント３００は、ストレージ・プール３１０およびエクステント３２０を含む。アレイ・エージェント３３０は、ストレージ・ボリューム３４０およびエクステント３５０を含む。ストレージ・プール３１０をロックすることには、ストレージ・プール３１０の基づくエクステント３２０に対するロックが伴う可能性がある。ストレージ・プール３１０に対するロックは、仮想化エージェント３００の管理していない資源に対して発行されたロックを含むことができる（たとえば、ストレージ・プール３１０を所有する仮想化エージェント３００からカスケードされるエージェントの管理する資源）。仮想化エージェント３００のオブジェクト・モデルの完全性を維持するために、仮想化エージェント３００では、より低いレベルのエージェント内の資源をロックする必要があることもある。たとえば、仮想化エージェント３００は、アレイ・エージェント３３０の所有するストレージ・ボリューム３４０およびエクステント３５０をロックすることができる。

ＣＩＭ環境では、プロファイルを定義することができ、プロファイルではそれぞれ、プロファイルのサポートするロックに伴うロック・カスケーディングが定義される。ＳＮＩＡ（Storage Networking Industry Association）は、一部のオブジェクト・モデルに関するプロファイルを開発するために作業中である。１つのプロファイルには、ＳＡＮ（storagearea network）エンティティの特定のあるクラスが記述される。ＳＡＮエンティティのあるクラスにより、ＲＡＩＤ（redundant array ofindependent disks）装置など、ＳＡＮ内部のある装置が記述される。ＲＡＩＤ装置により、複数のハード・ディスク上に同一のデータを格納することが可能になり、したがって、データの複数のコピーへの同時アクセスが可能になる。

ロック識別
インスタンス・ロックは、インスタンスに対するCIMObjectPathを参照することによって実現される。これは、「Enumerate」インスタンスの得る不透明な（opaque）トークンである。「Enumerate」インスタンスは、ＣＩＭ使用のセクション２．３．２．１１に定義されており、ＣＩＭクラスのインスタンスを列挙するために使用される。実際のロック・インスタンスは、クライアントの操作ＩＤとロックされるインスタンスのCIMObjectPathの組み合わせである。実際、ロックは、操作ＩＤとCIMObjectPathの間の関連付けと考えることができる。この関連付けは、ロック型（読み取りまたは変更）の特徴をもつ。

暗黙のロック
ロックを明示的に要求しなくても得られる特定の状況がある。具体的には、資源（たとえば、ストレージ・ボリュームまたはストレージ・プール）を作成するとき、その資源はCIMObjectPathを、その資源が作成されるまではもたないことになる。資源が作成されるとすぐに、CIMObjectPathに対するロックの獲得が、クライアントの操作ＩＤを代理して、クライアントがロック要求を発行しなくても行われる。

同様に、エージェントは、クライアントが要求する以上の資源をロックすることにすることができる。本発明の好ましい一実施形態では、エージェントは、クライアントがロックした資源の「下位」（below）にあるあらゆるものをロックしているとは仮定しない。たとえば、エージェントは、「インスタンス削除」（deleteinstance）操作をサポートするのに何が必要なはずかがわかっており、クライアントが行える「最悪の場合」の要求に伴う資源すべてをロックすることができる。

ロック可能な資源とロッキングのレベル
ロックの行われる資源は、ロッキングのレベルすべて（すなわち、トランザクション、隔離性、およびクライアント制御）で同じである。粒度およびどのようにロックが識別されるかが同じである。カスケードされた暗黙のロッキングは変わることが可能であるが、通常は変わらない。一般に、トランザクション・ロッキングでは、潜在的なロールバック要求をサポートするために、カスケードされた暗黙のロッキングの厳守（strict adherence）が必要となる傾向がある。隔離性およびクライアント制御のレベルのロッキングでは、ロールバック操作をサポートする必要がないため、厳守は必要ではない。

ロックの型
ロックの型（lock type）とは、要求の対象となるロックの「強さ」（strength）を指す。ロックの型により、そのロックの妨げる動作が決定される。ＬＴＭシステム・ロッキングのコンテキストでは、「変更」（change）ロックおよび「読み取り」（read）ロックがある。変更ロックは、読み取りロックよりも強い。

このロッキングの設計でのロック・マネージャおよびロック・エージェントでは、読み取りロックと変更ロックをどちらもサポートしている。読み取りロックでは、他の読み取り側を妨げることのない隔離性（たとえば、読み取られるデータは操作中は変化しない）を保証している。また、このロッキングの設計では、読み取りロックを伴わない「非ロック」（ダーティ）読み取りをサポートしている。

本発明の好ましい一実施形態では、「非ロック」書き込みをサポートしていない。すなわち、ある「OperationId」の下で起きる書き込み操作からは、（「create」操作でのように）ロックの獲得が引き起こされる。「OperationId」がなくて起きる書き込み操作は、クライアントがロッキング非対応クライアントであることを意味し、ロッキング非対応クライアント規則が適用される。すなわち、変更ロック（またはラッチ）がその要求の持続期間の間、獲得される。

読み取りと変更のロックはどちらも、３つのレベルのロッキングすべて（すなわち、トランザクション、隔離性、およびクライアント制御）でサポートされる。

ロック互換性のセマンティクス
表３に、本発明の好ましい一実施形態におけるＬＴＭシステム・ロッキングに関するロック互換性のセマンティクスを要約している。

表３には、２つの異なるクライアントの間の相互作用を示している。第１のクライアントは、資源Ａ上の「ロック保持側」であり、第２のクライアントは、資源Ａ上のロックに対する「ロック要求側」である。ロック保持側が変更ロックをもっている場合、ロック要求はすべて拒否される。しかし、ダーティ・リード（非ロック読み取り）は、ロック要求がないため、妨げられない。ロック保持側が資源上の読み取りロックをもつ場合は、変更ロック要求は拒否され、「非ロック」書き込みは拒否される。ロック要求側は、読み取りロックを得ることができるか、または非ロック読み取りを行うことができる。ロック保持側がロックを保持していない（非ロック読み取り）場合、何も妨げられない。書き込み側でロックを保持しない場合、非ロック読み取り側を除き、要求側はすべて妨げられる。

保護される動作
保護される動作は、ロックの妨げることができる動作である。読み取りまたは変更ロックが何を妨げるかという議論から、基本的な原理が得られるが、ここに提示するガイドラインは、網羅的なリストではない。

ＷＢＥＭ（Web Based Enterprise Management、Ｗｅｂベース・エンタープライズ・マネージメント）は、企業コンピューティング環境の管理の統一のために、ＤＭＴＦ（DistributedManagement TaskForce），Ｉｎｃ．によって開発された管理のセットおよびインターネット標準技術である。ＤＭＴＦでは、ＷＢＥＭを構成する標準のコア・セットを開発しており、これは、ＣＩＭ（CommonInformation Model、共通情報モデル）を含んでいる。

ＣＩＭは、情報の管理のためのオブジェクト指向モデルのための標準である。ＣＩＭ標準は、ＤＭＴＦ（Distributed Management TaskForce），Ｉｎｃ．が提供している。ＣＩＭ標準についてのさらなる情報に関しては、"Specificationfor CIM Operations over HTTP," Version 1.1, May 2, 2002を参照されたい。以下ではこれをCIM specificationと呼び、この文言によりその全体を参照により本明細書に組み込む。

ロックすべき資源は、CIMObjectPathによって識別される。これは、CIMObjectPathをもてば、何であれ、ロックの対象となることを意味する。しかし、ここで提案するロッキングの設計では、何がロックにとって有意味なものかについて少し具体的になっており、カスケーディング・ロッキングに基づいている。一般に、エージェントでは、装置全体のロッキング（すなわち、「エージェントをロックすること」）またはエクスポートされる資源の個々のインスタンスのロッキングがサポートされる。エージェントが、CIMObjectPathで識別される資源のロッキングをサポートしない場合、そのエージェントは、ロックをエージェント・ロックにまでエスカレートさせることができる。

また、ロッキング非対応クライアントとロッキング対応クライアントの間のやり取りに関してはいくつかのガイドラインがある。

読み取り保護（Read Protected）動作は、読み取りロックによって妨げられる動作である。読み取りロックは変更ロックを妨げるが、他の読み取りロックは妨げない。読み取りロックにより、「カスケードされたオブジェクト」およびロック階層内で低位のオブジェクトに対する変更ロックが妨げられる。たとえば、あるエージェントに対する読み取りロックがあると、そのエージェントの管理するオブジェクトすべてに対する読み取りロックがあることになる。あるボリューム上の読み取りロックは、そのロックされているボリュームへの変更をもたらす可能性のあるどの低いレベルのオブジェクトに対する読み取りロックにもカスケードする。したがって、あるボリュームをロックすることにより、そのボリュームが基づいているプール、エクステント、またはアレイへの他のエージェントによる変更が妨げられる。

変更（書き込み）保護（Change (Write) Protected）動作は、変更ロックによって妨げられる動作である。変更ロックにより、他のクライアントからの他の読み取りまたは変更ロックが妨げられる。変更ロックにより、「カスケードされたオブジェクト」に対する他のロックが妨げられる。たとえば、あるエージェントに対する変更ロックがあると、そのエージェントの管理するオブジェクトすべてに対する変更ロックがあることになる。あるボリューム上の変更ロックは、そのロックされているボリュームへの変更をもたらす可能性のあるどの低いレベルのオブジェクト上の変更ロックにもカスケードする。したがって、あるボリュームをロックすることにより、そのボリュームが基づいているプール、エクステント、またはアレイに対する読み取りまたは書き出しが妨げられる。

非保護（Unprotected）動作は、ロックによって妨げられないオブジェクトに対して働く動作である。非保護読み取り（UnprotectedRead）動作は、読み取りロックによって妨げられない動作である。読み取りロックは、他の読み取り側を妨げないが、書き込み側（および変更ロック）は妨げる。非保護書き込み（UnprotectedWrite）動作は、変更ロックによって妨げられない動作である。変更ロックでは、他の関連しないオブジェクトに対するロックを妨げない。変更ロックでは、ロックするオブジェクトへのダーティ・リードは妨げられない。ダーティ・リードとは、ロック（読み取りまたは変更）を獲得せずに情報をエージェントから取り出す任意のクライアント要求である。これは、読み取りが保護されていないため、ダーティ・リードと呼ばれる。同じ情報をその次に読み込んだ場合には、異なる結果がもたらされる可能性もある。また、ＬＴＭシステム内の書き込み動作では、ロッキング対応エージェントがあると、変更の対象となるオブジェクトそれぞれに対する変更ロックがあることが必要である。

ロッキング非対応クライアントとのやり取り
ロッキング非対応クライアントとのやり取りが起きるのは、ＬＴＭシステム・ロッキングが存在しており、「ロック保持側」または「ロック要求側」がロックを行っており、他のクライアントがロッキングを行っていないときである。ロッキング非対応クライアントは、どのようなロックを発行することもまったくない。しかし、ロッキング非対応クライアントが書き込み動作を試みるときには、暗黙の変更ロックが、その動作の持続期間の間、獲得される。したがって、変更または読み取りロックでは、ロックした資源に対するどのようなロッキング非対応クライアント動作も妨げられる。しかし、ロッキング非対応クライアントが読み取り動作を試みた場合（非ロック読み取り）、その読み取り動作はどのようなロッキングによっても妨げられない。ロッキング非対応クライアントが資源を更新している場合には、これにより、ロッキング・クライアントによる変更ロックが一時的に妨げられる。しかし、ダーティ・リード（非ロック読み取り）は妨げられない。

デッドロック管理
このロッキングの設計では、デッドロックを取り扱うために、ロック・マネージャ内にデッドロック検出機構を置いている。このロッキングでは、「lock as you go」セマンティクスがサポートし、ロックが直ちに利用可能でない場合用にロック・キューイングをサポートしている。デッドロックが起きるのは、２つ以上のクライアントが、２つ以上の資源をロックしようと試みており、互いを待っているときである（これは、時に「死の抱擁」（deadlyembrace）と呼ばれる）。本発明の好ましい一実施形態では、そのような状況を解決するために、ロック・マネージャが、そのようなサイクルの検出を試み、デッドロックを起こしているクライアントのうちの１つを選び、そのクライアントのロック要求を拒否することができる。

本発明の好ましい一実施形態では、ＬＴＭシステムで、より単純なアプローチである、ロック・キュー・タイムアウトをサポートしている。ロック要求がロック・キュー上に所定の時間の間ロックを得ることなく留まっている場合には、そのロック要求は拒否される。資源にはそれぞれ、関連付けられているロック・キューがある。

ロックをキューイングすることのできる時間の長さは、そのロックを許可したはずのエージェントが決定する。ロック・キューは、ロック・マネージャ内で保持および維持される。エージェントでは、ロックの許可または拒否を行う。ロックをエージェントが拒否すると、そのエージェントは、「キュー時間」（queue time）（そのロックが、ロック・マネージャに拒否される前にキューイングされたままでいられる時間）の埋め合わせを行うことができる。エージェントでキュー時間の埋め合わせを行わない場合は、ロック・マネージャで、（たとえば、ロック管理の管理者（lockmanagement administrator）が定めるまたは前もって定めた）デフォルトの時間の長さが適用されることになる。ロック要求は、結局拒否されることもある。何が次に起きるかは、使用中のロッキングのレベルによる。

トランザクション・レベルのロッキングでは、キュー上でタイムアウトするロックが、その操作（操作ＩＤにより識別される）をアボートさせることになる。具体的には、タイムアウトを検出するロック・マネージャからトランザクション・マネージャに、ロック要求が拒否されていることが通知される。トランザクション・マネージャにより、ロールバック操作が駆動されることになる。ロールバックの最後の部分は、そのトランザクションの保持しているロックの解放であり、これにより、死の抱擁が解放される（すなわち、デッドロックが終わる）ことになる。

隔離性レベルのロッキングでは、ロック・マネージャから要求元（originating）クライアントに、ロックが拒否されているという応答が返されることになる。クライアントは、ロック要求を再発行することにしてもよいが、クライアントの好ましい動作は、クライアントがそれまでに行っていたことからの回復を試みることになるはずである。この理由から、ロック・マネージャは、ロック拒否の際に、自動的にロックの解放を行わない。クライアントには、ロックの失敗の時点までにクライアントが行っていた作業の「アンドゥ」を試みる機会が与えられる。クライアントがその回復動作を完了したとき、クライアントによってロックが解放される。

クライアント制御レベルのロッキングでは、ロック・マネージャから要求元クライアントに、ロックが拒否されているという応答が返されることになる。隔離性レベルの場合と同様に、クライアント制御の場合のクライアントには、行っていたことを回復する機会が与えられる。しかし、クライアント制御の場合では、これは、クライアントが以前保持していたが、解放してしまったロックを再獲得することになる可能性がある。もちろん、これからは、「循環的拒否」（cyclic denial）の状況が生じかねない。この理由から、ロック・マネージャでは、ロック・マネージャがある操作ＩＤに与えた拒否の数のトラックを把握しておき、所定の数（たとえば、３個）の拒否の後でロックをすべて一方的に解放することになっている。

ロック操作
ロッキング対応クライアントとロック・マネージャ（サーバ）の間の要求／応答プロトコルの説明を、次のセクションで行う。このプロトコルに他のメッセージが追加されることもあり、あるいは一部のメッセージの削除または入れ替えが行われることもある。

ロック要求／応答パラメータ
AgentRequestは、次のパラメータのそれぞれのうちの１つを含む。すなわち、CIMObjectPath（すなわち、ロックすべき各インスタンスに対するオブジェクト・パス）およびType（すなわち、要求されているロックの型（Read（読み取り）またはChange（変更）））である。AgentResultsは、次のパラメータのそれぞれのうちの１つを含む。すなわち、CIMObjectPath（すなわち、ロックされている各インスタンスに対するオブジェクト・パス）およびType（すなわち、許可されたロックの型（ReadまたはChange））。

ロック要求のすべてにおいて、操作ＩＤが１つ提出される。操作ＩＤにより、ロックを要求するクライアント操作が識別される。操作ＩＤの確立は、GetOperationId要求またはBegin Transaction要求で行われる。

QueeueTimeは、ロック要求において、拒否されるエージェントに返される期間である。QueueTimeにより、そのエージェントが、どれくらいの期間、そのロック要求がキューイングされたままであってもかまわないとするかが識別される。

下の図４に、ロック要求、ロック要求を発行する構成要素（すなわち、クライアント、ロック管理サーバ、トランザクション・マネージャ、またはロック・エージェント）、および受け取り側の構成要素（すなわち、クライアント、ロック管理サーバ、トランザクション・マネージャ、またはロック・エージェント）の要約を行っている。ロック要求のそれぞれを、下でさらに詳細に説明することにする。

アステリスク（＊）でマークした要求は、クライアント制御レベルのロッキングで使用されるだけである。

クライアント・トランザクション・マネージャの要求／応答
このセクションでは、クライアントとトランザクション・マネージャの間の要求／応答プロトコルを説明する。

本発明の好ましい一実施形態では、クライアント要求は、BeginTransaction、LogUpdate、CommitTransaction、およびRollbackTransactionを含む。

BeginTransaction( ) 要求は、トランザクション制御（およびトランザクション・レベルのロッキング）の下で実行されるクライアント操作に対する操作ＩＤを要求するクライアントからのメッセージである。クライアントは、トランザクション管理サーバのうちの１つに操作ＩＤを尋ねる。本発明の好ましい一実施形態では、これは、そのクライアントのシステム上にあるトランザクション管理サーバとなるはずである。トランザクション・マネージャの生成する操作ＩＤは、トランザクション・マネージャおよびロック管理（ＬＭ、LockManagement）グループ・サーバへの要求の中で使用される。

LogUpdate(OperationId, Request,ReverseRequest) 要求は、クライアントからトランザクション・マネージャへのものであり、更新動作およびその更新を逆にするために行う動作のログを記録する。

CommitTransaction(OperationId) 要求は、クライアントからトランザクション・マネージャへのメッセージであり、そのトランザクションに関するコミット処理を開始する。

RollbackTransaction(OperationId) 要求は、クライアントからトランザクション・マネージャへのメッセージであり、そのトランザクションに関するロールバック処理を開始する。

本発明の好ましい一実施形態では、トランザクション管理サーバは、次の応答メッセージをサポートしている。すなわち、GrantTransactionID, LogUpdated, CommitDone, およびRollbackDoneである。

GrantTransactionID(OperationId) 応答は、BeginTransaction要求への応答となる。トランザクション・マネージャは、一意の操作ＩＤを生成し、その操作ＩＤをクライアントへと返す。OperationIdのプレフィクス（すなわち、操作ＩＤの最初の部分）は、その操作ＩＤを生成したのが、あるトランザクションのトランザクション・マネージャであることを示している。

LogUpdate(OperationId, Request) 応答は、トランザクション・マネージャからクライアントへのものであり、トランザクション・マネージャが（その要求によって識別される）更新動作のログ記録を完了したことを示す。

CommitDone(OperationId) 応答は、トランザクション・マネージャからクライアントへのメッセージであり、OperationIdによって識別されるトランザクションに対するコミット処理の完了が成功したことを示す。このメッセージは、CommitTransaction要求に応答して送られる。

RollbackDone(OperationId) 応答は、トランザクション・マネージャからクライアントへのメッセージであり、OperationIdによって識別されるトランザクションに対するロールバックが完了したことを示す。このメッセージは、CommitTransactionまたはRollbackTransaction要求に応答して送ることができる。

クライアント・ロック管理サーバの要求／応答
このセクションでは、クライアントとロック管理サーバの間の要求／応答プロトコルを説明する。

本発明の好ましい一実施形態では、クライアント要求は、GetOperationId、LockRequest、ReleaseOperationId、およびLockReleaseを含む。

GetOperationId( ) 要求は、クライアントが行うことになる操作に対する操作ＩＤを要求するロッキング対応クライアントからのメッセージである。クライアントは、ロック管理グループ・サーバのうちの１つに操作ＩＤを尋ねる。そのロック管理サーバの生成した同じ操作ＩＤが、他のロック管理グループ・サーバへの要求でも使用される。トランザクションの可能な環境では、OperationIDを得るのに、BeginTransaction要求を用いることができるが、ロック管理サーバに対するこの要求は発行されないはずである。GetOperationId要求の発行が、BeginTransaction要求の発行後である場合、第２のOperationIdが生成される。

LockRequest(AgentRequest[], Type[],OperationId) 要求は、「Type」パラメータの指定する型（ReadまたはChange）をもつ１つまたは複数のロックを要求するロッキング対応クライアントからのメッセージである。ロックは、指定した操作ＩＤを代理して得られることになる。

ReleaseOperationId(OperationId) 要求は、その操作ＩＤの保持するロックすべての解放を要求するロッキング対応クライアントからのメッセージである。この要求は、その操作に参加する各ロック管理グループ・サーバへと送られるが、操作ＩＤは、１つのロック管理グループ・サーバから得たものである。トランザクションの可能な環境では、ReleaseOperationId要求は、トランザクションを終了させることによって実現され（たとえば、CommitまたはRollbackの後で行われる）、クライアントがReleaseOperationIdコマンドを発行する必要はない。

LockRelease(AgentRequest[], OperationId) 要求は、特定のロックの解放を要求するロッキング対応クライアントからのメッセージである。このコマンドは、クライアント制御レベルのロッキングに対して有効である。本発明の好ましい一実施形態では、はじめに許可されたロックと解放の対象になるロックの間に１対１の関係はない。すなわち、クライアントは、ロックすべてを必ずしも同時に解放するわけではない。

本発明の好ましい一実施形態では、ロック管理サーバでは、クライアント要求に応答して、次の応答メッセージをサポートする。すなわち、GrantOperationId、LockGrant、LockRefused、LockQueued、OperationReleased、およびLockReleasedである。

GrantOperationId(OperationId) 応答は、GetOperationId要求への応答となる。ロック管理サーバでは、一意の操作ＩＤを生成し、それをクライアントに返す。

LockGrant(AgentResults[], OperationId) 応答は、クライアントからのLockRequest要求への応答となる。AgentResultsにより、要求された資源に対して許可するロックおよび許可するロックの型が識別される。AgentResultsは、AgentRequestとは異なっていてもよい。すなわち、ロックが高次のロックへとエスカレートされた可能性がある（たとえば、変更ロックへとエスカレートされた読み取りロック）。また、LockGrantは、そのクライアントで複数の操作が開始されている場合に備えて、操作ＩＤを返す。AgentResultsには、要求したロックまたはエスカレートさせたロックが返される。AgentResultsは、（カスケーディング・ロックによる）暗黙のロックを含まない。したがって、クライアントでは、そのクライアントがロックを要求したオブジェクトについてはわかっている。クライアントでは、ロックされたオブジェクトの「下位」にあるオブジェクトについてはわからない可能性がある。しかし、ロックのエスカレーションの報告は行われる。ロックのエスカレーションとは、保持されているロックを「アップグレード」して、そのロックの範囲を拡大するか、またはそのロックの型をアップグレードすることを指す。エスカレーションは、読み取りロックから変更ロックへのもの、またはインスタンス・ロックからエージェント・ロックへのものとすることができるはずである。クライアントでは、エスカレーションに基づいて妥当な最適化を行うことができるので（たとえば、エージェントへのロック要求の発行を、その操作がすでにエージェント・ロックを保持している状況では停止する）、エスカレーションの報告は行われる。

LockRefused(AgentResults[], OperationId) 応答は、クライアントからのLockRequest要求への応答となる。ロックを許可できず、ロック要求がキュー上でタイムアウトした場合、クライアントはこの応答を得ることになる。また、LockRefusedは、そのクライアントで複数の操作が開始されている場合に備えて、操作ＩＤを返す。

LockQueued(AgentResults[], OperationId) 応答は、サーバから、ロック要求がキューイングされた場合に送られる。この応答メッセージには、必ずしもクライアント側での動作は必要ではないが、このLockQueuedメッセージにより、クライアントは、その操作がキューイングされた状態にあることを知らされる。返されるOperationIdにより、ロック・キューイングの行われている操作が識別される。

OperationReleased(OperationId) 応答は、クライアントからのReleaseOperationId要求への応答となる。また、OperationReleasedは、そのクライアントで複数の操作が開始されている場合に備えて、操作ＩＤを返す。

LockReleased(AgentResult[], OperationId) 応答は、クライアントからのLockRelease要求への応答となる。AgentResultは、LockRelease要求中のAgentRequestとは異なっていてもよい。たとえば、エージェントがインスタンス・ロックをエージェント・ロックへとエスカレートさせていた場合、そのロックは解放されない可能性がある。AgentResultは、実際に、空の配列（nullarray）とすることもできる。LockReleased応答は、クライアント制御のロッキング・レベルに適用される。トランザクション・レベルのロッキングでは、LockRelease要求は拒否される。隔離性レベルのロッキングでは、LockRelease要求は、ロッキングのレベルをクライアント制御まで落とすことになる。

ロック管理サーバ・エージェントの要求／応答
このセクションでは、ロック管理サーバとロッキング対応エージェントの間の特定の要求／応答のセットを説明する。

本発明の好ましい一実施形態では、ロック管理サーバの要求は、AgentRequest、AgentReleaseAll、およびAgentReleaseを含む。

AgentRequest(AgentRequest[], OperationId) 要求は、ロック・マネージャにより、個々のエージェントへのロック要求に翻訳されることになるロック要求である。この要求では、エージェントの管理するオブジェクトに対するロック要求が、そのエージェントへと渡される。エージェントへのロック要求では、操作ＩＤが渡されて、そのロックを要求しているクライアント操作が識別される。許可されたロックは、（AgentRelease要求によって）明示的に解放されるまで保持される。

AgentReleaseAll(OperationId) 要求は、操作（クライアント）の保持する（エージェント）ロックをすべて解放するための要求である。サーバでは、解放すべきロックを明示的にリストすることは、そのロックが操作ＩＤによって暗黙に示される（implied）ため、しなくてもよい。すなわち、ロック・エージェントは、その操作の間、ロックを保つことが期待され、その操作の保持するロックはすべて、AgentReleaseAll要求によって解放される。

AgentRelease(AgentRequest[], OperationId) 要求は、操作（クライアント）の保持している、選択したロックを解放する要求である。この要求が発行されるのは、クライアント操作が、クライアント制御レベルのロッキングで実行されている場合である。

本発明の好ましい一実施形態では、トランザクション環境に関して、発行される要求がさらに３つある。第１は、ロック管理サーバからの「コミット準備」（Prepare to Commit）要求である。コミット準備要求は、エージェントにコミットする準備を行うように告げるためのトランザクション管理機能である。すなわち、コミット準備要求では、エージェントに対して、トランザクションが終わろうとしていること、および、エージェントはコミットまたはロールバックするよう準備すべきであることが告げられる。エージェントからの確認（confirmation）は、そのエージェントがどちらかの方向に進むことができることを意味する。エージェントがトランザクション・マネージャから得ることのできる第２の要求は、「エージェント・ロールバック」（RollbackAgent）または「エージェント・コミット」（Commit Agent）要求である。本発明の好ましい一実施形態では、トランザクション・マネージャは、エージェントのインテリジェンスを利用してロールバックを行うのではなく、ロールバックを駆動するために「逆」の動作を発行することができる。

本発明の好ましい一実施形態では、エージェント応答は、AgentGrant、AgentRefuse、AgentAvail、AgentAllReleased、およびAgentRleasedを含む。

AgentGrant(AgentResult[], OperationId) 応答は、AgentRequestへの応答となる。AgentResultリストは、AgentRequestリストよりも短くすることができる。この場合、暗黙に、要求するロックの一部は拒否されることになる（下を参照されたい）。許可されるロックには、CIMObjectPathおよび許可されるロックの型（たとえば、ReadまたはChange）が示されることになる。本発明の好ましい一実施形態では、AgentResultsは、ロックのエスカレーション（変更ロックへとエスカレートされた読み取りロック、またはエージェント・ロックへとエスカレートされたインスタンス・ロック）を含むが、AgentResultsは暗黙のまたはカスケードされたロックを含まない。

AgentRefuse(AgentResult[], OperationId,QueueTime) 応答は、エージェントがどのロック要求も拒否する場合に、エージェントにより発行される。拒否されるロックは、AgentResultで識別され、QueueTimeが得られる。これは、エージェントが、拒否されたロックのどれでもキュー上に留まるのを許してもかまわないとする時間インターバルである。

AgentAvail(AgentResult[]) 応答は、ロック管理サーバに対して、それまでに要求した（またキューイングした）資源が現在利用可能であることを告げる。実際のキューイングが行われるのは、ロック管理サーバ内である。しかし、このメッセージは、ロッキング非対応クライアントの保持する資源が現在ロッキング用に利用可能であることをロック管理サーバに知らせるのに必要である。

AgentAllReleased(OperationId) 応答は、エージェントからロック管理サーバへと、AgentReleaseAll要求への回答として送られる。

AgentReleased(AgentResult[], OperationId) 応答は、エージェントがロック管理サーバへと、AgentRelease要求への回答として送る応答である。これは、AgentRelease要求と同様に、クライアント制御レベルのロッキングに適用可能である。

発見（discovery）
本発明の好ましい実施形態では、管理者は、ロック管理サーバをセットアップし、そのそれぞれに一意のロック管理グループ値を与える。次いで、管理者は、ロック管理グループ値をエージェントに割り当てる。各エージェントは、ロック管理グループに属さないか、または１つのロック管理グループに属する。エージェントに対するデフォルトのロック管理グループ値は「DefaultUnconfigured」（デフォルト未構成）である。

ロック管理クライアントでは、１つ（複数）のロック管理グループ、そのロック管理サーバ、およびロック管理エージェントの決定を、サービス・エージェントを発見する間に行う。この発見プロセスから、クライアントは、どのロック管理サーバを使用してロック管理エージェント内の資源をロックすべきかを告げられる。本発明の好ましい一実施形態では、２つ以上のロック管理サーバが、１つのロック管理グループ値をサポートしていると発見機構（discovery mechanism）（すなわち、たとえば、ネットワークの資源についてのディレクトリ内の情報を維持する機構）に対して周知する（advertiseitself）と、エラーとなる。ロック管理サーバが立ち上がり、同じロック管理グループ値をもつ別のロック管理サーバを発見する場合には、そのロック管理サーバは、周知すべきではない。

エージェントが立ち上がり、そのロック管理グループに対するロック管理サーバがない場合には、そのエージェントでは、その状態を、「ロッキング可能」（locking enabled）ではないと記録する。

ロック管理の実装
本発明の好ましい一実施形態では、ロック管理の実装は、本明細書で説明するロッキングの設計を実装する適切な構成要素すべてによって行われるが、このロッキングは、環境内で非ロッキング構成要素と共存する。本発明の好ましい一実施形態では、ロッキング環境を得るために、ロック管理を、ロック管理サーバおよびロック管理エージェントで実装するが、クライアントでのロッキングは、クライアントの裁量に委ねられる。ロック管理サーバまたはロック・エージェントは、ロッキングを行わないクライアントまたはロッキング非対応エージェントに対処することができる。こうした場合のそれぞれを下で詳細に論じる。

ロック非対応クライアント
ロック非対応クライアントは、操作に関するロック管理を実装しないクライアントか、またはロッキングをまったく実装しないクライアント（たとえば、レガシ・クライアント）である。ロック対応エージェントは、更新要求をロック非対応クライアントから受け取ると、そのエージェントのロック対応クライアントを保護するために、その操作の持続期間の間、その操作をロックされている（すなわち、変更ロックを伴う）ものとして扱う。すなわち、動作がモデルを更新した場合、それに伴うロックは、その要求から影響を受ける資源に対する変更ロックである。操作が読み取りの場合は、エージェントは動作を「非ロック」読み取りとして扱うことができる。本質的には、ロック非対応クライアントは、ＣＩＭで表現されるオブジェクト・モデルの何らかの部分の更新を試みる場合には、ロック非対応クライアントを妨げることができる（すなわち、拒否される要求となる）。

どのロッキング対応クライアントも、ロック非対応クライアントによって変更中である資源に対するロックを保持しない場合は、その要求は実行することができる。しかし、変更ロック（またはその均等物）が伴うことになり、その結果、ロッキング対応クライアントからのどのようなロック要求も妨げられる。ロッキング対応クライアントからのロック要求の場合には、ロック要求はキューイングすることができる。エージェントは、ロック要求のキューイングに使用すべきキュー時間の値を返す。ロッキング非対応クライアントはロック・マネージャを経由していないため、エージェントからロック・マネージャへは、AgentAvailメッセージが、そのロック非対応クライアントの終了時に発行される。

ロック非対応エージェント／オブジェクト・マネージャ
ロック非対応エージェントまたはオブジェクト・マネージャは、ロック管理を実装していないエージェントまたはオブジェクト・マネージャである。

本発明の好ましい一実施形態では、ロック非対応のＣＩＭＸＭＬ（CommonInformation Model - Extensible Markup Language）サーバ（すなわち、ＣＩＭオブジェクト・マネージャおよびエージェントのあるＣＩＭサーバ）では、ロックを許可および解放するための追加の内在的な方法のサポートを行わない。こうしたレガシの役割を発見するクライアントでは、不変の操作を、それらがロック非対応クライアントであるかのように扱うことになる。

ロック管理クライアント
クライアントでは、その動作するロッキング環境の認識を行う。まず、クライアントは、ロック・マネージャの有無の認識を行う。次いで、クライアントは、トランザクション・マネージャの有無の認識を行う。エージェントがすべてロッキング対応であり、トランザクション・マネージャが存在している場合は、エージェントはトランザクション・レベルのロッキングを使用することができる。トランザクション・マネージャが存在しない場合は、エージェントは、隔離性レベルまたはクライアント制御レベルを使用するか、あるいは、ロッキングをまったく行わない。

構成内にロッキング非対応エージェントであるエージェントがある場合、クライアントでは、これらのエージェント上のどのような動作も保護されないことを認識している。さらに、クライアントでは、トランザクションまたは隔離性のレベルのロッキングを行っている操作は、ロッキング非対応エージェントに関しては、その能力をもたないことを了解している。

クライアントでは、所与の任意の操作においてどのレベルのロッキングを使用すべきかを決定する。コンカレンシおよびスケーラビリティのためには、クライアントがその操作をサポートする「最小」レベルのロッキングを使用することが望ましい。たとえば、あるクライアントが、あるＳＡＮの調査を利用可能なストレージに関して（たとえば、純粋な読み取り操作のために）行っている場合は、そのクライアントがロッキングをまったく行わないことが望ましいはずである。そのクライアントが、利用可能なストレージの調査をボリュームの作成のために行っている場合は、見つかったストレージがそのボリュームの作成に実際に使用可能であることを保証するには隔離性レベルで十分である。

トランザクション・レベルのロッキングの使用は、協調の必要な、場合によってはＳＡＮ内の複数のエージェントにまたがる、複数の更新の関わる複雑な操作のために予約されている。

ある操作の実行をロッキングのレベルの１つの下で行うことにしたクライアントは、操作ＩＤの要求をトランザクション・マネージャまたはそのクライアントの使用することになるロック・マネージャの１つに対して行うことにより、その操作を開始する。操作ＩＤの要求はどのようなロック・マネージャに対しても行うことができるが、クライアントが操作ＩＤの要求を、そのクライアントで使用中のロック・マネージャの１つに対して行う場合には、より効率的である。

ロック管理クライアントに関する規則は、次のように要約される。すなわち、
（１）クライアントでは、そのクライアントが操作において扱わなければならなくなるエージェント、ロック管理サーバ、およびトランザクション・マネージャの一覧を作成して、エージェントがすべてロッキングで扱われているか、およびロッキング環境がトランザクション可能（transaction enabled）かを決定する。ある操作をロッキング操作としてコードできるかどうか、およびロッキングのレベルは、操作により変わりうる。すなわち、クライアントは、そのクライアントの使用することになるロッキングのレベルの選択を、その操作に何が必要になるかのそのクライアントの理解に基づいて行える。

ロック管理クライアントでは、資源に対するロックの獲得を、クライアントがその資源に対する動作を試みる前に行う。しかし、これは、その動作の行われる直前に行うことができる。本発明の好ましい一実施形態では、ロックすべての獲得を、何らかの動作の行われる前に行う必要はなく、「作成」（Create）要求に対する例外が存在する。変更ロックは、「作成」要求に伴うことになる。

単一のロック管理要求は、同じロック管理グループ内のエージェントへの参照を含む。

ロック管理クライアントでは、操作が終わったときにロックを解放する。これは、クライアントがトランザクション・マネージャを使用中の場合（すなわち、コミットまたはロールバックがあると、ロックの解放があることになる）には、クライアントに対して自動的に行われる。

ロック管理クライアントでは、そのロック要求も拒否された場合には、「回復」（recovery）を行ってロックを解放する。すなわち、あるロック要求が拒否されると、その操作の保持する存在中のロックが維持されて、これにより、アプリケーションでは、自前の「アンドゥ」を試みること、またはトランザクション・マネージャのロールバック機能を呼び出すことが可能になる。このどちらかが終わるとすぐに、ロックの解放が行われる。

（ａ）隔離性またはクライアント制御のレベルのロッキングで動作中のロック管理クライアントは、何らかの障害状況に遭遇する前に行われた操作のどの部分でも「アンドゥ」する役目をもつ。

（ｂ）ロック管理クライアントがロックの獲得を試み、その試みが失敗した場合、そのロック管理クライアントは、そのロックの試みを再試行することができる。本発明の好ましい一実施形態では、これは推奨しておらず、ロック管理サーバは、この規則の実施を、再試行の試みで操作ＩＤに対するロックを拒否することによって行うことができる。

ロック管理サーバ
ロッキング・プロセスは、ロッキングに関する状態情報を維持するロック・マネージャ（たとえば、ロック管理サーバ）に関わる。これは、ロック要求はロック管理サーバにより管理され、衝突はロック管理サーバのレベルで扱われることを意味する。ロック管理サーバでは、明らかな衝突およびキュー要求の検出を、エージェントと相談する必要なく行うことが可能である。ロック・マネージャは、たとえば、次の状態情報を維持している。すなわち、
あるクライアント（操作ＩＤ）の保持しているロック
あるクライアント（操作ＩＤ）のためのロックをもつエージェント
ロック・キュー（他のロック要求の背後でキューイングされるクライアント・ロック要求）
ロック・キュー・タイムアウト

このロッキングの設計では、所与のどのロック管理グループでも１つのロック管理サーバがアクティブである。１つのエージェントは、１つのロック管理グループに属する。本発明の好ましい一実施形態では、ロッキングの設計で、どのロック管理グループにも属さないエージェントという概念がサポートされるが、そのようなエージェントの管理する資源は、ロッキング制御下にはない。

あるロック管理サーバが、ロック管理エージェントの発見を行う間、ロック管理グループ値の同じ別のアクティブなロック管理サーバを見つけた場合、そのロック管理サーバはアクティブにならない。しかし、そのロック管理サーバは、ロック管理グループ値の同じもう１つのロック管理サーバとの通信を開始し、そのロック管理グループ値に対するバックアップのロック管理グループ・サーバの地位に収まる。

ロック管理サーバは、その動作する環境を認識する。具体的には、ロック管理サーバは、他のロック管理グループ・サーバの発見を行い、そのロック管理サーバが、ロック管理グループ値に対する唯一のロック管理サーバであることを確認する。また、そのロック管理サーバは、ロック管理グループ値の同じエージェントをすべて発見する。

ロック管理サーバでは、以下の機能を行うことが可能になっている。

ロッキングのレベル（トランザクション、隔離性、またはクライアント制御）をサポートし実施すること。具体的には、OperationIdがトランザクションＩＤである（すなわち、プレフィクスが付いている）場合、ロック・マネージャが、トランザクションの終わる前のロックの解放をサポートすることはない。隔離性とクライアント制御のレベルの場合を比較すると、ロック・マネージャは、隔離性レベルを、クライアントが個々のロックを解放するまでは仮定している。その後は、ロック・マネージャではその操作を、クライアント制御としてマークする。

（２）OperationIdを生成すること。サーバは、操作ＩＤを生成して、隔離性およびクライアント制御のレベルのロッキングに対するクライアント操作を識別することができる。本発明の好ましい一実施形態では、OperationIdは複合した値である。値の第１の部分では、その操作がトランザクションでないことを示し、第２の部分はロック管理グループ値であり、値の第３の部分はロック管理グループの範囲内で一意である識別子である。識別子は、０から２^３２−１の範囲にある整数である。このため、同じ時間フレーム内での再使用を避けるのに十分な距離が可能になっている。

どのロックが保持されているかの記録を、どの資源（たとえば、CIMObjectPath）をどの保持側（OperationId）が保持しているかを記録することによって行うこと、また、キューイングされているロック要求の記録を維持すること。

ロック・マネージャまたはロック・エージェントの障害後にロックを回復すること。また、ロック・キューを回復すること。

妨げられているロック要求をキューイングすること。許されるキュー時間の埋め合わせが、その資源をロックしていたはずのエージェントによって行われる。ロック管理サーバでは、エージェントの主張したキュー時間を守るために、キュー上での時間を監視する。操作がロックを得る前にキュー時間が時間切れになった場合、クライアントにはロックが拒否されたというメッセージ（lock refused message）が返される。

クライアントから求められたときにロックを解放すること。ロック管理サーバでは、エージェントおよびクライアントとのハートビート機能を使用して障害（たとえば、クライアント、エージェント、または通信の障害）の場合のロックの解放を行う。ハートビート機能は、たとえば、サーバからクライアントおよびエージェントへと送られる信号、ならびに、応答しているクライアントまたはエージェントが正しく機能していることを示すその信号への応答である。

本発明の好ましい一実施形態では、ロック管理サーバは、また、他のロック・マネージャとの通信を実装してロック管理フェイルオーバを実現する。

ロック管理サーバの特色
本発明の好ましい一実施形態では、最小限のロック管理サーバは、次の特徴および特色を持つはずである。
ロック管理サーバ要求を受理し、所定の応答を提供すること。
ロック管理エージェント要求を駆動し、その応答を処理すること。
ロッキング対応クライアント操作をサポートするときに、ステートフル（stateful）であること。
ＳＰＯＦ（single point of failure、単一機器の障害がシステム全体の障害となる箇所）に従属しているが、ロック管理サーバ・フェイルオーバをサポートするようにも設計されていること。
機能をそれ自体のロック管理グループの範囲内で行うこと。

ロック・マネージャの自由選択による向上
本発明の好ましい一実施形態では、次のものをサポートするようにロック・マネージャを設計することが可能である。すなわち、
可用性の高い（highly available）ロック管理サーバ
トランザクショナル（transactional）なロック管理サーバ

ロック管理エージェントの考慮
ロッキング対応エージェントは、ロッキング・モードまたは非ロック（no lock）モードで動作するように作成されている。ロッキング対応エージェントが行うよう求められるものは、操作により様々である。

最初の発見中に、ロッキング対応エージェントは、そのロック管理グループ・サーバを探す。ロック管理グループ・サーバが見つかった場合は、そのエージェントのロッキング機能がイネーブルになる。ロック管理グループ・サーバが見つからなかった場合は、そのエージェントは非ロック・モードで動作する。

特定の実施形態では、ロック管理エージェントがロック要求を処理するときに従う必要のある規則は、次のものである。すなわち、
許可されたロックは、すべて、明示的に解放されるまで保持する。
ロッキング対応クライアントの保持するロックと衝突するようなロッキング非対応クライアントからの動作は妨げる。
ロック非対応クライアントによる使用が理由でロック要求を拒否した後で資源が利用可能になっているときは、ロック管理サーバに（AgentAvailで）通知する。

ロック管理の使用ケース
このロッキングの設計の例示のために、クライアント操作のための１組の想定状況（scenarios）を説明することにする。ロック論理の説明は、次の想定状況のそれぞれに対して行う。すなわち、
ストレージの不十分な仮想化システム上にボリュームを作成する
ある仮想化システムから別の仮想化システムへとストレージを移動させる
仮想化システムからホスト・ベースの仮想化へとストレージを移動させる。
論理ボリューム・マネージャ上に論理ボリュームを作成し、それを仮想化サブシステムおよびディスク・アレイからプロヴィジョンする

仮想化システム上にボリュームを作成する
図６に、本発明の好ましい実施形態による、ストレージの不十分な仮想化システム上でのボリュームの作成を示している。クライアント（Ｃ１）４００は、仮想化サブシステム（Ｖ１）４１０上にボリュームの作成を試みるが、仮想化サブシステム４１０には、そのボリュームを作成するのに十分なストレージがない。このため、クライアント４００は、まず、ストレージをディスク・アレイＳＳ１ ４２０から得る。このストレージはＶ１ ４１０へと割り当てられ、次いで、このストレージは、Ｖ１ ４１０上で使用することができる。動作は操作ＩＤ１（Ｏｐ１）と関連付けられている。この操作の具体的なステップは、次のものである。

（１）ＳＳ１ ４２０上にボリュームを（たとえば、ＣＩＭにあるStorageConfigurationServiceステートメントによって）作成する − これは、ＳＳ１ ４２０内でストレージ・プールをロックし、ボリューム作成（createvolume）サービスを発行するものである。この想定状況での仮定は、仮想化サブシステム４１０が、ストレージの自動プロヴィジョニングを行わないことである。ＳＳ１ ４２０上でのボリュームの作成は、クライアント４００が行う。

（２）ボリュームをＶ１ ４１０に割り当てる − 作成したばかりのボリュームをＶ１ ４１０へと割り当てる（すなわち、論理ユニット番号（ＬＵＮ、logical unit number）がマッピングされる）。仮定は、このボリュームのＶ１ ４１０による制御は、クライアント４００がこのボリュームをＶ１ ４１０へマッピングするまで行われない、ということである。

（３）ストレージ・プールのＶ１ ４１０への拡張を、ボリュームのプールへの追加によって行う − Ｖ１ ４１０に割り当てたボリュームが、Ｖ１ ４１０オブジェクト・モデルにエクステントとして現れる。クライアント４００は、このエクステントを、新しいＶ１ ４１０を収容することになるＶ１ ４１０ストレージ・プールへと追加する。

（４）ＬＵＮをＶ１ ４１０上に作成する − クライアント４００が、実際にボリュームをＶ１ ４１０上に作成する。

図７に、本発明の好ましい実施形態による、ストレージの不十分な仮想化システム上でのボリュームの作成のための一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表４６０を示している。

ある仮想化システムから別の仮想化システムへとストレージを移動させる
図８に、本発明の好ましい実施形態による、ある仮想化システムから別の仮想化システムへのストレージの移動を示している。クライアント（Ｃ１）５１０は、ロック管理グループＡ５００内である仮想化システム（Ｖ１）５２０から別の仮想化システム（Ｖ２）５３０へとストレージを移動させることを試みる。このために、クライアント５１０は、Ｖ１ ５２０上のストレージを解放し、次いで、解放したストレージをＶ２ ５３０へと割り当てる。Ｖ１ ５２０から解放されたストレージは、ロック管理グループＢ５４０内のアレイＳＳ１ ５５０によって保持される。動作は操作ＩＤ１（Ｏｐ１）と関連付けられている。この操作の具体的なステップは次のものである。

Ｖ１ ５２０上のエクステントを削除する（StorageConfigurationService） − これは、Ｖ１ ５２０内でストレージ・プールをロックし、エクステント削除（deleteextent）サービスを発行するものである。この想定状況での仮定は、ストレージ・プールをロックすることによって、ストレージ・プールのエクステントがロックされる、ということである。

ＳＳ１ ５５０ ボリュームをＶ１ ５２０からアンマップ（unmap）する − これは、ＳＳ１ ５５０ボリューム、および、このボリュームのマッピングされていたポート／イニシエータをロックするものである。ここでの仮定は、マッピングに関わるオブジェクトは、（マップ要求でわかるように）ロックに必要なものである、ということである。

ＳＳ１ ５５０ボリュームをＶ２ ５３０へとマッピングする − 操作ではすでにこのボリュームに対するロックを保持しているが、操作は、Ｖ２ ５３０に対する新しいポート／イニシエータのロックも行う。

エクステント（ＳＳ１ ５５０ボリューム）をＶ２ ５３０ストレージ・プールへと追加する（StorageConfigurationService） − これは、Ｖ２ ５３０上のストレージ・プールをロックするものである。

図９および図１０に、本発明の好ましい実施形態による、ある仮想化システムから別の仮想化システムへのストレージの移動のために隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表５６０を示している。

仮想化システムから論理ボリュームへとストレージを移動させる
図１１に、本発明の好ましい実施形態による、仮想化システムから論理ボリューム・マネージャへのストレージの移動を示している。クライアント（Ｃ１）６１０は、ロック管理グループＡ６００内のある仮想化システム（Ｖ１）６２０から論理ボリューム・マネージャ（ＬＶＭ１）６３０へとストレージを移動させる。このために、クライアント６１０はＶ１ ６２０上のストレージを解放し、解放したストレージをＬＶＭ１ ６３０へと割り当てる。Ｖ１ ６２０から解放されたストレージは、ロック管理グループＢ６４０内のアレイＳＳ１ ６５０によって保持されている。動作は、操作ＩＤ１（Ｏｐ１）に関連付けられている。この操作の具体的なステップは、次のものである。

Ｖ１ ６２０上のエクステントを削除する（StorageConfigurationService） − これは、Ｖ１ ６２０内のストレージ・プールをロックし、エクステント削除（deleteextent）サービスを発行するものである。この想定状況での仮定は、ストレージ・プールをロックすることにより、そのストレージ・プールのエクステントがロックされる、ということである。

ＳＳ１ ６５０ボリュームをＶ１からアンマップする − これは、ＳＳ１ ６５０ボリューム、および、このボリュームのマッピングされていたポート／イニシエータをロックするものである。ここでの仮定は、マッピングに関わるオブジェクトは、（マップ要求でわかるように）ロックの必要なものである、ということである。

ＳＳ１ ６５０ボリュームをＬＶＭ１ ６３０へとマッピングする − 操作ではすでにこのボリュームに対するロックを保持しているが、操作は、ＬＶＭ１ ６３０に対する新しいポート／イニシエータのロックも行う。

エクステント（ＳＳ１ ６４０ボリューム）をＬＶＭ１ ６３０論理ボリューム・グループ（ストレージ・プール）へと追加する（StorageConfigurationService） − これは、ＬＶＭ１ ６３０上の論理ボリューム・グループをロックするものである。

図１２および図１３に、本発明の好ましい実施形態による、ある仮想化システムから別の論理ボリューム・マネージャへのストレージの移動のために隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表６６０を示している。

論理ボリュームを作成し、それを複数のソースからプロヴィジョンする
図１４に、本発明の好ましい実施形態による、論理ボリュームの作成、および複数のソースからのその論理ボリュームのプロヴィジョンを示している。クライアント（Ｃ１）７００は、論理ボリュームの作成、および、その論理ボリュームの複数のソースからのプロヴィジョンを試みている。具体的には、クライアント７００は、ストレージを仮想化システム（Ｖ１）７２０およびストレージ・アレイ（ＳＳ１）７３０から得ようと望む。動作は、操作ＩＤ１（Ｏｐ１）に関連付けられている。この操作の具体的なステップは、次のものである。

ボリュームをＶ１ ７２０上に作成する（StorageConfigurationService） − これは、Ｖ１ ７２０内のストレージ・プールをロックし、ボリューム作成（createvolume）サービスを発行するものである。

Ｖ１ ７２０ボリュームをホスト（すなわち、論理ボリューム・マネージャ１（ＬＶＭ１）７１０）にエクスポーズ（すなわち、マッピング）する − これは、Ｖ１ ７２０ボリューム、および、このボリュームのマッピングされていたポート／イニシエータをロックするものである。ここでの仮定は、マッピングに関わるオブジェクトは、（マップ要求でわかるように）ロックの必要なものである、ということである。

ＳＳ１ ７３０上にボリュームを作成する（StorageConfigurationService） − これは、ＳＳ１ ７３０内のストレージ・プールをロックし、ボリューム作成（createvolume）サービスを発行するものである。

ＳＳ１ ７３０ボリュームをホスト（すなわち、ＬＶＭ１）にエクスポーズ（すなわち、マッピング）する − これは、ＳＳ１ ７３０ボリューム、および、このボリュームのマッピングされていたポート／イニシエータをロックするものである。ここでの仮定は、マッピングに関わるオブジェクトは、（マップ要求でわかるように）ロックの必要なものである、ということである。

論理ディスク（すなわち、エクステント）をＬＶＭ１ ７１０論理ボリューム・グループ（ストレージ・プール）に追加する（Storage Configuration Service） − これは、ＬＶＭ１ ７１０上の論理ボリューム・グループをロックするものである。

図１５および図１６に、本発明の好ましい実施形態による、論理ボリュームの作成、および複数のソースからのその論理ボリュームのプロヴィジョンのための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表７６０を示している。

ロックおよびトランザクション管理
図１７に、本発明の好ましい実施形態による、ロックおよびトランザクション管理（ＬＴＭ、lockand transaction management）システムにおいてロックを処理するために実装する論理を示している。制御は、ブロック８００で、クライアントがロックすべき資源を識別することから始まる。また、このクライアントには、どのエージェントがその資源へのアクセスを制御する（すなわち、「資源を制御する」）かがわかっており、このクライアントは、ロック要求を、ロック・マネージャを介して、資源へのアクセスを制御するロック・エージェントへと送る（ブロック８１０）。エージェントでは、ロック要求を許可または拒否し（８２０）、エージェントは、ロック要求に対する応答をロック・マネージャ（８３０）へと送る。ロック・マネージャは、ロック要求が許可されたかどうかを判定する（ブロック８４０）。ロック要求が許可されていた場合は、ロック・マネージャは許可通知をクライアントへと転送し（ブロック８５０）、そうでない場合は、ロック・マネージャはそのロック要求をキューイングする（ブロック８５０）。

図１８に、本発明の好ましい実施形態による、ロック・マネージャの実装する論理を示している。制御は、ブロック９００で、ロック・マネージャが、マルチ・ベンダ・クライアントから受け取ってマルチ・ベンダ・エージェントに向けられたロック要求を管理し、マルチ・ベンダ・エージェントからマルチ・ベンダ・クライアントへの応答を管理することから始まる。マルチ・ベンダ環境では、複数のベンダのそれぞれが、すべてのベンダが開発した役割における同じ論理（たとえば、エージェントまたはクライアント）を実装しようと試みている。典型的なＳＡＮ環境は、マルチ・ベンダ環境を含む。したがって、「マルチ・ベンダ・クライアント」という用語は、クライアントまたはクライアントのサブセットのそれぞれを異なるベンダが開発した可能性があることを示すのに使用する。「マルチ・ベンダ・エージェント」という用語は、エージェントまたはエージェントのサブセットのそれぞれを異なるベンダが開発した可能性があることを示すのに使用する。

ロック・マネージャでは、各マルチ・ベンダ・クライアントおよびマルチ・ベンダ・エージェントについての状態情報を維持する（ブロック９１０）。ロック・マネージャは、マルチ・ベンダ・エージェントの拒否したロック要求に関するキューイングを管理する（ブロック９２０）。ロック・マネージャは、ハートビート機能を実行して、マルチ・ベンダ・クライアントおよびマルチ・ベンダ・エージェントが正しく機能するようにする（ブロック９３０）。

図１９に、本発明の好ましい実施形態による、トランザクション・マネージャの実装する論理を示している。制御は、ブロック１０００で、トランザクション・マネージャが、あるトランザクションが異種（heterogeneous）分散環境内で始まっているという標示を受け取ることから始まる。異種分散環境とは、クライアント、トランザクション・マネージャ、ロック・マネージャ、およびエージェント、または、こうした役割のサブセットが、同じまたは異なるベンダ製のものである環境である。ブロック１０１０で、トランザクション・マネージャは、そのトランザクションに関する操作識別子を生成する。ブロック１０２０で、トランザクション・マネージャは、その操作識別子で識別されるトランザクションに対する動作のログを記録するが、この動作は、要求、（ロールバックで使用するための）対応する逆の要求、およびロック許可を含む。たとえば、ある要求は「ボリュームＸを作成する」ものであることがあるが、この場合、対応する逆の要求は「ボリュームＸを削除する」となるはずである。ブロック１０３０で、トランザクション・マネージャは、そのトランザクションに関するコミット処理を行う。ブロック１０４０で、トランザクション・マネージャは、そのトランザクションに関するロールバック処理を、必要な場合には行う。

図２０および図２１に、本発明の好ましい実施形態による、ある資源をロックするのにどの操作識別子を使用すべきかを決定するときにカスケーディング・エージェントの実行する論理を示している。図２０において、制御は、ブロック１１００で、第１のエージェントが、関連付けられている操作識別子をもつクライアントが第１のエージェントの制御する資源をロックするロック要求を受け取ることから始まる。第１のエージェントは、第１のエージェントの制御する資源のロックを、クライアントに関連付けられている操作識別子によって行う（ブロック１１０２）。すなわち、このロックは、クライアントに関連付けられている操作識別子に関連付けられている。その資源のロックを同じ操作識別子によって行う別の要求を受け取った場合、そのロック要求は許可される。

第１のエージェントは、第２のエージェントの制御する追加の資源のロックを、そのクライアントの要求を処理するための同じ操作識別子によって行うべきかどうかの判定を、第２のエージェント上で行うべき操作が、そのクライアントの要求の完了するときまでに完了しなければならないかどうかに基づいて行う（ブロック１１０４）。すなわち、第２のエージェント上で行うべき操作が、クライアントの要求が完了するときまでに完了しなければならない場合、第２のエージェントの制御する追加の資源は、同じ操作識別子によってロックされる。ブロック１１０６で、追加の資源を同じ操作識別子でロックすべきであると判定された場合には、処理はブロック１１０８へと続き、そうでない場合、処理はブロック１１１８へと続く。

ブロック１１０８で、第１のエージェントは、ロック要求を第２のエージェントのロック・マネージャへと送って、追加の資源を同じ操作識別子によってロックする。ブロック１１１０で、第２のエージェントのロック・マネージャは、ロックの衝突が存在するかどうかを判定する。ロックの衝突が存在する場合、処理はブロック１１１４へと続き、そうでない場合、処理はブロック１１１２へと続く。ブロック１１１４で、第２にエージェントのロック・マネージャが、ロック要求をキューイングする。ブロック１１１２で、第２のエージェントのロック・マネージャは、ロック要求を第２のエージェントへと渡す。第２のエージェントは、第２のエージェントの制御する資源を、同じ操作識別子によってロックする（ブロック１１１６）。

ブロック１１１８で、第１のエージェントは、そのロック・マネージャから新しい操作識別子を得る。第１のエージェントは、第２のエージェントのロック・マネージャに通知を送って、追加の資源を新しい操作識別子によってロックする（ブロック１１２０）。ブロック１１２２で、第２のエージェントのロック・マネージャは、ロックの衝突が存在するかどうかを判定する。ロックの衝突が存在する場合、処理はブロック１１２６へと続き、そうでない場合、処理はブロック１１２４へと続く。ブロック１１２６で、第２のエージェントのロック・マネージャは、ロック要求をキューイングする。ブロック１１２４で、第２のエージェントのロック・マネージャは、ロック要求を第２のエージェントへと渡す。第２のエージェントでは、第２のエージェントの制御する資源を、新しい操作識別子によってロックする（ブロック１１２８）。

図２２および図２３に、本発明の好ましい実施形態による、第１のエージェントが、第２のエージェントの制御する資源をロックし、第２のエージェントが、その資源をロックする別の要求を受け取るときに、カスケーディング・エージェントの実行する論理を示している。図２２において、制御は、ブロック１１５０で、第１のエージェントが、関連付けられている操作識別子をもつクライアントが、第２のエージェントの制御する資源をロックする要求を受け取ることから始まる。第１のエージェントは、第２のエージェントの制御する資源を、そのクライアントに関連付けられている操作識別子によってロックする（ブロック１１５２）。図２３において、制御は、ブロック１１５４で、第２のエージェントが、クライアントが、第２のエージェントの制御する、資源を操作識別子によってロックする要求を受け取ることから始まる（ブロック１１５４）。第２のエージェントは、その資源がすでに同じ操作識別子によってロックされているかどうかを判定する（ブロック１１５６）。本発明の好ましい一実施形態では、第２のエージェントは、その資源がすでに同じ操作識別子によってロックされているかどうかを判定するために、第１の操作識別子を、その資源をロックするのに使用した操作識別子と突き合わせる。ブロック１１５８で、その資源がすでに同じ操作識別子によってロックされていた場合、処理はブロック１１６０へと続き、そうでない場合、処理はブロック１１６２へと続く。ブロック１１６０で、第２のエージェントは、その資源が同じ操作識別子によってロックされていることを、クライアントに通知する。ブロック１１６２で、第２のエージェントは、ロック要求の拒否をそのロック・マネージャへと送る。ブロック１１６４で、第２のエージェントのロック・マネージャは、そのロック要求をキューイングする。

図２４に、本発明の好ましい実施形態による、クライアントによる異なるレベルロッキングを可能にするロック・マネージャの実装する論理を示している。制御は、ブロック１２００で、ロック・マネージャがクライアントからコマンドを受け取ることから始まる。ブロック１２１０で、ロック・マネージャは、操作識別子に、その操作識別子をトランザクション・マネージャが生成したことをプレフィクスが示すコマンドが与えられているかどうかを判定する。ブロック１２２０で、トランザクション・マネージャがその操作識別子を生成したと判定された場合、処理はブロック１２３０に続き、そうでない場合、処理はブロック１２４０に続く。ブロック１２３０で、ロック・マネージャは、トランザクション・レベルのロッキングで動作する。ブロック１２４０で、ロック・マネージャは、クライアントがロック（すなわち、ロックならどれでも）を解放するまで、隔離性レベルのロッキングで動作する。クライアントがロックを解放した後、ロック・マネージャはクライアント制御レベルのロッキングで動作する。

図２５に、本発明の好ましい実施形態による、あるエージェントの実装する論理を示している。制御は、ブロック１３００で、あるエージェントが、１つまたは複数の動作を含む操作を受け取ることから始まる。この操作は複数の同時非協働的クライアントからの複数のエージェントにまたがって保護されており、ここで１つの操作は１つまたは複数の動作を含む。特に、各読み取り保護動作に対しては、ある資源に対する読み取りロックが保持され、書き込み動作は、その読み出しロックで保護されている資源への書き込みを妨げられる（ブロック１３１０）。各書き込み保護動作に対しては、ある資源に対する変更ロックが保持され、変更ロックで保護されている資源に対する書き込み動作ならびに読み取りおよび変更ロックは妨げられる。

図２６に、本発明の好ましい実施形態による、デッドロックを解決するためにロック・マネージャ内に実装する論理を示している。制御は、ブロック１４００で、ロック・マネージャが、第１の操作識別子による、第２の操作識別子によってすでにロックされている資源（たとえば、オブジェクト）に対するロック要求の拒否を受け取ることから始まる。このロック要求は、クライアントが送り、エージェントが拒否したものである。ロック・マネージャは、ロック要求を、ロック・キュー・タイムアウト期間をもつキューに入れる（ブロック１４１０）。ブロック１４１２で、ロック・マネージャは、そのロック要求が、ロック・キュー・タイムアウト期間内にキューの先頭にあるかどうかを判定する。そうである場合、処理はブロック１４２０へと続き、そうでない場合、処理はブロック１４１４へと続く。呼び方を簡単にするために、本明細書では、キューの「先頭」（top）は、ロック・マネージャがロック要求の処理をそこから行えるキューの位置を指すのに使用している。ブロック１４１４で、ロック・マネージャは、ロック・キュー・タイムアウト期間が時間切れになったかどうかを判定する。そうである場合、処理はブロック１４５０へと続き、そうでない場合、処理はブロック１４１２へと続く。

ブロック１４２０で、ロック・マネージャはロック要求を再発行する。特に、ブロック１４２０で、ロック・マネージャがロック要求を再発行する理由は、そのロックの解放が、そのロックをその前に保持していたものによって行われており、キューイングされたロック要求がロック・キュー・タイムアウト期間内にキューの先頭へと移動したためである。ロック・マネージャでは、キューイングされたロック要求の処理を、それがキューの先頭に来た後行うことに注意されたい。ブロック１４３０で、ロック要求の許可がロック・キュー・タイムアウト期間内に行われた場合、処理はブロック１４４０へと続き、そうでない場合、処理はブロック１４１２へと続く。ブロック１４４０で、ロック・マネージャは、そのロック要求をキューから取り除く。ロックが許可されなかった場合、ロック要求を再びキューイングする（re-queued）。このようにして、すでにロックされているある資源に対するロック要求は、後で許可されるか、または終了させられ、デッドロック状況が回避される。代替実施形態では、ブロック１４１０で、ロック要求のキューへの再挿入を、そのロック要求がそれまでに何回キューに入れられているかなど、１つまたは複数の要因に基づいて行うことができる。

特に、ロック要求がキューの先頭に達し再発行されると、ロック要求は、通常、後で許可される。しかし、ロッキング非対応クライアントが所望のロックを得る場合があるかもしれない。したがって、再発行されたロック要求をエージェントが拒否することになることはあり得る。この場合、ロック要求はキュー上に戻され、「ロッキング非対応クライアント・ロック」がクリアされるのを待つ。エージェントからロック・マネージャへと流れるAgentAvailメッセージにより、そのロックがロッキング非対応クライアントによって解放されていることの標示が与えられる。ロック・マネージャがAgentAvailメッセージを得ると、ロック・マネージャではそのことを知ってロック要求を再発行し、またはキュー上のロック要求がタイムアウトしていた場合には、ロック・マネージャではそのメッセージを単に破棄する。

実装に関するその他の詳細
ロックおよびトランザクションを管理するための説明した技法は、方法、装置、または製造物として、ソフトウェア、ファームウェア、ハードウェア、またはそのどのような組み合わせも製造する、標準のプログラミングのまたは工学上の技法あるいはそのどちらを用いても実装することができる。本明細書で使用する「製造物」（article of manufacture）という用語は、ハードウェア論理（たとえば、集積回路チップ、ＰＧＡ（ProgrammableGate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）など）、または、磁気ストレージ媒体（たとえば、ハード・ディスク・ドライブ、フロッピー（Ｒ）・ディスク、テープなど）、光学ストレージ（ＣＤＲＯＭ、光ディスクなど）、揮発性および不揮発性のメモリ装置（たとえば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラマブル・ロジック（programmablelogic）など）などのコンピュータ可読媒体の形で実装されるコードまたは論理を指す。コンピュータ可読媒体内のコードは、プロセッサによってアクセスおよび実行される。好ましい実施形態を実装するコードは、さらに、伝送媒体を通してまたはファイル・サーバからネットワークを介してアクセス可能である。そのような場合、コードを実装する製造物は、ネットワーク伝送線、無線伝送媒体、空間を伝播する信号、電波、赤外線信号などの伝送媒体を含む。したがって、「製造物」は、コードを実施する媒体を含む。さらに、「製造物」は、コードを実施し、処理し、実行するハードウェアとソフトウェアの構成要素の組み合わせを含む。もちろん、多くの変更をこの構成に対して行うことができること、および、製造物は当技術分野に知られているどのような情報担持媒体も含むことができることが当業者には理解されよう。

図１７〜２６の論理では、特定の順序で起きる特定の操作を説明している。代替実施形態では、論理動作の特定のものは、変更するにせよ削除するにせよ、異なる順序で実行することができる。しかも、複数のステップを上で説明した論理には追加しても説明した実施形態に適合することが可能である。さらに、本明細書で説明する動作は逐次的に起きてもよく、または特定の動作を並列して処理することができ、あるいは単一プロセスによって行われると説明した動作は、分散プロセスによって行うこともできる。

図１７〜図２６の論理を、ソフトウェアの形で実装するものとして説明した。この論理は、ホスト・システムまたはアプリケーション・プログラムのオペレーティング・システムの一部とすることができる。さらに別の実施形態では、この論理をストレージ領域内、あるいはＲＯＭ（read only memory）または他の直接結線（hardwired）型の装置内に維持することができる。好ましい論理は、ハード・ディスク・ドライブ内に、またはプログラマブルおよび非プログラマブルのゲート・アレイ論理として実装することができる。

図２７に、本発明の好ましい実施形態による役割（roles）１１０、１２０、１３０、１４０Ａ．．．Ｎのアーキテクチャを示している。ロッキング対応クライアント１１０，トランザクション管理サーバ１２０、ロック管理サーバ１３０、およびロック管理エージェント１４０Ａ．．．Ｎは、それぞれ、プロセッサ１５０２（たとえば、マイクロプロセッサ）を有するコンピュータ・アーキテクチャ１５００、メモリ１５０４（たとえば、揮発性メモリ装置）、およびストレージ１５０６（たとえば、磁気ディスク・ドライブ、光ディスク・ドライブ、テープ・ドライブなどの不揮発性ストレージ）の形で実装することができる。ストレージ１５０６は、内部ストレージ装置あるいは外付けまたはネットワーク・アクセス可能なストレージを含むことができる。ストレージ１５０６内のプログラムは、メモリ１５０４へとロードされ、プロセッサ１５０２によって当技術分野に知られている形で実行される。このアーキテクチャは、ネットワークとの通信を可能にするネットワーク・カード１５０８をさらに含む。入力装置１５１０は、ユーザ入力をプロセッサ１５０２に提供するために使用され、キーボード、マウス、ペン・スタイラス、マイクロフォン、触覚感知ディスプレイ画面、または、当技術分野に知られている他のどのようなアクティベーションまたは入力機構を含むことができる。出力装置１５１２は、プロセッサ１５０２、または、ディスプレイ・モニタ、プリンタ、ストレージなどの他の構成要素から送信された情報を描画する能力をもつ。

本発明の好ましい実施形態の以上の説明は、例示および説明を目的として提示しており、網羅的であること、または本発明を開示した厳密な形式に制限することを意図するものではない。

本発明の好ましい実施形態による、４つの異なる役割を含むロッキングおよびトランザクション管理のための参照モデルを示す構成図である。 本発明の好ましい実施形態による、トランザクション・マネージャのあるロッキング環境を示す図である。 本発明の好ましい実施形態による、トランザクション・マネージャのないロッキング環境を示す図である。 本発明の好ましい実施形態による、ロッキング非対応クライアントのあるロッキング環境を示す図である。 本発明の好ましい実施形態による、カスケーディング・ロッキングを示す図である。 本発明の好ましい実施形態によるストレージの不十分な仮想化システム上でのボリュームの作成を示す図である。 本発明の好ましい実施形態による、ストレージの不十分な仮想化システム上でのボリュームの作成のための一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、ある仮想化システムから別の仮想化システムへのストレージの移動を示す図である。 本発明の好ましい実施形態による、ある仮想化システムから別の仮想化システムへのストレージの移動のための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、ある仮想化システムから別の仮想化システムへのストレージの移動のための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、仮想化システムから論理ボリューム・マネージャへのストレージの移動を示す図である。 本発明の好ましい実施形態による、仮想化システムから論理ボリューム・マネージャへのストレージの移動のための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、仮想化システムから論理ボリューム・マネージャへのストレージの移動のための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、論理ボリュームの作成、および複数のソースからのその論理ボリュームのプロヴィジョンを示す図である。 本発明の好ましい実施形態による、論理ボリュームの作成、および複数のソースからのその論理ボリュームのプロヴィジョンのための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、論理ボリュームの作成、および複数のソースからのその論理ボリュームのプロヴィジョンのための隔離性レベルのロッキングの下で行う一連の動作におけるロッキングのステップおよび主要なクライアント動作要求の表である。 本発明の好ましい実施形態による、ロックおよびトランザクション管理（ＬＴＭ、lockand transaction management）システムにおいてロックを処理するために実装する論理を示す図である。 本発明の好ましい実施形態による、ロック・マネージャの実装する論理を示す図である。 本発明の好ましい実施形態による、トランザクション・マネージャの実装する論理を示す図である。 本発明の好ましい実施形態による、ある資源をロックするのにどの操作識別子を使用すべきかを決定するときにカスケーディング・エージェントの実行する論理を示す図である。 本発明の好ましい実施形態による、ある資源をロックするのにどの操作識別子を使用すべきかを決定するときに、カスケーディング・エージェントの実行する論理を示す図である。 本発明の好ましい実施形態による、第１のエージェントが、第２のエージェントの制御する資源をロックし、第２のエージェントが、その資源をロックする別の要求を受け取るときに、カスケーディング・エージェントの実行する論理を示す図である。 本発明の好ましい実施形態による、第１のエージェントが、第２のエージェントの制御する資源をロックし、第２のエージェントが、その資源をロックする別の要求を受け取るときに、カスケーディング・エージェントの実行する論理を示す図である。 本発明の好ましい実施形態による、クライアントによるロッキングの異なるレベルを可能にするロック・マネージャの実装する論理を示す図である。 本発明の好ましい実施形態による、あるエージェントの実装する論理を示す図である。 本発明の好ましい実施形態による、デッドロックを解決するためにロック・マネージャ内に実装する論理を示す図である。 本発明の好ましい実施形態によるロッキング対応クライアント、トランザクション管理サーバ、ロック管理サーバ、およびロック管理エージェントのアーキテクチャを示す図である。

Claims (12)

1. クライアント・アプリケーションに対して第１エージェント及び第２エージェントがカスケードされており前記第１エージェントが前記第２エージェントに対するクライアントとして働くシステムにおける資源をロックする方法であって、
   （ｉ）前記第１エージェントが、第１操作識別子に関連づけられているクライアント・アプリケーションが前記第１エージェントの制御のもとにある資源をロックするための前記クライアント・アプリケーションからの第１ロック要求を受け取るステップと、
   （ｉｉ）前記第１エージェントが、該第１エージェントの制御のもとにある前記資源のロックを前記第１操作識別子によって行うステップと、
   （ｉｉｉ）前記第１エージェントが、前記第２エージェントの制御のもとにある追加の資源のロックを、前記クライアント・アプリケーションからの第１ロック要求を処理するために前記第１操作識別子によって行うかどうかの判定を、前記第２エージェント上で行うべき操作が前記クライアント・アプリケーションからの第１ロック要求が完了するときまでに完了しなければならないかどうかに基いて行う判定ステップと、
   （ｉｖ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックするステップと、
   （ｖ）前記追加の資源を前記第１操作識別子によってロックすべきでないと判定されたことに応答して、前記第１のエージェントが第２操作識別子を取得するステップと、
   （ｖｉ）前記第２エージェントが、該第２エージェントの制御のもとにある前記追加の資源を前記第２操作識別子によりロックするステップとを含む方法。
2. 前記ステップ（ｉｖ）が、
   （イ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第１エージェントが、前記追加の資源を前記第１操作識別子によってロックするために第２ロック要求を前記第２エージェントのロック・マネージャに送るステップと、
   （ロ）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定するステップと、
   （ハ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求を前記第２エージェントに渡すステップと、
   （ニ）前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックするステップと、
   （ホ）前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求をキューイングするステップとを行う、請求項１に記載の方法。
3. 前記ステップ（ｖ）と前記ステップ（ｖｉ）との間に、
   （ヘ）前記第１エージェントが、前記追加の資源を前記第２操作識別子によってロックするために第３ロック要求を前記第２エージェントのロック・マネージャに送るステップと、
   （ト）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定するステップと、
   （チ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求を前記第２エージェントに渡すステップとを行い、そして
   （リ）前記ステップ（ト）において前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求をキューイングするステップとを行う、請求項１に記載の方法。
4. 前記キューイングするステップの次に、前記キューイングを管理するロック・マネージャが、
   （ａ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあるかどうかを判定するステップと、
   （ｂ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあることに応答して、前記ロック要求を再発行するステップと、
   （ｃ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたどうかを判定するステップと、
   （ｄ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたことに応答して、前記ロック要求を前記ロック・キューから取り除くステップと、
   （ｅ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にないことに応答して、前記ロック・キュー・タイムアウト期間が時間切れになっているかどうかを判定するステップと、
   （ｆ）前記ロック・キュー・タイムアウト期間が時間切れになっていることに応答して、前記ロック要求を拒否し、前記ロック・キュー・タイムアウト期間が時間切れになっていないことに応答して、前記ステップ（ａ）に戻るステップとを行う、請求項２又は請求項３に記載の方法。
5. クライアント・アプリケーションに対して第１エージェント及び第２エージェントがカスケードされており前記第１エージェントが前記第２エージェントに対するクライアントとして働くシステムにおける資源をロックするプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
   コンピュータに、
   （ｉ）前記第１エージェントが、第１操作識別子に関連づけられているクライアント・アプリケーションが前記第１エージェントの制御のもとにある資源をロックするための前記クライアント・アプリケーションからの第１ロック要求を受け取る手順と、
   （ｉｉ）前記第１エージェントが、該第１エージェントの制御のもとにある前記資源のロックを前記第１操作識別子によって行う手順と、
   （ｉｉｉ）前記第１エージェントが、前記第２エージェントの制御のもとにある追加の資源のロックを、前記クライアント・アプリケーションからの第１ロック要求を処理するために前記第１操作識別子によって行うかどうかの判定を、前記第２エージェント上で行うべき操作が前記クライアント・アプリケーションからの第１ロック要求が完了するときまでに完了しなければならないかどうかに基いて行う判定手順と、
   （ｉｖ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックする手順と、
   （ｖ）前記追加の資源を前記第１操作識別子によってロックすべきでないと判定されたことに応答して、前記第１のエージェントが第２操作識別子を取得する手順と、
   （ｖｉ）前記第２エージェントが、該第２エージェントの制御のもとにある前記追加の資源を前記第２操作識別子によりロックする手順とを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
6. 前記手順（ｉｖ）が、
   （イ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第１エージェントが、前記追加の資源を前記第１操作識別子によってロックするために第２ロック要求を前記第２エージェントのロック・マネージャに送る手順と、
   （ロ）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定する手順と、
   （ハ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求を前記第２エージェントに渡す手順と、
   （ニ）前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックする手順と、
   （ホ）前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求をキューイングする手順とを行う、請求項５に記載のコンピュータ読み取り可能な記録媒体。
7. 前記手順（ｖ）と前記手順（ｖｉ）との間に、
   （ヘ）前記第１エージェントが、前記追加の資源を前記第２操作識別子によってロックするために第３ロック要求を前記第２エージェントのロック・マネージャに送る手順と、
   （ト）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定する手順と、
   （チ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求を前記第２エージェントに渡す手順とを行い、そして
   （リ）前記手順（ト）において前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求をキューイングする手順を行う、請求項５に記載のコンピュータ読み取り可能な記録媒体。
8. 前記キューイングする手順の次に、前記キューイングを管理するロック・マネージャが、
   （ａ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあるかどうかを判定する手順と、
   （ｂ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあることに応答して、前記ロック要求を再発行する手順と、
   （ｃ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたどうかを判定する手順と、
   （ｄ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたことに応答して、前記ロック要求を前記ロック・キューから取り除く手順と、
   （ｅ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にないことに応答して、前記ロック・キュー・タイムアウト期間が時間切れになっているかどうかを判定する手順と、
   （ｆ）前記ロック・キュー・タイムアウト期間が時間切れになっていることに応答して、前記ロック要求を拒否し、前記ロック・キュー・タイムアウト期間が時間切れになっていないことに応答して、前記ステップ（ａ）に戻る手順とを行う、請求項６又は請求項７に記載のコンピュータ読み取り可能な記録媒体。
9. クライアント・アプリケーションに対して第１エージェント及び第２エージェントがカスケードされており前記第１エージェントが前記第２エージェントに対するクライアントとして働くシステムであって、
   （ｉ）前記第１エージェントが、第１操作識別子に関連づけられているクライアント・アプリケーションが前記第１エージェントの制御のもとにある資源をロックするための前記クライアント・アプリケーションからの第１ロック要求を受け取り、
   （ｉｉ）前記第１エージェントが、該第１エージェントの制御のもとにある前記資源のロックを前記第１操作識別子によって行い、
   （ｉｉｉ）前記第１エージェントが、前記第２エージェントの制御のもとにある追加の資源のロックを、前記クライアント・アプリケーションからの第１ロック要求を処理するために前記第１操作識別子によって行うかどうかの判定を、前記第２エージェント上で行うべき操作が前記クライアント・アプリケーションからの第１ロック要求が完了するときまでに完了しなければならないかどうかに基いて行い、
   （ｉｖ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックし、
   （ｖ）前記追加の資源を前記第１操作識別子によってロックすべきでないと判定されたことに応答して、前記第１のエージェントが第２操作識別子を取得し、
   （ｖｉ）前記第２エージェントが、該第２エージェントの制御のもとにある前記追加の資源を前記第２操作識別子によりロックする、システム。
10. （イ）前記追加の資源を前記第１操作識別子によってロックすべきであると判定されたことに応答して、前記第１エージェントが、前記追加の資源を前記第１操作識別子によってロックするために第２ロック要求を前記第２エージェントのロック・マネージャに送り、
    （ロ）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定し、
    （ハ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求を前記第２エージェントに渡し、
    （ニ）前記第２エージェントが該第２エージェントの制御のもとにある前記追加の資源を前記第１操作識別子によりロックし、
    （ホ）前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第２ロック要求をキューイングする、請求項９に記載のシステム。
11. （ヘ）前記第１エージェントが、前記追加の資源を前記第２操作識別子によってロックするために第３ロック要求を前記第２エージェントのロック・マネージャに送り、
    （ト）前記第２エージェントのロック・マネージャが、ロックの衝突があるかどうかを判定し、
    （チ）前記ロックの衝突がないことに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求を前記第２エージェントに渡し、そして
    （リ）前記（ト）において前記ロックの衝突があることに応答して、前記第２エージェントのロック・マネージャが、前記第３ロック要求をキューイングする、請求項９に記載のシステム。
12. 前記キューイングを管理するロック・マネージャが、
    （ａ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあるかどうかを判定し、
    （ｂ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にあることに応答して、前記ロック要求を再発行し、
    （ｃ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたどうかを判定し、
    （ｄ）前記ロック要求の許可が前記ロック・キュー・タイムアウト期間内に行われたことに応答して、前記ロック要求を前記ロック・キューから取り除き、
    （ｅ）前記ロック要求がロック・キューのタイムアウト期間内に前記ロック・キューの先頭にないことに応答して、前記ロック・キュー・タイムアウト期間が時間切れになっているかどうかを判定し、
    （ｆ）前記ロック・キュー・タイムアウト期間が時間切れになっていることに応答して、前記ロック要求を拒否し、前記ロック・キュー・タイムアウト期間が時間切れになっていないことに応答して、前記（ａ）の動作に戻る、請求項１０又は請求項１１に記載のシステム。

Images