(57)【要約】  クライアントは、クライアントサーバシステムに直接接続することを許可される。Ｏｐｌｏｇマネジメントシステムは、クライアントが直接接続クライアントサーバシステムのコントロール構造体を変更すると、変更を追跡する。Ｏｐｌｏｇｇｉｎｇシステムはｏｐｌｏｇに変更を格納する。そこで、クライアントが障害を起こした場合、Ｏｐｌｏｇｇｉｎｇシステムは、規定された原理に依って、クライアントによってなされた変更を取り消すことにより、あるいはクライアントに代わって変更を完了することにより、コントロール構造体を修復することができる。
2008517374.tif 000002
【特許請求の範囲】
【請求項１】
第１のクライアントと第２のクライアントとによる同時アクセスをサポートするシステムであって、前記第１のクライアントと前記第２のクライアントは、前記システムに直接接続されており、
前記第１のクライアントによるシステムのコントロール構造体における変更についての情報を格納するｏｐｌｏｇを生成するｏｐｌｏｇ生成部と、
前記第１のクライアントが前記変更を完了する前に障害を起こした場合、前記システムの前記コントロール構造体を修復するｏｐｌｏｇクリーナープロセスと、
を備える、コンピュータベースの装置。
【請求項２】
ｏｐｌｏｇに格納される前記情報は、ｏｐｌｏｇクリーナープロセスが前記コントロール構造体における前記変更を取り消すことを可能にする情報を含む、請求項１に記載のコンピュータベースの装置。
【請求項３】
ｏｐｌｏｇは、
前記第１のクライアントであると識別されるトランザクション識別子と、
前記第１のクライアントによって変更される表を識別する表識別子と、
トランザクション識別子と表識別子と関連するカーソル識別子と、
を含む、請求項２に記載のコンピュータベースの装置。
【請求項４】
ｏｐｌｏｇは、
第１のリスト識別子と、
第２のリスト識別子と、
第１のリストから第２のリストへ移動されるエレメントを識別するエレメント識別子と、
第１のリスト内の次のエレメントを識別する第１の次のエレメント識別子と、
第２のリスト内の次のエレメントを識別する第２の次のエレメント識別子と、
を含む、請求項２に記載のコンピュータベースの装置。
【請求項５】
ｏｐｌｏｇに格納された前記情報は、ｏｐｌｏｇクリーナープロセスが前記コントロール構造体における前記変更を完了することを可能にする情報を含む、請求項１に記載のコンピュータベースの装置。
【請求項６】
ｏｐｌｏｇは、
リスト識別子と、
リスト識別子によって識別されたリストの長さと、
前記リストにおいて繰り返して行われる操作と、
を含む、請求項５に記載のコンピュータベースの装置。
【請求項７】
システムと前記第１のクライアントとの間の接続を監視する接続監視デーモンをさらに備える、請求項１に記載のコンピュータベースの装置。
【請求項８】
接続監視デーモンが前記第１のクライアントの障害を検出した場合、接続監視デーモンがｏｐｌｏｇクリーナープロセスを開始するよう作動する、請求項７に記載のコンピュータベースの装置。
【請求項９】
システムは、データベースシステムである、請求項１に記載のコンピュータベースの装置。
【請求項１０】
データベースは、メモリ内データベースシステムである、請求項９に記載のコンピュータベースの装置。
【請求項１１】
前記第１のクライアントがデータベースに接続する接続ポイントをさらに備える、請求項９に記載のコンピュータベースの装置。
【請求項１２】
第２のクライアントがデータベースに接続する第２接続ポイントをさらに備える、請求項１１に記載のコンピュータベースの装置。
【請求項１３】
クライアントが直接システムに接続することを可能にすることと、
クライアントによってシステムのコントロール構造体になされる変更をログすることと、
クライアントの障害を監視することと、
クライアントが障害を起こした場合、システムの可用性を維持しつつ、システムのコントロール構造体を修復することと、
を備える、システムを用いる方法。
【請求項１４】
前記方法は、第２のクライアントがシステムに直接接続することを可能にすることをさらに備え、
システムのコントロール構造体を修復することは、クライアントが障害を起こした場合に、第２のクライアントをシステムから切断することなくシステムのコントロール構造体を修復することを含む、
請求項１３に記載の方法。
【請求項１５】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
開いたトランザクションのリストを維持することと、
開いたトランザクションのリスト内の開いたトランザクションをそれぞれカーソルと関連づけることと、
各カーソルをシステム内の表と関連づけることであって、表はカーソルに関連づけられた開いたトランザクションの一部として変更されることと、
を含む、請求項１３に記載の方法。
【請求項１６】
システムのコントロール構造体を修復することは、
第１の関連が存在する場合、カーソルと表との間の第１の関連を削除することと、
第２の関連が存在する場合、開いたトランザクションとカーソルとの間の第２の関連を削除することと、
を含む、請求項１５に記載の方法。
【請求項１７】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
クライアントによって変更されるシステムのコントロール構造体におけるリストを識別することと、
クライアントによってリストのエレメントに対して行われる操作を識別することと、
クライアントによってエレメントに対して行われる操作を取り消すための情報を格納することと、
を含む、請求項１３に記載の方法。
【請求項１８】
操作を識別することは、リストに加えられるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項１９】
操作を識別することは、リストから削除されるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項２０】
システムのコントロール構造体を修復することは、
リストにおけるホールとして削除されるエレメントを識別することと、
リストが連続するまでホールを繰り返して移動することと、
を含む、請求項１９に記載の方法。
【請求項２１】
操作を識別することは、リスト内で移動されるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項２２】
システムのコントロール構造体を修復することは、リスト内のエレメントを元の状態に復元することを含む、請求項１７に記載の方法。
【請求項２３】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
クライアントによって変更されるシステムのコントロール構造体におけるリストを識別することと、
クライアントによってリスト内のエレメントに対して行われる操作を識別することと、
操作についての情報を格納することと、
を含む、請求項１３に記載の方法。
【請求項２４】
システムのコントロール構造体を修復することは、
クライアントが操作を行っていないエレメントを識別することと、
エレメントに対して操作を繰り返し行うことと、
を含む、請求項２３に記載の方法。
【請求項２５】
操作を識別することは、クライアントによってリスト内のエレメントに対して行われるホール移動操作を識別することを含み、
操作をエレメントに対して繰り返し行うことは、リストが連続するまで、リスト内のエレメントを越えてホールを繰り返し移動することを含む、
請求項２４に記載の方法。
【請求項２６】
クライアントがシステムに直接接続することを可能にすることは、クライアントがデータベースシステムに直接接続することを可能にすることを含み、
変更をログすることは、クライアントによってデータベースシステムのコントロール構造体になされる変更をログすることを含み、
システムのコントロール構造体を修復することは、データベースシステムの可用性を維持しつつ、データベースシステムのコントロール構造体を修復することを含む、
請求項１３に記載の方法。
【請求項２７】
クライアントがデータベースシステムに直接接続することを可能にすることは、クライアントがメモリ内データベースシステムに直接接続することを可能にすることを含み、
変更をログすることは、クライアントによってメモリ内データベースシステムのコントロール構造体になされる変更をログすることを含み、
システムのコントロール構造体を修復することは、メモリ内データベースシステムの可用性を維持しつつ、メモリ内データベースシステムのコントロール構造体を修復することを含む、
請求項２６に記載の方法。
【請求項２８】
関連するデータを有するマシンアクセス可能な媒体を備える物品であって、前記データがアクセスされると、
クライアントがシステムに直接接続することを可能にすることと、
クライアントによってシステムのコントロール構造体になされる変更をログすることと、
クライアントの障害を監視することと、
クライアントが障害を起こした場合、システムの可用性を維持しつつシステムのコントロール構造体を修復することと、
をマシンが行う物品。
【請求項２９】
マシンアクセス可能なデータは、アクセスされると、第２のクライアントがシステムに直接接続することを可能にする関連するデータをさらに含み、
システムのコントロール構造体を修復することは、クライアントが障害を起こした場合、第２のクライアントをシステムから切断することなく、システムのコントロール構造体を修復することを含む、
請求項２８に記載の物品。
【請求項３０】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
開いたトランザクションのリストを維持することと、
開いたトランザクションのリスト内の開いたトランザクションをそれぞれカーソルに関連づけることと、
各カーソルをシステム内の表に関連づけることであって、表はカーソルに関連づけられた開いたトランザクションの一部として変更されることと、
を含む、請求項２８に記載の物品。
【請求項３１】
システムのコントロール構造体を修復することは、
第１の関連が存在する場合、カーソルと表との間の第１の関連を削除することと、
第２の関連が存在する場合、開いたトランザクションとカーソルとの間の第２の関連を削除することと、
を含む、請求項３０に記載の物品。
【請求項３２】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
クライアントによって変更されるシステムのコントロール構造体におけるリストを識別することと、
クライアントによってリスト内のエレメントに対して行われる操作を識別することと、
クライアントによってエレメントに対して行われる操作を取り消すための情報を格納することと、
を含む、請求項２８に記載の物品。
【請求項３３】
操作を識別することは、リストに加えられるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３４】
操作を識別することは、リストから削除されるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３５】
システムのコントロール構造体を修復することは、
リストにおけるホールとして削除されるエレメントを識別することと、
リストが連続するまでホールを繰り返し移動することと、
を含む、請求項３４に記載の物品。
【請求項３６】
操作を識別することは、リスト内で移動されるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３７】
システムのコントロール構造体を修復することは、リスト内のエレメントを元の状態に復元することを含む、請求項３２に記載の物品。
【請求項３８】
クライアントによってシステムのコントロール構造体になされる変更をログすることは、
クライアントによって変更されるシステムのコントロール構造体のリストを識別することと、
クライアントによってリスト内のエレメントに対して行われる操作を識別することと、
操作についての情報を格納することと、
を含む、請求項２８に記載の物品。
【請求項３９】
システムのコントロール構造体を修復することは、
クライアントが操作を行っていないエレメントを識別することと、
エレメントに対して操作を繰り返し行うことと、
を含む、請求項３８に記載の物品。
【請求項４０】
操作を識別することは、クライアントによってリスト内のエレメントに対して行われるホール動作操作を識別することを含み、
操作をエレメントに対して繰り返し行うことは、リストが連続するまで、リスト内のエレメントを越えてホールを繰り返し移動することを含む、
請求項３９に記載の物品。
【請求項４１】
クライアントがシステムに直接接続することを可能にすることは、クライアントがデータベースシステムに直接接続することを可能にすることを含み、
変更をログすることは、クライアントによってデータベースシステムのコントロール構造体になされる変更をログすることを含み、
システムのコントロール構造体を修復することは、データベースシステムの可用性を維持しつつ、データベースシステムのコントロール構造体を修復することを含む、
請求項２８に記載の物品。
【請求項４２】
クライアントがデータベースシステムに直接接続することを可能にすることは、クライアントがメモリ内データベースシステムに直接接続することを可能にすることを含み、
変更をログすることは、クライアントによってメモリ内データベースシステムのコントロール構造体になされる変更をログすることを含み、
システムのコントロール構造体を修復することは、メモリ内データベースシステムの可用性を維持しつつ、メモリ内データベースシステムのコントロール構造体を修復することを含む、
請求項２８に記載の物品。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、クライアントサーバシステムにおける回復の分野に関する。具体的には、本発明は、クライアントプロセスがサーバプロセスに直接接続するアーキテクチャに関する。より具体的には、本発明は、サーバサブシステムに直接接続する１以上のクライアントプロセスの障害に際し、現在および新規のクライアントに対するサーバサブシステムの可用性を維持する能力に関する。
【背景技術】
【０００２】
発明の背景
コンピュータアプリケーションの一般的なアーキテクチャは、クライアントサーバアーキテクチャである。クライアントサーバアプリケーションは、アプリケーションの機能性がサーバとクライアントにわたって分け合われるコンピュータシステムである。たとえば、クライアントはユーザインタフェイスを提供し、サーバは共有リソースへのアクセスを提供するであろう。一般的に、クライアントおよびサーバは分離されたプロセスとして実行する。クライアントは、サーバプロセスに、自身の代わりにアクションを行うようにリクエストする、すなわち、クライアントはサーバを介して共有リソースにアクセスする。サーバは、共有リソースを管理し、これらのリソースはマネージドデータ（ｍａｎａｇｅｄ  ｄａｔａ）と名づけられるであろう。アクションの実行を容易にするために（クライアントの代わりに）、サーバはコントロールデータを維持し、これらのアクションの実行を管理する必要がある。コントロールデータの実施例は、同時並行性、許可、マネージドデータへのアクセスなどを制御するための情報である。一般的に、コントロールデータは一時的であり、システム開始にあたって再初期化される；しかし、コントロールデータの部分は永続的であることができる。要約すれば、クライアントサーバシステムのサーバによって取り扱われるデータは、２つの部分に分割されるであろう：マネージドデータとコントロールデータである。
【０００３】
クライアントサーバアーキテクチャにおいて用いられるサーバの一般的な実施例は、データベースマネジメントシステム（ＤＢＭＳ）である。データベースはコンピュータに格納されるデータアイテムの集合である‐これらのデータアイテムは、データベースマネジメントシステム（ＤＢＭＳ）設定におけるマネージドデータを構成する。複数のユーザがこれらの（マネージド）データアイテムに、クライアントを介して同時にアクセスするであろう。クライアントの代わりに実行されるアクションは、トランザクションと呼ばれる。トランザクションは、データベースから読み出し、データベースに書き込み（挿入、削除、もしくは更新）、または両方を行い、したがってトランザクションは多数の読みおよび書き操作から作られるであろう。トランザクションは、データアイテムの変更のみならず、ＤＢＭＳが内部に維持して実行を制御し、内在するデータアイテムにアクセスを提供するコントロールデータの変更をもまたもたらす。本発明者は、ＤＢＭＳからの実施例をしばしば提供するであろう。しかし、ここで留意すべきは、ここに提示される発明は広い適用性を有し、ＤＢＭＳはアプリケーションの一実施例に過ぎないことである。
【０００４】
当業者は、アトミック性が、任意のミッションクリティカルクライアントサーバシステムの所望の挙動であることを理解するであろう。アトミック性は、任意のクライアントリクエストが完全に実行され、もしくは全く実行されないという特性、すなわち、クライアントがリクエストしたアクションの全ての影響が他のクライアントに可視であるか、どの影響も不可視であるかということに言及する。アトミック性が非常に所望されるクライア
ントサーバシステムの一実施例は、ＤＢＭＳである。トランザクションの全ての影響が他のトランザクションに可視であるべきか、どの影響も不可視であるべきか（これはトランザクションのＡＣＩＤ（アトミック性、同時並行性、分離性、永続性）特性の部分である）である。クライアントリクエストは、マネージドデータに、意図的な直接影響を有する。しかし、コントロールデータは間接的に変更される。これは、クライアントに代わって実行されるサーバプロセスによって変更される。一般的に、アトミック性の特性は、コントロールデータではなくマネージドデータに関連する。
【０００５】
技術的に、ロギングと回復を介して、マネージドデータにアトミック性を実施するテクニックは、汎用的である。先書きロギング（ＷＡＬ）は、ロギングの既知の実施例である。このスキームにおいて、ログ記録が作成され、マネージドデータになされた変更を追跡する。ログ記録は、マネージドデータの古いコピーを、新しいコピーと同じく含む。これらはまた、クライアントアクションの開始と終了とを記録する。ＷＡＬは、ログ記録が、実際のマネージドデータを持続する前に、ディスクなどの不揮発性の媒体まで持続されることを保証する。したがって、任意の障害の場合、サーバは、所与のクライアントアクションが部分的に完了されたか、完全に完了されたかを決定することを存続するログ記録を用いる。部分的に完了したクライアントアクションの影響は、ログ記録に保存されたマネージドデータの古いコピーを用いることにより取り消され、マネージドデータの状態を、クライアントアクションを開始する前の状態にロールバックする。同様に、ログ記録に保存されたマネージドデータの新しいコピーが用いられて、マネージドデータの状態をロールフォワードして完全に完了したクライアントアクションによって行われた変更を反映する。このようにして、サーバは、マネージドデータにおけるクライアントアクションのアトミック性を、障害に際する場合にも保証する。ロールバックおよびロールフォワードは共に、システムにおけるアトミック性を達成することをサポートする。
【０００６】
アトミック性がマネージドデータについて正確な状態であるのとちょうど同じく、整合性がコントロールデータについての正確な状態である。コントロールデータについての整合性のある状態を、コントロールデータがクライアントアクションによって変更されない任意の状態と規定する。ここで留意すべきは、ロールバックの終了にあたり、コントロールデータは本質的に整合性のある状態にあることである。クライアントアクションが行われた場合、これに限定されるものではないが、アクセスコントロール情報、マネージドデータメタデータ、同時性コントロール情報などを含む、コントロールデータに変更をもたらすであろう。クライアントの障害に際し、コントロールデータは、サーバが、マネージドデータに行われたクライアントアクションの影響を成功理にロールバックできる前に、整合性のある状態にある必要がある。
【０００７】
回復とは、コントロールデータとマネージドデータの両方を正確な状態にするプロセスであると定義する。つまり、回復は、コントロールデータを整合性のある状態にすることと、マネージドデータについてのアトミック性を維持することとを含む。
【０００８】
従来、ＤＢＭＳなどのクライアントサーバシステムにおいて、クライアントリクエストは、クライアントプロセスそのものから分離されてサーバプロセスにおいて実行され、クライアントプロセスは、メッセージなどのプロセス間通信機構を介してサーバに接続する。これらの構成は、間接接続と呼ばれる。このような構成は、クライアントのエラーからの回復力が高い。具体的に、クライアントプロセスが消滅するか終了する場合、サーバはクライアントとの通信の欠如を通じて障害を検出し、障害を起こしたクライアントプロセスに代わって、変更されたであろう任意のコントロールデータを削除し、コントロールデータについて整合性のある状態に達し、障害を起こしたクライアントプロセスの代わりに実行されていた全ての不完全なアクションをロールバックする。従来の間接接続の重大な利益は、クライアントプロセスの障害が、サーバがコントロールデータにもたらす変更を
中断しないことである。したがって、クライアントプロセスの障害は、部分的に変更されたコントロールデータをもたらすことはない。たとえば、コントロールデータにおける一般的な変更は、リンクリストへの挿入であるかもしれない。間接接続では、リンクリストを変更する行為は、変更の途中で中断しない；むしろこれは挿入の前後で中断するであろう。リンクリストを変更する行為が途中で中断しないであろうことは、クライアントが消滅した場合にこれらの不連続のポイントでのみサーバがチェックするためである；クライアントが消滅した場合、サーバはさらなるアクションを取ることができる。基本的に、サーバプロセスは、そうすることが都合の良い場合、すなわちコントロールデータが整合性のある状態にある時、クライアントの障害に作用することが自由である。
【０００９】
クライアントプロセスとサーバプロセスとの間のプロセス間通信が、サーバプロセスをクライアントの障害から隔離する一方、これは著しい動作オーバーヘッドを各クライアントリクエストに加える。このオーバーヘッドは、高性能環境において望ましくなく、とりわけメモリ内ＤＢＭＳについて受け入れられない。メモリ内ＤＢＭＳは、６４ビットプロセッサと安価で充分なメインメモリをフルに活用し、大変高い性能を供給するために設計された、最新技術のＤＢＭＳである。このようなシステムにおいて、データベースの全てのデータアイテムは、ランタイムに、ディスクなどの不揮発性メモリにある代わりに、メインメモリにある。
【００１０】
プロセス間通信のオーバーヘッドを克服する一般的な解決法は、いくつかのサーバ機能について、クライアントアプリケーションとリンクされることができる、実行可能なライブラリとしてパッケージ化されることであり、またクライアントアプリケーションについて、またサーバのその部分について、単一のプロセスで実行することである。この構成を、直接接続と呼び、結合したクライアントアプリケーションおよびサーバライブラリを直接接続クライアントサーバシステムと呼ぶ。一般的に、クライアントサーバアプリケーションに多数のクライアントがあるため、コントロールデータおよびいくつかもしくは全てのマネージドデータを共有メモリセグメントに維持することが一般的である。
【００１１】
このような環境において、クライアントプロセスの障害は、クライアントアクションの実行を中断しうる。このようなクライアント障害の結果は、潜在的に整合性のない状態にあるマネージドデータとコントロールデータの両方を含む。たとえば、コントロールデータのリンクリストを変更するクライアントを再び考慮する。直接接続モデルにおいて、クライアントは、リンクリストを変更する途中に消滅するか終了するかであろう。したがって、リンクリストは循環する状態のままにされ、切断され、もしくはいくつかのその他の整合性のない状態のままにされるであろう。サーバが、整合性のない状態からのロールバックを試行する場合、これは無限のループから抜け出せず、メモリをリークし、クラッシュするかもしれない。したがって、コントロールデータが整合性のない状態にあるかもしれないという事実は、障害のあったクライアントによってマネージドデータに行われた変更をロールバックしようとするサーバに問題を生じる。
【００１２】
直接接続クライアントによるコントロールデータへの変更を扱う問題は、文献でよく認識されている。この問題の１つの解決法は、コントロールデータを変更する途中に、直接接続クライアントプロセスに予期しない障害が起きた時はいつでも、サーバへの全てのクライアント接続が無効であると宣言することである。時々、クリティカルセクションが用いられて、コントロールデータを変更するこのような領域を宣言する。これらの領域は精度の点で変動するであろう；この技術のシンプルな適用は、全てのサーバ実行可能なライブラリがクリティカルセクションであると宣言することである。サーバは、部分的に変更されたコントロールデータを整合性のある状態にすることができず、このスキームは、任意のクライアントがサーバライブラリの中にある時に障害を起こした時に、全てのクライアントが再度接続することを強いる。このことはまた、システムがその回復プロセス（前
に説明されたように、マネージドデータのアトミック性を保証するために用いられる）を経てコントロールデータを再初期化するようにする。この解決法は効果的であるが、実用的ではない。６４のプロセッサおよび、おそらくデータベースへの５０のクライアント接続を有する、大きなＳＭＰマシンを考慮する。任意の単一の予期しない終了は、全てのクライアント接続が切断されることをもたらすであろう。これはとりわけ、メモリ内ＤＢＭＳなどの、間接接続が提供するのと同じ安定性保証を要求する一方で、直接接続クライアントサーバシステムの速度有利性を所望する、ミッションクリティカルなアプリケーションにおいて重大な攻撃である。
【００１３】
これらの問題を扱う他の提案があり、それらは部分的な解決法であった。ＭｏｌｅｓｋｙとＲａｍａｍｒｉｔｈａｍは、ノードの障害に際してもコントロール構造体のコヒーレンスを保証することができる、ハードウェアベースのキャッシュコヒーレンスモデルを提案した。彼らは、ノードを、所与のトランザクションを実行する、プロセス／メモリの対であると規定する。しかしこれらのスキームを実施するには、キャッシュラインをロックするのに特別なハードウェア命令が要求され、正確な識別子でタグをつけるのに、特別なキャッシュライン構造体が必要とされる。これらのハードウェア特性はそこで、データベースへの全ての接続をシャットダウンすることを含まない回復スキームを実施するのに用いられる。プロセスアーキテクチャにおける進展があっても、提案された要求は最新のプロセッサに対応しなかった。したがって、このスキームは今日実施するには実用的ではない。異なるプロセスの間で交わされるメッセージに依る他のスキームが提案された。しかしこれらは、間接接続と同じパフォーマンス欠点を有する。
【００１４】
無効の問題を扱うように変更されることができる他のスキームは、Ｎｅｖｅｓ他によって提案されたチェックポイントプロトコルである。このプロトコルの主要な欠点は、エントリに整合性のある共有メモリシステムを仮定することである。このようなモデルにおいて、共有メモリの全てのアクセスは、保護されると仮定され、多様なアクセス間に依存はない。このモデルは、ＤＢＭＳなどの複雑なシステムについて実用的ではない。ＤＢＭＳにおいて、共有メモリの複数のセグメントが、単一のユニットとして依存する方法で、アクセスされ、更新されるであろう。さらに他の一連のスキームは、Ｇａｎｅｓｈ他によって提案され、障害のあったクライアントから回復するのにかかる時間を短縮した。しかしこれらのスキームはコントロールデータの整合性に達することができない。
【００１５】
したがって、技術を改良して、直接接続クライアントモデルのコントロールデータの整合性を達成することが必要とされる。このようなシステムの実施例は、直接接続クライアントプロセスがＤＢＭＳと同じプロセスで実行する場合であり、とりわけＤＢＭＳがメモリ内ＤＢＭＳである場合である。これらの技術は、全てのハードウェアプラットフォームに広く移植できるべきであり‐すなわち、技術はハードウェアニュートラルであるべきであり‐実用的であり、パフォーマンスもしくは同時並行性を犠牲にすることなく、また大きな記憶装置を必要とすることなく、コントロールデータの整合性を達成すべきである。
【００１６】
上述で、マネージドデータへの変更を追跡するためにロギング技術が用いられ、クライアントアクションのアトミック性を保証することを見た。一般的に、これらの技術はコントロールデータの変更を追跡するのには用いられない。コントロールデータは、普通は一時的であり、サーバがクライアントの代わりに行うアクションの実行を管理することをサポートするために存在する。さらに、従来の間接接続は、システムを、部分的に変更されたコントロールデータを扱わなければならないことから隔離する；したがって、コントロールデータにおいて整合性を達成することは、これらの従来のシステムにおける課題ではない。しかし、直接接続クライアントにとって、マネージドデータについて整合性のある状態に達することは最優先事項であり、そうでなければ全ての実行は終了しなければならない。
【００１７】
マネージドデータについて上述されたスキームと同様に、永続的な記憶装置にコントロールデータへの全ての変更をログすることを提案できるかもしれない。このことは、生成されるであろうログの量からして、はるかに大きな不揮発性の記憶装置を要求するであろう。より重要なことに、遅い不揮発性の記憶装置への頻繁なアクセスのために、このようなシステムはより遅く、システムはディスクバウンドするであろう。したがって、このスキームは実用的ではない。
【発明の開示】
【課題を解決するための手段】
【００１８】
発明の概要
本発明者は、直接接続クライアントサーバシステムのコントロールデータにおける整合性を保証する新しい技術を提案する。本発明者は、従来のデータロギングの原理を、コントロールデータとの関連で用い、障害回復サブシステムの設計に用いられる広い原理を規定する技術を提案する。提案された装置は、クリティカルセクション、ｏｐｌｏｇ、ｏｐｌｏｇ生成部、接続監視プロセス、ｏｐｌｏｇクリーナープロセスから成る。この装置は全体で、Ｏｐｌｏｇｇｉｎｇシステムとして知られる。
【発明を実施するための最良の形態】
【００１９】
詳細な説明
この項の以下の部分で、以下のこれらのコンポーネントを規定し、各コンポーネントを詳細に説明する。Ｏｐｌｏｇｇｉｎｇシステムは以下より成る。
【００２０】
・クリティカルセクション：クリティカルセクションは、直接接続クライアントがコントロールデータを操作する時に、強化障害回復が必要とされるであろうところを、規定する。
【００２１】
・Ｏｐｌｏｇ：障害回復を助けるために、ｏｐｌｏｇとして知られるコントロールデータのログが維持される。
【００２２】
・Ｏｐｌｏｇ生成部：これは、（直接接続クライアントの部分である）サーバライブラリの部分である）。実行する直接接続クライアントは、クリティカルセクション内で実行する時、ｏｐｌｏｇ生成部を用いて、ｏｐｌｏｇを維持する。
【００２３】
・接続監視システム：サーバにおけるプロセスは、直接接続クライアントの健全性を監視する。直接接続クライアントの障害の時に、接続監視プロセスは、障害のあったクライアントの影響を取り消す、１以上のｏｐｌｏｇクリーナープロセス（以下に規定される）を開始する。
【００２４】
・Ｏｐｌｏｇクリーナープロセス：このプロセスは、障害のあったクライアントについてのｏｐｌｏｇを読み、コントロールデータを修復して、マネージドデータにロールバックをコールする。
【００２５】
クリティカルセクションの概念は、Ｏｐｌｏｇｇｉｎｇシステムの中核を成す。クリティカルセクションは、直接接続クライアントの消滅や予期しない終了が、コントロールデータを整合性のない状態に放置するであろう、サーバライブラリの一部である。前述において、コントロールデータについての整合性のある状態を、そこからロールバックがマネージドデータに行われることのできる状態であると、規定された。したがって、各クリティカルセクションは、サーバが、直接接続クライアントによって実行されていた未完了のアクションを調査し、修復アクションを取ってコントロールデータについて整合性のある
状態に達することができることを保証するため、保護を必要とする；そしてその後、アトミック性を保証するべく、マネージドデータにロールバックを行う。ここで留意すべきは、クリティカルセクションは通常、同期プリミティブによって保護される共有データを変更することである。しかし、同期プリミティブは常に必要とはされない。クリティカルセクションは、どの同時アクセスにもさらされないであろう、接続固有の情報への変更から成るであろう。しかしこの文書における議論について、クリティカルセクションが同期プリミティブによって保護されるという一般条件を前提とする。ここで留意すべきは、複雑なシステムにおけるクリティカルセクションが、同期プリミティブによって保護される複数の共有データ構造体にアクセスするであろうため、大きいであろうことである。したがって、アプリケーションがどこにあったか、またコントロールデータを整合性のある状態にするためにどの修復アクションが用いられることができるかを、サーバが正確に理解することをサポートするために、高機能のスキームが要求される。
【００２６】
各クリティカルセクションについて、ｏｐｌｏｇを規定する。ｏｐｌｏｇは、既知のロギングスキームの、マネージドデータにおけるコントロール構造体への適応である。しかし、マネージドデータの従来のログと異なり、本発明の実施形態についてのｏｐｌｏｇの設計は、それが保護するクリティカルセクションの構造体に、密接に結びついている。シンプルなクリティカルセクションは、フィールド「Ａ」と識別されるデータフィールドを有し、コントロールデータを保護する同期プリミティブを有するかも知れず、有しないかも知れない。先に言及されたように、この議論のために、クリティカルセクションが常にコントロールデータを保護する同期プリミティブを有するであろうことを前提とする。クリティカルセクションと共に用いるｏｐｌｏｇは、少なくとも２つの構造体を有する‐非アクティブに、もしくはｏｐｌｏｇが関連するクリティカルセクションを識別するように設定されたＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤフィールドと、実行がクリティカルセクションにある場合に識別するＳｔｅｐＮｕｍｂｅｒフィールドである。クリティカルセクションに特有の、より多くのフィールドがあるであろう。たとえば、検討中のシンプルなｏｐｌｏｇは、フィールドＡの古い値を格納する他のフィールドを有することができる。このシンプルな場合において、クリティカルセクションは、同期プリミティブを取得した時に開始し、同期プリミティブが解除された時に終了する。このクリティカルセクションにおいて、同期プリミティブはフィールドＡに取得され、そこでフィールドＡにおける値がインクリメントされ、最後にフィールドＡの同期プリミティブが解除される。
【００２７】
図７は、このコントロール構造体および関連するｏｐｌｏｇの実施例を示す。ｏｐｌｏｇは、クライアント接続がクリティカルセクションにあるときは常に、コントロールデータ状態を反映する必要がある。ここで、シンプルなクリティカルセクションについてｏｐｌｏｇが通過する状態を詳述する。初期状態において、ｏｐｌｏｇは非アクティブであり、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが非アクティブに設定されるであろう。この時点で、ｏｐｌｏｇに情報はなく、このようなｏｐｌｏｇはｏｐｌｏｇクリーナープロセスによって処理されないであろう。同期プリミティブが取得される前に、ｏｐｌｏｇのＳｔｅｐＮｕｍｂｅｒが０に設定され、そこでＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが、実施例においては６５である現在のクリティカルセクション識別子に設定されるであろう。コントロールプリミティブを取得した後で、しかしフィールドＡの値が変更される（実施例においてはインクリメントされる）前に、ｏｐｌｏｇはまず、実施例においては５５であるＯｌｄＶａｌｕｅにおけるＡの現在値を格納するであろう；そしてＳｔｅｐＮｕｍｂｅｒを１に設定するであろう。フィールドＡの値がインクリメントされた後、そのイベントは、ＳｔｅｐＮｕｍｂｅｒを２に変更することによりｏｐｌｏｇに示される。その後、クリティカルセクションは同期プリミティブを解除し、終了する。ｏｐｌｏｇは、そのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤを非アクティブに設定することにより削除される。
【００２８】
より複雑なクリティカルセクションについて、ｏｐｌｏｇは対応してより複雑になるこ
とができる。Ｏｐｌｏｇｇｉｎｇについての明確なステップは、同期プリミティブの取得の後で、同期プリミティブの解除の前である。値は、フィールドの変更の前に、しかし同期プリミティブが取得された後に、記録される。このようなクリティカルセクションの実施例は、異なる同期プリミティブの下にあるが、同じクリティカルセクションの部分である２つの値が変更され、１つの論理演算を形成した時である。２つのコントロールデータフィールドＡおよびＢをカバーするクリティカルセクションを考える。それぞれ異なる同期プリミティブの下にある、フィールドＡがまず、次にフィールドＢが、変更される。この実施例において、クリティカルセクションはフィールドＡの同期プリミティブを取得し、フィールドＡにおける値をインクリメントし、そしてフィールドＡの同期プリミティブを解除するであろう。クリティカルセクションはそこで、フィールドＢの同期プリミティブを取得し、フィールドＢにおける値をＡにおいて見つけた値によってインクリメントするであろう。
【００２９】
図８は、このより複雑なクリティカルセクションの実施例を示す。このオペレーションについての関連するｏｐｌｏｇは、必要とされるフィールドＳｔｅｐＮｕｍｂｅｒおよびＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤから成る。２つのさらなるフィールドが用いられてフィールドＡおよびＢの値：ＯｌｄＶａｌｕｅＡおよびＯｌｄＶａｌｕｅＢ、を格納する。ここで留意すべきは、フィールドＡとフィールドＢが既知の位置にない場合、２つのさらなるフィールドが用いられて、フィールドＡとＢの位置を格納できることである。さらに、フィールドＡとＢの同期プリミティブが既知の位置にない場合、２つのさらなるフィールドが用いられて、これらの同期プリミティブの位置を格納することができる。この実施例において、フィールドＡとＢおよびそれらの同期プリミティブが既知の位置にあることを前提とする。
【００３０】
対応するｏｐｌｏｇが、コントロールデータが通過する全ての遷移を反映するため、ｏｐｌｏｇは７状態を通過するであろう。クリティカルセクションの開始の前に、ｏｐｌｏｇは非アクティブ状態であろう、すなわちそのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩｄフィールドが非アクティブに設定されるであろう。しかし、Ａの同期プリミティブの取得の前に、ＳｔｅｐＮｕｍｂｅｒが０に設定され、ｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤは１２０に設定され、これはクリティカルセクションを一意的に識別する。フィールドＡの同期プリミティブが取得された後、しかしフィールドＡにおける値が変更される前に、ｏｐｌｏｇはフィールドＡの現在値をＯｌｄＶａｌｕｅＡに格納する：この場合は３である；そしてＳｔｅｐＮｕｍｂｅｒが１に設定される。一旦フィールドＡにおける値が変更される（この場合は３から４にインクリメントされる）と、ｏｐｌｏｇのＳｔｅｐＮｕｍｂｅｒは２に変更する。その後、フィールドＡの同期プリミティブが解除され、フィールドＢの同期プリミティブが取得される。ｏｐｌｏｇは、同期プリミティブにおけるこの変更を、この実施例においては８９であるフィールドＢの前回の値を格納することにより反映し、そのＳｔｅｐＮｕｍｂｅｒを３に変更する。フィールドＢにおける値が変更された後、ＳｔｅｐＮｕｍｂｅｒは４に変更される。その後、フィールドＢについての同期プリミティブが解除される。クリティカルセクションがその後終了するので、ｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤフィールドは削除される（すなわち非アクティブに設定される）。
【００３１】
Ｏｐｌｏｇについての重要な考慮は、クライアントのアクションがｏｐｌｏｇを整合性のない状態のままにするか否かである。ｏｐｌｏｇが整合性のない状態のままにされた場合、この項に前述され、後でより詳細に論じられるｏｐｌｏｇクリーナープロセスが、整合性のないコントロールデータについて前に説明された同じ問題に遭遇するかも知れない。これを避けるべく、ｏｐｌｏｇは１以上のイネイブラフラグを有する。上に詳述されたｏｐｌｏｇの実施例について、ＳｔｅｐＮｕｍｂｅｒおよびＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤのフィールドはフラグの役割を果たす。これらの２つのフィールドは、ｏｐｌｏ
ｇクリーナープロセスが整合性のない状態のｏｐｌｏｇを見つけるであろうことを保証するよう用いられる。初めは、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤは非アクティブであり、コントロールデータが変更されていないことを示す。そこでＳｔｅｐＮｕｍｂｅｒフィールドが０に設定され、その時になってＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤがクリティカルセクションの対応する識別子に設定される。ここで留意すべきは、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが設定される時までに、ＳｔｅｐＮｕｍｂｅｒが既に０に設定されるため、このようなｏｐｌｏｇは整合性があることである。ｏｐｌｏｇクリーナープロセスがこの段階においてこのｏｐｌｏｇに影響しなければならないならば、これは、対応する同期プリミティブが、もし保持される場合に、解除されることを保証しようと試みるだけであろう。ｏｐｌｏｇクリーナープロセスは、コントロールデータにおける何の値も変更しないであろう。その後ｏｐｌｏｇは、ＳｔｅｐＮｕｍｂｅｒを進める前に、全ての必要な値を格納する。ｏｐｌｏｇは常に、所与のＳｔｅｐＮｕｍｂｅｒについて必要なデータを有する。このことは、ｏｐｌｏｇクリーナープロセスが、整合性のある状態にあるｏｐｌｏｇを調査し、したがってコントロールデータを整合性のある状態に進めることができることを保証する。ここで留意すべきは、所与のクライアントリクエストについて、重なるクリティカルセクションはないということである。本質的に、重なる多数の「クリティカルセクション」は全て、所与のクライアントリクエストについて実行されなければならず、１つのクリティカルセクションである。しかし、ネスト化したクリティカルセクションを考慮する。
【００３２】
ネスト化したクリティカルセクションの実施例は、図９に示される。クリティカルセクション１および２があるとする。クリティカルセクション１において、フィールドＡの第１の同期プリミティブが取得される。しかし、フィールドＡにおける値を変更する前に、関数呼び出しが行われる。関数呼び出しにおいて、フィールドＢの同期プリミティブを取得する他のクリティカルセクション２が存在し、フィールドＢにおける値を変更し、同期プリミティブを解除し、そして戻る。戻った後、クリティカルセクション１において、フィールドＡにおける値に変更がなされ、そしてＡの同期プリミティブが解除される。理論的には、全てのネスト化されたクリティカルセクションは１つのクリティカルセクションである。しかし、異なる関数呼び出しの組み合わせは、整合性のあるクリティカルセクションの組み合わせである、多くの異なるクリティカルセクションを引き起こすであろう。このスキームは、ネスト化したクリティカルセクションを考慮する、なぜならこれは良いソフトウェアシステム設計についてより実用的であるからである。
【００３３】
このアプローチの１つの結果は、同時に開く複数のｏｐｌｏｇ（クリティカルセクションの各インスタンスに対応する）があるであろうことである。このシステムの動作は、最も新しい（ネスト化レベルにおいては最も深い）ｏｐｌｏｇが、１レベル上がる前に、まずｏｐｌｏｇクリーナープロセスによって削除される必要があるであろうことである。ここで留意すべきは、ｏｐｌｏｇのネスト化深さは特定のアプリケーションに依り、それが何であるべきかに理論的制限はないということである。しかし、ｏｐｌｏｇのネスト化深さを最小化するシンプルなヒューリスティックがある。長く複雑なクライアントアクションは、より小さなアクションに分解されるべきであり、それらの関連するｏｐｌｏｇは、マネージドデータへの任意の影響をロールバックする前に、ロールバックプロセスがコントロールデータを削除するために用いることができる、既知の場所に格納される。クライアントアクションがより小さい場合、対応するクリティカルセクションはより複雑でなく小さい傾向があり、全体的なネスト化深さの全体は同じく小さいであろう。他のヒューリスティックは、長いクライアントアクションを一連のより小さなクライアントアクションに分解することである；そこでクリティカルセクションもまた小さくなる。
【００３４】
Ｏｐｌｏｇｇｉｎｇシステムの設計における目的の１つは、必要メモリが低くあるべきであることであると述べた。ここで留意すべきは、ｏｐｌｏｇは、コントロールデータの
状態と、特定の実行があるステップとを格納することである。プロセスの終了の時、この情報は、いくつかのクリーンアッププロセスにとって利用可能である必要がある（ｏｐｌｏｇクリーナープロセスを参照して上述したように）。ｏｐｌｏｇは固定記憶域にログされることができ、ここではこれらはｏｐｌｏｇクリーナープロセスによってピックアップされて、コントロールデータの整合性を達成することができる。しかし、過度のディスク書き込みおよび読み出しは、容認できないパフォーマンスの不利益を有するかもしれない。代替案は、全てのｏｐｌｏｇをディスクの代わりにメインメモリに格納することであろう。この設計は、パフォーマンスの問題を回避する。しかし、ｏｐｌｏｇが、ＷＡＬスキームの下の従来のログが格納されるように、連続的に格納され、チェックポイントのみで消去される場合、これは過度の必要スペースを招き、したがって実用的ではない。
【００３５】
パフォーマンスの不利益と、過度の必要スペースとを回避するべく、本発明の一実施形態において、ｏｐｌｏｇはメインメモリのスタックに格納される。スタックは技術的に既知の格納構造であり、ここでは最も新しい存在が上にあり、最も古い存在が下にある。この設計において、必要スペースはｏｐｌｏｇのネスト化のレベルに等しい。また、この設計において、非アクティブのログが、存在しないｏｐｌｏｇに等しいことを前提とする。この前提は、何ら新しい要件をもたらすものではなく、事実、ｏｐｌｏｇの設計からすると、非アクティブのｏｐｌｏｇには何らのアクションも取られず、したがってこれは存在しないようなものである。したがって、各接続について、システムが生成する可能性がある最も深いｏｐｌｏｇスタックを保持するのに充分なスペースが割り当てられる。初めは、スタックにはデータがない。ｏｐｌｏｇが必要とされる度に、これはスタックから割り当てられる。割り当てに際してｏｐｌｏｇは非アクティブである。一旦クリティカルセクションが終了して、ｏｐｌｏｇがもはや必要とされなくなると、これは非アクティブとしてマークされ、ｏｐｌｏｇスタックに確保されたスペースに戻る。
【００３６】
他の重要な部分は、ｏｐｌｏｇクリーニング機構である。直接接続クライアントの所与の環境においてさえ、いくつかのプロセスは、どのクライアントからも分離して実行され、保守タスクを行う。クライアント接続を監視するこのような分離したプロセスの１つは、接続監視デーモンである。直接接続クライアントプロセスの予期しないクライアントの消滅もしくは終了に際し、接続監視デーモンはクライアントプロセスの終了を検出し、回復を開始する。直接接続クライアント終了についての回復は、２つの部分から成る：コントロールデータを整合性のある状態にすることと、アトミック性を達成するためのマネージドデータのロールバックである。まず、接続監視デーモンが、サーバに１つの接続を有する単一のクライアントの予期しない障害を回復する方法を詳述する。そして、サーバへの複数の接続を有する複数のクライアントの問題を取り扱う必要のある設計を説明するであろう。
【００３７】
一実施形態において、マネージドデータに影響する前に、（直接接続クライアントサーバシステムにおける）直接接続クライアントは、接続監視デーモンが接続を許可することをリクエストする。接続監視デーモンがそこで、この直接接続クライアントについての情報を格納することができる。一実施形態において、既知のオペレーティングシステム設定であるソケットが用いられ、接続監視デーモンが直接接続クライアントの健全性を監視することができることを保証する。成功理に接続を確立すると、クライアントと接続監視デーモンとの間でソケットが開かれる。そこで、接続プロセスデーモンが、ソケットが予想外に閉じられことを発見した時、これによって、クライアントプロセスの予期しない終了が検出される。接続監視デーモンが、クライアントが予想外に終了したと決定する時、これはｏｐｌｏｇクリーナープロセスを呼び出す。ｏｐｌｏｇクリーナープロセスは呼び出されると、所与の接続についてアクティブである全てのｏｐｌｏｇを調査する（ｏｐｌｏｇそのものは、共有メモリに格納され、前に説明されたように、整合性のある状態である）。
【００３８】
ここで、図７から８で上述されたｏｐｌｏｇについての実施例を用いて、ｏｐｌｏｇクリーナーが取るアクションを詳述する。図７のｏｐｌｏｇについて、ｏｐｌｏｇクリーナーは、ｏｐｌｏｇがまだアクティブであるか否かを決定する。上述のように、ｏｐｌｏｇは、クリティカルセクションの前と後で非アクティブである。しかし、ＳｔｅｐＮｕｍｂｅｒ０、１および２に対応するｏｐｌｏｇについての３つの状態がある。ＳｔｅｐＮｕｍｂｅｒ  ０において、コントロールデータに何ら変更はなされなかった。したがって、ｏｐｌｏｇクリーナーは、同期プリミティブが保持されている場合、これを解除しようと試みるのみである。ＳｔｅｐＮｕｍｂｅｒが１の場合、ｏｐｌｏｇクリーナーは、ｏｐｌｏｇに記録された前回の値（ＯｌｄＶｌｕｅ）をフィールドＡに再インストールする。ＳｔｅｐＮｕｍｂｅｒが２の場合、コントロールデータは整合性があると考えられるため、ｏｐｌｏｇクリーナーは削除を行わない。しかし、クライアントアクションは同期プリミティブを解除していなかったかもしれない。クリーナーは、関連する同期プリミティブが解除されていない場合、これを解除するであろう。その後、ロールバックがこの接続に呼び出され、マネージドデータのアトミック性を保証するであろう。ロールバックの前に、ｏｐｌｏｇクリーナープロセスは、アクティブであることがわかったｏｐｌｏｇに関する全ての同期プリミティブが解除されることを保証する。また、所与の接続によって保持される任意の同期プリミティブがロールバックの終了に際して解除される。
【００３９】
図８の複雑なｏｐｌｏｇは、対応して複雑なｏｐｌｏｇクリーナーを有する。ここで留意すべきは、この実施例には７つの状態と２つの同期プリミティブがあることである。まず、ｏｐｌｏｇクリーナープロセスは、クライアントアクションが終了したＳｔｅｐＮｕｍｂｅｒに注目する。ｏｐｌｏｇがＳｔｅｐＮｕｍｂｅｒ  ０または４にある場合、コントロールデータには何のアクションも必要とされない。ＳｔｅｐＮｕｍｂｅｒ  １において、ｏｐｌｏｇクリーナープロセスは、フィールドＡについての古い値をＯｌｄＶａｌｕｅ  Ａから再インストールする。ＳｔｅｐＮｕｍｂｅｒ  ２について、ｏｐｌｏｇクリーナープロセスは、フィールドＡについて、同期プリミティブが保持されている場合、これを解除し、アクションの残りを実行する：すなわち、フィールドＢにおける値を変更する。ＳｔｅｐＮｕｍｂｅｒ  ３について、ｏｐｌｏｇクリーナープロセスは、フィールドＢに古い値をＯｌｄＶａｌｕｅＢから再インストールし、フィールドＢの値を変更するアクションの残りを実行する。各ステップの終了時に、ｏｐｌｏｇクリーナープロセスは、フィールドＡとフィールドＢの両方について、いずれかがまだ保持されている場合、同期プリミティブを解除する。ここで留意すべきは、第２、第３のステップについての修復アクションは上述よりもさらに複雑であろうことである。修復アクションは、ｏｐｌｏｇクリーニングの終了にあたって初期化されるであろうマネージドデータについて、ロールバックの構造体に依るであろう。ロールバックが、クライアントアクションについてのクリティカルセクションが完了されることを必要とする場合、ｏｐｌｏｇクリーナープロセスは上述のステップを行う。さもなければ、ｏｐｌｏｇクリーナープロセスは、単にフィールドＡとフィールドＢについての値の変更をロールバックすることを選択することができる。たとえば、フィールドＡにおける変更がインクリメントであった場合、ｏｐｌｏｇクリーナープロセスは、ＳｔｅｐＮｕｍｂｅｒフィールドの値が２である後にデクリメントしてＡを復元することができる。最後に、この接続にロールバックが呼び出されて、マネージドデータのアトミック性を保証するであろう。
【００４０】
マルチクライアントシステムにおいて、サーバへのいくつかの接続を有する多くのクライアントが、同時に予期しない障害を起こすであろう。所与のクライアントが、他の接続されたクライアントと同時に実行するため、任意の所与のクライアントは同期プリミティブを保持して消滅するかもしれず、このことは新規の、もしくは現在接続しているクライアントの実行をブロックするか、予期しない障害を起こした他のクライアントの回復をブロックするか、である。したがって、全てのコントロールデータが整合性のある状態にさ
れることと、またマネージドデータのロールバックが、予期しない障害を起こした全てのクライアントについて成功理に終了することとを保証し、同時に、全ての既に接続した、および新規のクライアントが進展することを保証する、特別な取り扱いが要求される。
【００４１】
この時点で、共通のタイプの同期プリミティブについてコメントが必要とされる。２つの共通の種類の同期プリミティブがある‐アプリケーションロック（通常、順序づけ、待機、およびその他のサービスと保証を提供する複雑な同期プリミティブを実行したアプリケーション）およびシステムラッチ（セマフォなどのような基本システムロック）である。全ての同期プリミティブに共通する問題は、デッドロックである。デッドロックとは、２つ以上のプロセスが互いによって取得される同期プリミティブを待機する状態である。これは、デッドロックサイクル内の任意の参加者による進展も妨げる。アプリケーションロックにおけるデッドロックは、比較的容易に見つけられる；すなわち、アプリケーションはこれらのデッドロックについての全ての情報へのアクセスを有するため、アプリケーションは、これが任意のこのようなデッドロックを発見した場合、何らかの修復アクションを取ることができる。しかしシステムラッチデッドロックに作用することは困難である。このような状態において、デッドロックサイクルに参加するプロセスは進展しない；アプリケーションはデッドロックの何の情報も持たず、いかなる修復アクションも不可能である。この状態は、予期しないクライアントの消滅によって、より複雑になる‐アプリケーションロックとシステムラッチの両方は、接続監視デーモンによって適切な時に解除され、現在接続されているクライアントの正確な実行を保証する必要がある。
【００４２】
接続監視デーモンが、障害を起こした各クライアントについて連続してｏｐｌｏｇクリーナープロセスを開始した場合、これはデッドロックに遭遇するであろう。代わりに、本発明の実施形態は、ｏｐｌｏｇクリーナープロセスを開始する大いに協働する設計を用いる。この解決法は、デッドロックがないであろうことを保証する。接続監視デーモンは、現在障害を起こした各クライアントの各接続について、新しいｏｐｌｏｇクリーナープロセスを開始する。当業者は、ｏｐｌｏｇクリーナープロセスは同じプロセスのスレッドでもよいこと、すなわち接続監視デーモンは新しいスレッドもしくはプロセスとしてｏｐｌｏｇクリーナーを生じる選択を有することを認識するであろう。たとえば、それぞれサーバに２つの接続を有する３人のクライアントが消滅した場合、それぞれ１つの特定の接続を削除する、６つのｏｐｌｏｇクリーナープロセスが同時に開始されることができる。プロセスが開始される順番は、それらが全て開始されるならば、問題にならない。この設計は、障害を起こしたプロセスによって取得された全ての同期プリミティブが最終的には解除され、任意のこのような同期プリミティブの無限の待機を防ぐであろうため、ｏｐｌｏｇクリーニングプロセスが行き詰まらないことを保証する。
【００４３】
上述されたＯｐｌｏｇｇｉｎｇシステムの装置は、広い適用性を有する。たとえばこれは、図表作成、インデックス作成などの部分の、データベースの分野における既知のクリティカルセクションに適用されるであろう。他のクリティカルセクションは、カーソルオープン、表カーソル、インデックスカーソル、ハッシュカーソルなど多種のカーソルの次の操作および閉じる操作を含む。クリティカルセクションのさらに他の実施例は、ツリーインデックス、ハッシュインデックスなどの一時インデックスの作成である。さらに、Ｏｐｌｏｇｇｉｎｇシステムが、内在する表および多様なインデックスの、挿入、削除、更新操作において用いられることができる。これらのクリティカルセクションは、表ページのスロットの作成もしくは削除を引き起こし、カウントおよびディレクトリなどを変更するであろう。Ｏｐｌｏｇｇｉｎｇシステムはまた、新しいログファイルを作成したり、ログファイルを開いたり、ログファイルを閉じたりといったアクションを保護するのに用いられることができる。Ｏｐｌｏｇｇｉｎｇシステムが用いられることのできるさらに他の一連の操作はロックマネージャで、ロックしたりロックを解除したりといった操作についてである。本発明の実施形態はまた、これらの技術を、ＤＢＭＳにおけるＳＱＬコマンド
の編集において用いることができる。データベースのフィールドからの上述の実施例は、Ｏｐｌｏｇｇｉｎｇシステムを用いるであろうクリティカルセクションの完全なリストであるよう意図されてはいない。代わりにこれらは、ｏｐｌｏｇｇｉｎｇの恩恵を受けることができるクリティカルセクションの種類を与えるよう意図されている；潜在的使用はより広い。
【００４４】
Ｏｐｌｏｇｇｉｎｇシステムは複雑で扱いにくく見えるであろう。しかし、Ｏｐｌｏｇｇｉｎシステムの実際の実施の結果は大変有望である。ある試験において、たった１２５のクリティカルセクションおよび対応するｏｐｌｏｇだけが必要とされた。ｏｐｌｏｇは、ｏｐｌｏｇについての最大のネスト化深さが１１であるため、深さ１１のスタックに格納された、したがって、コントロールデータ内の全ての変化をｏｐｌｏｇするのに最小のメモリオーバーヘッドがある。さらに、パフォーマンス結果は良好である。Ｏｐｌｏｇｇｉｎｇシステムの付加は、１人のクライアントがサーバに直接接続する時にスループットの減少を１０％より少なくした；複数のクライアントがサーバに接続する時、認識できる減速はない。試験は、Ｏｐｌｏｇｇｉｎｇシステムが、直接接続クライアントに障害がある時にサーバコンポーネントの連続可用性を保証するのに効果的な技術であることを示す。
【００４５】
図１は、データ（マネージドデータといくつかの永続コントロールデータの両方）６と、プロセッサ４（中央演算装置（ＣＰＵ））と、プロセッサ４と通信するメインメモリモジュール８とを含む、直接接続クライアントサーバシステムと示す。一実施例におけるプロセッサ４とメモリ８を含むコンピュータ機器２はサーバである。コンピュータ機器２は、直接接続クライアントサーバシステム１０のためのソフトウェアを格納し、実行する。直接接続クライアントサーバ１０は、Ｏｐｌｏｇｇｉｎｇシステム２０と呼ばれるモジュールを含む。プロセッサ４は、サーバ２において、アドレス可能な共有メモリ６と共に動作する単一のＣＰＵもしくは複数のＣＰＵであろう。データ８は一般的に、このような装置は１つしか図１に示されないが、複数の直接アクセス記憶装置（ＤＡＳＤ）に格納される。所望であれば、データ６は唯一のＤＡＳＤにのみ格納されることができることを、当業者は認識するであろう。さらに、当業者は、任意のその他のコンピュータ読みとり可能な媒体が用いられてデータ６を格納できることを認識するであろう。ＤＡＳＤは、たとえばディスクパックであり、データベースシステムは、データ６とプロセッサ４との間の通信を確立する、要求されるＤＡＳＤコントローラおよびチャネルを含むということが当業者にとって理解されるであろう。他の実施形態において、データ８は、メインメモリ８そのものの中に格納されるであろう。図１に示されないものは、サーバ２の他のコンポーネントである：たとえば、キーボード、マウス、またはモニタである。さらに、サーバ２は「サーバ」と呼ばれるが、任意のマシンが、特に「サーバ」と呼ばれることなく目的を果たすことができることを、当業者は認識するであろう。たとえば、デスクトップコンピュータ、ノートブックコンピュータ、もしくは適切に調整された任意のその他のコンピュータ機器が、「サーバ」２として目的を果たすことができる。
【００４６】
ターミナル１は、ユーザからリクエストを受け入れ、ユーザに結果を戻す、任意の入力／出力（Ｉ／Ｏ）装置である。たとえばターミナルは、パーソナルコンピュータ（ＰＣ）、もしくは広告アプリケーションプログラマインタフェイス（ＡＰＩ）を用いるアプリケーションであろう。リクエストはクライアントによって、ターミナル１から投稿され、直接接続クライアントサーバシステム１０によって、そのＯｐｌｏｇｇｉｎｇシステム２０と連動して同時に処理される。
【００４７】
ターミナル１は、サーバ２に直接接続されてもよく、サーバ２にネットワーク（図１には示されない）を介して接続されてもよい。ターミナル１がサーバ２にネットワークを介して接続される場合、ネットワークは任意の形状であってよい。たとえば、ネットワーク
は、ローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）を介して接続される直接ケーブル接続（ターミナル１とサーバ２の間に何らの媒介リンクがない場合）であってよく、もしくはインターネットなどのグローバルネットワークであってよい。さらに、ターミナル１とサーバ２との間の接続は、ワイヤ接続であってもよく、またはワイヤレス接続であってもよい。接続がワイヤレスである場合、任意のワイヤレスタイプの接続が用いられることができる。たとえば、ＩＥＥＥ  ８０２．１１ａ／ｂ／ｇスタンダードに、もしくはＢｌｕｅｔｏｏｔｈ（登録商標）スタンダードに、適合する任意の接続が用いられることができる。
【００４８】
図２は、Ｏｐｌｏｇｇｉｎｇシステム２０のより詳細を示す。Ｏｐｌｏｇｇｉｎｇシステムはコントロールデータの整合性を維持することをサポートする。まず、新しいクライアントアクションを実行し、障害のないクライアントについて連続のクライアントアクションを実行する能力を、いかにＯｐｌｏｇｇｉｎｇシステムが提供するかを説明し、次いで図２に提示される概略図を詳細に説明する。従来のログ３０は、１つのデータ６が格納されているように、記憶装置に保持される。これらのログは、障害がある場合にシステムを回復し、マネージドデータのアトミック性を維持することをサポートするのに用いられる。これらのログは、直接接続クライアントサーバシステム１０の、マネージドデータの変更についてのみ書き込まれ、コントロールデータの変更については書き込まれない。一実施形態において、メモリ内のデータ８のイメージは、３つのセグメントに分割される。第１のセグメント８１は、コントロールデータである。このデータは、データベースの構造体についてのメタデータと、現在開いているクライアントアクションとそれらの状態についての情報とを定義し、本質的に、これはコントロールデータである。Ｏｐｌｏｇ８２は、クライアントプロセスを実行する代わりにコントロールデータについての情報を格納するために確保されている領域である。データ８３は、直接接続クライアントサーバシステムのマネージドデータを格納するセグメントである。データ８の前のイメージは、データイメージ６として任意のＤＡＳＤに格納される。データへの任意の変更について、マネージドデータログ３０が生成され、ＤＡＳＤに送られる。このことは、クリティカルセクションの途中に消滅した、障害のあったクライアント１０１などの、クライアントの予期しない障害に際し、ｏｐｌｏｇシステム２０が引き継ぐことができ、障害のあったクライアントプロセスに対応する任意のｏｐｌｏｇ８２を発見し、コントロールデータに対する任意の影響を取り消してこれを整合性のある状態にし、次いでクライアントの代わりに実行するアクションにロールバックを呼び出すことを保証する。このことは、マネージドデータログ３０とデータイメージ６とを用いて、マネージドデータに従来のロールバックを遂行するであろう。したがって、Ｏｐｌｏｇｇｉｎｇシステム２０は、クライアントプロセス１０１の予期しない障害に際しても、他のクライアントへの直接接続クライアントサーバシステムの連続的な可用性を保証する。
【００４９】
ここで、図２に提示される概略図を詳細に規定する。ここで留意すべきは、直接接続クライアント１０１の相互作用と、直接接続クライアントサーバシステム１０のクライアントパートと、Ｏｐｌｏｇｇｉｎｇシステム２０、ｏｐｌｏｇ生成部２０１、ｏｐｌｏｇ８２、接続監視デーモン２０２、およびｏｐｌｏｇクリーナープロセス２０３の精成とに注目することである。直接接続クライアント１０１は、メーカー供給のサーバライブラリ１０１１を用いるアプリケーションから成る。ｏｐｌｏｇ生成部２０１は、サーバライブラリ１０１１の一部である。Ｏｐｌｏｇ生成部２０１は、直接接続クライアント１０１がクリティカルセクションにある時、ｏｐｌｏｇを生成する。クライアント接続１０１がクリティカルセクションに入る時、ｏｐｌｏｇ生成部２０１は、共有メモリ８のｏｐｌｏｇ領域８２にｏｐｌｏｇを作成する。接続監視デーモン２０２は、各直接接続クライアント１０１と開かれるソケットを有する。特定のクライアントが予期せず終了する時、接続監視デーモンとのソケット接続は切られる。このことは、図２の第２の直接接続クライアントに示される。接続監視デーモン２０２は、ソケット接続のこの予期しない切断を、直接接
続クライアントの予期しない終了の指示として用いる。任意の直接接続クライアントサーバ１０１の予期しない障害に際し、接続監視デーモン２０２は、障害のあったプロセスにおいてアクティブであった各接続についてｏｐｌｏｇクリーナープロセス２０３を開始する。ここで留意すべきは、図２に示されるように、複数のｏｐｌｏｇクリーナープロセス２０３が開始されるであろうことである。ｏｐｌｏｇクリーナープロセス２０３は接続を引き継ぎ、障害のあったクライアントについてｏｐｌｏｇ領域８２に存在する任意のアクティブなｏｐｌｏｇを探し、障害のあったクライアントによってコントロールデータになされた任意の変更を取り消す。これは、マネージドデータログ３０を用いてロールバックを受けることができる、コントロールデータをマネージドデータについて障害のあったクライアントの全てのアクティブなアクションから、整合性のある状態に戻す。共有データとコントロールデータの両方についてデータベースを整合性のある状態に戻すプロセスおよび、障害のあったクライアントアクティブなアクションをロールバックするプロセスは、障害のなかった他のアクティブなクライアントに対してサーバシステムが連続的に可用であり続ける間に行われる。
【００５０】
コントロールデータを変更するクリティカルセクションの間におけるプロセスの障害がある際にも、直接接続クライアントサーバシステムの連続的な可用性を提供するために、ｏｐｌｏｇをどのように用いられることができるかについての多くの実施例がある。前に言及されたように、本書において全ての可能性を列挙することは不可能である；しかし、本書に概説された装置の３つの異なる適用を見ることにより、可能性の種類を提供することを目指す。まず、シンプルなクリティカルセクション操作「所与の表上でカーソルを開く」におけるｏｐｌｏｇｇｉｎｇテクニックの比較的シンプルな適用を説明する。このような操作は、クライアント接続によりデータを利用するためにしばしば用いられる。データアクセスの不可欠な部分を形成する他の操作は、「カーソルを考慮し次の値を得る」と「カーソルを閉じる」である。いかに連続的可用性が達成されるかを説明するため、初めのものを説明する。次に、クライアントプロセスの障害に際してリンクリストの完全性を維持することが必要な場合に、二重にリンクリストを変更する、ｏｐｌｏｇの適用を説明する、さもなければ次のクライアント接続が無制限にループするか、割り当てられないメモリにアクセスして、それ自身が障害を起こすかである。第３に、ループ状態にあるｏｐｌｏｇｇｉｎｇテクニックの適用を説明する。ここで、操作は、同様のアクションを繰り返し行うことから成り、ループの実行は整合性を保証するために、完結するか、ロールバックするかする必要がある。これらの実施例は、ｏｐｌｏｇｇｉｎｇテクニックの広い適用性の種類を提供するであろう。
【００５１】
図３は、クライアントの終了に際して直接接続クライアントサーバシステム８の可用性を保証する、シンプルなクリティカルセクション操作と、ｏｐｌｏｇの設計との詳細を示す。ＤＢＭＳの実施例を取り上げる。コントロールデータ８１が３つの部分から成ることを前提とする。カーソル構造体８１１は、カーソルについての情報をデータ８に格納する。トランザクション構造体８１２は、トランザクションについての情報をシステムに格納する。表構造体８１３は、所与の表についての情報を格納する。クライアントプロセスがメーカー供給のライブラリ１２を用いてデータ８内のデータにアクセスする時、「所与の表上にカーソルを開く」操作が行われるであろう。
【００５２】
コントロール構造体８１１、８１２、および８１３の初期および最終の状態を示し、「所与の表上にカーソルを開く」操作がいかにコントロール構造体に影響を及ぼすかを説明する。初期状態において、トランザクション８１２２はカーソルを開いていなかった。したがって、そのカーソルフィールド８１２３は空値である。同様に、カーソル８１１１は用いられておらず、したがってその表フィールド８１１２は空値である。同様に、表ヘッダ８１３１は、表上でどのカーソルも開いておらず、したがってカーソルカウント８１３２は０の値を有することに留意する。トランザクション８１２２についての「所与の表上
にカーソルを開く」操作が、表８１３１について成功理に終了する時、最終段階に到達する。最終段階において、トランザクション８１２２は、そのフィールド８１２３に格納され、カーソル８１１１を指すカーソルポインタを有する。カーソル８１１１は同様に、表８１３１を指すよう初期化された表ポインタ８１１２を有する。表ヘッダ８１３１は、その上で開くカーソルを有したので、そのカーソルカウントフィールド８１３２はここで１である。
【００５３】
このクリティカルセクション操作の実行の間、任意の時に何らかの障害がクライアントプロセスに起きた場合、コントロールデータ８１は、どのカーソルもそれを指さない時に表ヘッダ（８１３１）のカーソルカウントフィールド８１３２がゼロでない、整合性のない状態のままであろう。もしくは、カーソル８１１１がそれを指すその表ポインタフィールド８１１２を有する場合に、これはゼロであろう。障害が起こった時に無関係であり、実際、整合性のある初期もしくは最終状態へ進むことができることを確認することが必要である。
【００５４】
ｏｐｌｏｇ構造体８２１は、コントロール構造体になされる変更を追跡するのに用いられるｏｐｌｏｇの１状態の詳細を提供する。ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤおよびＳｔｅｐＮｕｍｂｅｒ以外に、これはトランザクションナンバー（ＸＡＣＴ）、カーソル識別子（ＣＵＲＳＯＲ）、表識別子（ＴＡＢＬＥ）、および表の前回のカーソルカウント（ＣＯＵＮＴ）を格納する。したがって、操作「所与の表上にカーソルを開く」が成功理に終了する前に、すなわちシステムが最終状態に到達してｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが非アクティブに設定される前に、何らかの障害がクライアントプロセスに起きれば、Ｏｐｌｏｇｇｉｎｇシステムはｏｐｌｏｇ８２１を用いて、クリティカルセクション操作「所与の表上にカーソルを開く」の実行の任意の影響を取り消すことができる。とりわけ、ｏｐｌｏｇクリーナープロセスが、実施例に言及される状態のｏｐｌｏｇ８２１をピックアップする場合、これはシンプルに、トランザクション８１２２のカーソルポインタフィールド８１２３に空値を再インストールするであろう。これは、カーソル８１１１の表ポインタフィールド８１１２に空値をインストールし、表ヘッダ８１３１のカーソルカウントフィールド８１３２を、所与の場合は０である操作ｏｐｌｏｇ８２１に格納されたカウントに、リセットする。したがって、ｏｐｌｏｇｇｉｇシステムは、これがクライアントプロセスについて発見する任意のアクティブなｏｐｌｏｇ８２１の影響を取り消す。この時点で、ｏｐｌｏｇｇｉｇシステムは、クライアントプロセスにロールバックを呼び出し、これは、クライアントプロセスが有したであろう任意のマネージドデータ影響を取り消す。したがって、ｏｐｌｏｇｇｉｇシステムは、クライアントサーバシステム内のコントロールデータとマネージドデータの両方に整合性があり、連続的に可用であることを保証する。
【００５５】
図４は、上述したｏｐｌｏｇｇｉｎｇ原理の適用の、さらに他の実施例を提供する。データベースにおける既知かつ一般的な操作は、リンクリストの保守である。図４は、このような実施例を示す。データ８のコントロールデータセグメントは、２つのリンクリスト、リスト１とリスト２とから成る。各リストはアイテム８０から作られる。アイテム８０は、データ８０１、次８０２および前８０３の３つのフィールドから成る。操作はエレメントをリスト２のヘッドからリスト１のヘッドに送る。
【００５６】
８１４の初期状態において、リスト１は２つの部分アイテム１．１とアイテム１．２とを有する。これらは、二重リンクリストとして既知のテクニックにリンクされる。このスキーム下で、リストはアイテム８０を指す。アイテム８０の次のフィールド８０２は、次のアイテム８０を指し、前のフィールド８０３は、リストの前のアイテム８０を指す。同様に、リスト２は、２つの部分アイテム２．１とアイテムとから成る。操作は、リスト２からリスト１のヘッドへ送られるアイテム２．１を識別する。コントロール構造体セグメ
ント８１４の最終状態において、アイテム２．１がリスト１のヘッドに送られたことが発見される。ここで留意すべきは、このことはリスト１、リスト２、アイテム２．１の次のフィールド８０２、アイテム２．２の前のフィールド８０３、アイテム２．１の前のフィールドにおける変更を必要とすることである。ｏｐｌｏｇｇｉｇ（登録商標）システム２０を介するアトミック性と整合性を保証するため、新しいｏｐｌｏｇ８２２を作成する。通常のフィールド以外に、このｏｐｌｏｇは、第１のリストを指すフィールドＬＩＳＴＡ、第１のリストの次のＬＩＳＴＡＮＥＸＴ、第２のリストのＬＩＳＴＢ、ＬＩＳＴＢからＬＩＳＴＡへ動かす必要があるアイテムであるＬＩＳＴＢＣＵＲ、ＬＩＳＴＢＣＵＲからのＬＩＳＴＢの次のアイテムであるＬＩＳＴＢＮＥＸＴ、およびＬＩＳＴＢＣＵＲアイテムからのＬＩＳＴＢの前のアイテムであるＬＩＳＴＢＰＲＥＶから成る。クライアントプロセスがクリティカルセクション操作「リスト間でエレメントを送る」を実行する場合、まず、８２２のリストフィールドのそれぞれについて詳細を格納するｏｐｌｏｇ８２２を作成する。
【００５７】
操作「リスト間でエレメントを送る」の実行中に何らかの障害がある場合、ｏｐｌｏｇｇｉｇシステム２０は、クライアントプロセスに代わって実行していたトランザクションを引き継ぎ、削除するであろう。ここで留意すべきは、整合性のある状態に達するため、操作を完了する、すなわち最終状態に達することができ、もしくは初期状態で終了することができることである。この操作の動作を考慮し、初期状態で終了する必要があることを前提としよう。また、ここで留意すべきは、ｏｐｌｏｇは、ＳｔｅｐＮｕｍｂｅｒが３である所与の状態にあることである。Ｏｐｌｏｇｇｉｇシステム２０はまず、ｏｐｌｏｇ８２を探し、消滅したクライアントプロセスに関連するｏｐｌｏｇ８２２を発見するであろう。状態３を考慮し、ｏｐｌｏｇｇｉｇシステムは次のステップを取り、リスト１およびリスト２を初期状態に修復するであろう。
【００５８】
・この場合はリスト１であるＬＩＳＴＡへ行く。
・リスト１が、この場合はアイテム１．１であるＬＩＳＴＡＮＥＸＴを指すようにする。
【００５９】
・アイテム１．１へ行き、前回ポインタ８０３を空値に設定する。したがって、リスト１はここで元と同じに見える。
【００６０】
・次に、この場合はリスト２であるＬＩＳＴＢが実行される。リスト２は、この場合はアイテム２．１であるＬＩＳＴＢＣＵＲを指すように設定される。
【００６１】
・アイテム２．１の次のフィールド８０２が、この場合はアイテム２．２であるＬＩＳＴＢＮＥＸＴを指すように設定される。
【００６２】
・最後に、アイテム２．１の前のフィールド８０３が、この場合は空値であるＬＩＳＴＢＰＲＥＶを指すように設定される。
したがって、Ｏｐｌｏｇｇｉｎｇシステムは、コントロールデータセグメント８１４がここで初期状態であることを保証する。これは次いで、まだ保持されている任意の同期プリミティブを解除するであろう。その後ロールバックがクライアント接続に呼び出される。
【００６３】
図５は、繰り返されるクリティカルセクション操作の詳細を提供する。この操作は、これがループを終了するまで完了すると考えられない。したがって、データベースシステム１０について整合性のある唯一の状態は、コントロールデータセグメントが最終状態にある時であろう。これは、一旦クリティカルセクション操作「ループしない」が開始すると、唯一の受け入れ可能な最終状態である。インデックスノート８１５１を考慮する。これは、ヘッダ情報以外に、以下のサブコンポーネントを有する；エントリ８１５１２から８
１５１８の７エントリについて、ノードおよびスペースにおけるエントリの数を格納する、フィールド長さ８１５１１である。このノードについて留意すべきは、値はコンパクトに格納される、すなわち値は常に一緒にあり、エントリフィールドにおける値はエントリ８１５１２から開始することである。エントリ８１５１３における値を削除したばかりであることを前提としよう。それを行った後、インデックスノードについて唯一の整合性のある状態は最終状態にある。エントリ８１５１３における値を削除した時、値がコンパクトに格納されることを保証するため、ホール移動プログラムを呼び出す。ここで留意すべきは、一旦エントリ８１５１３における値が削除されると、値がもう存在しないと考え、そのエントリをホールと呼ぶことである。整合性を維持するため、全てのホールはリストの最後にあるべきである。長さ８１５１１を４に設定する。ホール移動は、ホールがリストの最後に移動することを保証するであろう。繰り返しは、ＭＨ．２からＭＨ．７のラインにある。繰り返しは、ホール変動が８１５１１＋長さ（８１５１１における）よりも大きくなるまで続く。またｏｐｌｏｇ８２３を用いてｏｐｌｏｇｇｉｎｇを行うということにまた留意すべきである。ｏｐｌｏｇに、ノード識別子、ノードの長さ、ホールの位置を格納する。一旦ホール移動が完了すると、インデックスノード８１５１は最終状態にあり、ｏｐｌｏｇ８２３は非アクティブ化される。
【００６４】
直接接続クライアントサーバシステム１０におけるマネージドデータのコントロールデータの整合性と、トランザクションのアトミック性とを保証するため、Ｏｐｌｏｇｇｉｎｇシステム２０は、ホール移動プログラムの実行の間にクライアントが障害を起こしたときはいつでも、引き継ぐであろう。その時点で、Ｏｐｌｏｇｇｉｎｇシステムはホール移動プログラムを再度実行するであろうが、これはラインＭＨ．１のループの状態にあるホールを、ｏｐｌｏｇ８２３．ＨＯＬＥに設定するであろう。たとえば、ホール移動におけるコード実行が、ホールが８１５１５だった時に、クライアントプロセスが消滅した場合、Ｏｐｌｏｇｇｉｎｇシステム２０はホール移動において再度繰り返し、インデックスノード８１５１について最終状態をもたらすであろう。その時点で、Ｏｐｌｏｇｇｉｎｇシステムは、クライアントプロセスについて実行中であったトランザクションにロールバックを呼び出し、データ整合性とアトミック性とを保証することができる。
【００６５】
図６Ａおよび６Ｂは、本発明の実施形態にしたがった、図１のｏｐｌｏｇを用いて図１の直接接続クライアントサーバシステムを修復する手順を要約する。図６Ａにおいて、ステップ６０５で、直接接続クライアントサーバシステムは、クライアントがデータベースに直接接続することを許可する。ステップ６１０で、Ｏｐｌｏｇｇｉｎｇシステムはクライアントによってデータになされる変更をログする。ステップ６１５で、システムはチェックしてクライアントに障害が起きたかどうかを見る。起きていたら、次にステップ６２０で、システムは、クライアントによってなされた変更を識別する。
【００６６】
ステップ６２５（図６Ｂ）において、システムは、変更が取り消せるかどうかを決定する（それらが完了していなかったことを前提として）。その場合は、次にステップ６３０で、システムはクライアントによってなされた変更を取り消す。このような変更の実施例は、図３および４を参照して上述したように、表を開いた状態のままにすることと、もしくはリスト間でエレメントを動かすこととを含む。そうでなければ、ステップ６３５で、システムは変更を完了する。このような変更の実施例は、図５を参照して上述したように、ホールをリストの最後に動かすことである。ここで留意すべきは、全ての場合において、クライアントによってなされる変更が取り消され、もしくは完了され、コントロールデータが整合性のある状態にされたことを保証する充分な情報が、利用可能であることが必要であることである。ステップ６３０および６３５のうちの一方が行われることは意味がない：コントロールデータへの変更は、状況に依って、ロールバックされるか完了されるかされる。システムの構造は、コントロールデータが１つの方法もしくは他の方法で整合性のある状態に置かれるようなものである；コントロールデータは整合性のない状態のま
まにされない。
【００６７】
以下の論議は、本発明のいくつかの態様が実施されるであろう適切なマシンの、簡潔な、一般的な説明を提供しようと意図される。一般的に、マシンは、プロセッサ、メモリ、たとえばランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、もしくはその他の状態保持媒体、記憶装置、ビデオインタフェイス、および入力／出力インタフェイスポートが取り付けられる、システムバスを含む。マシンは、少なくとも部分的に、キーボード、マウスなどの従来の入力装置からの入力によって、および他のマシンから受け取った指示、バーチャルリアリティ（ＶＲ）環境との相互作用、バイオメトリックフィードバック、もしくはその他の入力信号によって、制御されるであろう。ここでは、「マシン」の用語は、単一のマシン、もしくは共に動作する、通信で結合されたマシンもしくは装置のシステムを広く包含するよう意図される。典型的なマシンは、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、ハンドヘルド装置、電話、タブレットなどのコンピュータ装置を含む。
【００６８】
マシンは、プログラム可能もしくはプログラム不可能な論理回路もしくはアレイ、特定用途向け集積回路、内蔵コンピュータ、スマートカード、などの内蔵されたコントローラを含むであろう。マシンは、ネットワークインタフェイス、モデム、もしくはその他の通信結合などを通じるなどして、１以上のリモートマシンへの１以上の接続を用いるであろう。マシンは、イントラネット、インターネット、ローカルエリアネットワーク、広域ネットワークなどの物理的および／もしくは論理的ネットワークを手段として、相互接続されるであろう。ネットワーク通信は、無線（ＲＦ）、人工衛星、マイクロ波、電子電気技術者協会（ＩＥＥＥ）８０２．１１、Ｂｌｕｅｔｏｏｔｈ（登録商標）、可視光線、赤外線、ケーブル、レーザーなどを含む、多様な有線および／もしくはワイヤレスの短距離もしくは長距離キャリアおよびプロトコルを用いるであろうことを、当業者は理解するであろう。
【００６９】
本発明は、機能、手順、データ構造体、アプリケーションプログラムなどを含む、関連するデータを参照することにより、もしくはそれとともに、説明され、これは、マシンによってアクセスされた時、タスクを行う、もしくは抽象データ型もしくは低レベルハードウェアコンテキストを規定するマシンをもたらす。関連するデータは、たとえば、たとえばＲＡＭ、ＲＯＭなどの揮発性および／もしくは不揮発性メモリ、もしくはその他の記憶装置、および、ハードドライブ、フロッピー（登録商標）ディスク、光学式記憶、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、生物学的記憶装置などを含む、それらに関連した記憶媒体に格納されるであろう。関連するデータは、パケット、シリアルデータ、パラレルテータ、伝播信号などの形状である物理的および／もしくは論理的ネットワークを含む、伝送環境を越えて配信され、圧縮された、もしくは暗号化されたフォーマットで用いられるであろう。関連するデータは分散環境で用いられ、マシンアクセスについて局所的におよび／もしくは離れて格納される。
【００７０】
説明された実施形態を参照して、本発明の原理を説明し、図解したが、説明された実施形態が、このような原理から離れることなく、配置および詳細において変更されることが認識されるであろう。また、前述の論議は特定の実施形態に焦点が当てられたが、他の構成が意図される。とりわけ、「一実施形態において」などという表現がここで用いられるが、これらのフレーズは通常、実施形態の可能性を参照するよう意味され、本発明を特定の実施形態の構成に限定するよう意図されるものではない。ここでは、これらの用語は、他の実施形態と組み合わせ可能な、同じ、もしくは異なる実施形態を参照するであろう。
【００７１】
結果として、ここに説明される実施形態への多種多様な置換を考慮して、この詳細な説明および関連する構成要素は一例に過ぎず、本発明の範囲を限定するものとして考えられ
るべきではない。したがって、本発明として請求されるのは、以下の請求項の範囲と精神の中に入るであろうこのような変更の全てと、その同等物であろう。
【図面の簡単な説明】
【００７２】
【図１】本発明の実施形態にしたがった、ｏｐｌｏｇｇｉｎｇをサポートする、直接接続クライアントサーバシステムの線図である。
【図２】本発明の実施形態にしたがった、図１の直接接続クライアントサーバシステムにおけるｏｐｌｏｇｇｉｎｇの詳細を示す概略図である。
【図３】本発明の実施形態にしたがった、代表的なクリティカルセクション「表上でカーソルを開く」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図４】本発明の実施形態にしたがった、代表的なクリティカルセクション「リンクリスト間でエレメントを送る」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図５】本発明の実施形態にしたがった、代表的なクリティカルセクション「リストからホールを移動させる」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図６Ａ】本発明の実施形態にしたがった、コントロールデータを整合性のある状態にし、図１のクライアントサーバのマネージドデータになされた任意の変更をロールバックする、図１のｏｐｌｏｇを用いる手順を示す。
【図６Ｂ】本発明の実施形態にしたがった、コントロールデータを整合性のある状態にし、図１のクライアントサーバのマネージドデータになされた任意の変更をロールバックする、図１のｏｐｌｏｇを用いる手順を示す。
【図７】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【図８】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【図９】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【図１】
2008517374.tif 000003
【図２】
2008517374.tif 000004
【図３】
2008517374.tif 000005
【図４】
2008517374.tif 000006
【図５】
2008517374.tif 000007
【図６Ａ】
2008517374.tif 000008
【図６Ｂ】
2008517374.tif 000009
【図７】
2008517374.tif 000010
【図８】
2008517374.tif 000011
【図９】
2008517374.tif 000012
【手続補正書】
【提出日】平成18年8月30日(2006.8.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のクライアント（１）と第２のクライアント（１）とによる同時アクセスをサポートするシステム（２）であって、前記第１のクライアント（１）と前記第２のクライアント（１）はそれぞれ、コントロール構造体のコントロールデータ（８１）を変更する前記クライアントアプリケーションをサポートする、実行可能なライブラリにリンクされるアプリケーションを含み、
前記第１のクライアント（１）によりシステム（２）の前記コントロール構造体内に格納される前記コントロールデータ（８１）における変更についての情報を格納するｏｐｌｏｇ（８２）を生成するｏｐｌｏｇ生成部（２０１）と、
前記第１のクライアント（１）が前記変更を完了する前に障害を起こした場合、前記システム（２）の前記コントロール構造体内に格納される前記コントロールデータ（８１）を修復するｏｐｌｏｇクリーナープロセス（２０３）と、
を備える、コンピュータベースの装置。
【請求項２】
ｏｐｌｏｇ（８２）に格納される前記情報は、ｏｐｌｏｇクリーナープロセス（２０３）が前記コントロール構造体内に格納される前記コントロールデータ（８１）における前記変更を取り消すことを可能にする情報を含む、請求項１に記載のコンピュータベースの装置。
【請求項３】
ｏｐｌｏｇ（８２）は、
前記第１のクライアント（１）であると識別されるトランザクション識別子（８１２２）と、
前記第１のクライアント（１）によって変更される表を識別する表識別子（８１３１）と、
トランザクション識別子（８１２２）と表識別子（８１３１）と関連するカーソル識別子（８１１１）と、
を含む、請求項２に記載のコンピュータベースの装置。
【請求項４】
ｏｐｌｏｇ（８２）は、
第１のリストを識別する第１のリスト識別子と、
第２のリストを識別する第２のリスト識別子と、
第１のリストから第２のリストへ移動されるエレメントを識別するエレメント識別子と、
第１のリスト内の次のエレメントを識別する第１の次のエレメント識別子と、
第２のリスト内の次のエレメントを識別する第２の次のエレメント識別子と
を含む、請求項２に記載のコンピュータベースの装置。
【請求項５】
ｏｐｌｏｇ（８２）に格納された前記情報は、ｏｐｌｏｇクリーナープロセス（２０３）が前記コントロール構造体内に格納される前記コントロールデータ（８１）における前記変更を完了することを可能にする情報を含む、請求項１に記載のコンピュータベースの装置。
【請求項６】
ｏｐｌｏｇ（８２）は、
リスト識別子と、
リスト識別子によって識別されたリストの長さと、
前記リストにおいて繰り返して行われる操作と、
を含む、請求項５に記載のコンピュータベースの装置。
【請求項７】
システム（２）と前記第１のクライアント（１）との間の接続を監視する接続監視デーモン（２０２）をさらに備える、請求項１に記載のコンピュータベースの装置。
【請求項８】
接続監視デーモン（２０２）が前記第１のクライアント（１）の障害を検出した場合、接続監視デーモン（２０２）がｏｐｌｏｇクリーナープロセス（２０３）を開始するよう作動する、請求項７に記載のコンピュータベースの装置。
【請求項９】
システム（２）は、データベースシステムである、請求項１に記載のコンピュータベースの装置。
【請求項１０】
データベースは、メモリ内データベースシステムである、請求項９に記載のコンピュータベースの装置。
【請求項１１】
前記第１のクライアントがデータベースに接続する接続ポイントをさらに備える、請求項９に記載のコンピュータベースの装置。
【請求項１２】
第２のクライアントがデータベースに接続する第２接続ポイントをさらに備える、請求項１１に記載のコンピュータベースの装置。
【請求項１３】
クライアント（１）が、システム（２）のコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）と、
クライアント（１）によってシステム（２）のコントロール構造体内に格納されるコントロールデータ（８１）になされる変更をログすること（６１０）と、
クライアント（１）の障害を監視すること（６１５）と、
クライアント（１）が障害を起こした場合、システム（２）の可用性を維持しつつ、システム（２）のコントロール構造体内に格納されるコントロールデータ（８１）を修復すること（６３０、６３５）と、
を備える、システム（２）を用いる方法。
【請求項１４】
前記方法は、第２のクライアント（１）が、システム（１）のコントロール構造体のコントロールデータ（８１）を変更する第２のクライアントアプリケーションをサポートする実行可能なライブラリにリンクされた第２のアプリケーションを用いることを可能にすること（６０５）をさらに備え、
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、クライアント（１）が障害を起こした場合に、第２のクライアント（１）をシステム（２）から切断することなくシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項１３に記載の方法。
【請求項１５】
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）は、
開いたトランザクションのリストを維持することと、
開いたトランザクションのリスト内の開いたトランザクションをそれぞれカーソルと関連づけることと、
各カーソルをシステム内の表と関連づけることであって、表はカーソルに関連づけられた開いたトランザクションの一部として変更されることと、
を含む、請求項１３に記載の方法。
【請求項１６】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、
第１の関連が存在する場合、カーソルと表との間の第１の関連を削除することと、
第２の関連が存在する場合、開いたトランザクションとカーソルとの間の第２の関連を削除することと、
を含む、請求項１５に記載の方法。
【請求項１７】
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）は、
クライアント（１）によって変更されるシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）におけるリストを識別することと、
クライアント（１）によってリストのエレメントに対して行われる操作を識別することと、
クライアント（１）によってエレメントに対して行われる操作を取り消すための情報を格納することと、
を含む、請求項１３に記載の方法。
【請求項１８】
操作を識別することは、リストに加えられるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項１９】
操作を識別することは、リストから削除されるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項２０】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復することは、
リストにおけるホールとして削除されるエレメントを識別することと、
リストが連続するまでホールを繰り返して移動することと、
を含む、請求項１９に記載の方法。
【請求項２１】
操作を識別することは、リスト内で移動されるエレメントを識別することを含む、請求項１７に記載の方法。
【請求項２２】
システムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、リスト内のエレメントを元の状態に復元することを含む、請求項１７に記載の方法。
【請求項２３】
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）は、
クライアントによって変更されるシステムのコントロール構造体内に格納されたコントロールデータ（８１）におけるリストを識別することと、
クライアントによってリスト内のエレメントに対して行われる操作を識別することと、
操作についての情報を格納することと、
を含む、請求項１３に記載の方法。
【請求項２４】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復することは、
クライアントが操作を行っていないエレメントを識別することと、
エレメントに対して操作を繰り返し行うことと、
を含む、請求項２３に記載の方法。
【請求項２５】
操作を識別することは、クライアントによってリスト内のエレメントに対して行われるホール移動操作を識別することを含み、
操作をエレメントに対して繰り返し行うことは、リストが連続するまで、リスト内のエレメントを越えてホールを繰り返し移動することを含む、
請求項２４に記載の方法。
【請求項２６】
クライアント（１）が、システム（２）のコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）は、クライアント（１）がデータベースシステムのコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）を含み、
変更をログすること（６１０）は、クライアント（１）によってデータベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）を含み、
システムのコントロール構造体を修復すること（６３０、６３５）は、データベースシステムの可用性を維持しつつ、データベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項１３に記載の方法。
【請求項２７】
クライアント（１）がデータベースシステム（２）のコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）は、クライアント（１）がメモリ内データベースシステムのコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）を含み、
変更をログすること（６１０）は、クライアントによってメモリ内データベースシステ
ムのコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）を含み、
システムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、メモリ内データベースシステムの可用性を維持しつつ、メモリ内データベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項２６に記載の方法。
【請求項２８】
関連するデータを有するマシンアクセス可能な媒体を備える物品であって、データがアクセスされると、
クライアント（１）が、システム（２）のコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）と、
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）と、
クライアント（１）の障害を監視すること（６１５）と、
クライアント（１）が障害を起こした場合、システム（２）の可用性を維持しつつ、システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）と、
をマシンが行う物品。
【請求項２９】
マシンアクセス可能なデータは、アクセスされると、第２のクライアント（１）がシステム（２）に直接接続することを可能にする（６０５）、関連するデータをさらに含み、
システムのコントロール構造体を修復すること（６３０、６３５）は、クライアント（１）が障害を起こした場合、第２のクライアント（１）をシステム（２）から切断することなく、システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項２８に記載の物品。
【請求項３０】
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすることは、
開いたトランザクションのリストを維持することと、
開いたトランザクションのリスト内の開いたトランザクションをそれぞれカーソルに関連づけることと、
各カーソルをシステム（２）内の表に関連づけることであって、表はカーソルに関連づけられた開いたトランザクションの一部として変更されることと、
を含む、請求項２８に記載の物品。
【請求項３１】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、
第１の関連が存在する場合、カーソルと表との間の第１の関連を削除することと、
第２の関連が存在する場合、開いたトランザクションとカーソルとの間の第２の関連を削除することと
を含む、請求項３０に記載の物品。
【請求項３２】
クライアント（１）によってシステムのコントロール構造体になされる変更をログすること（６１０）は、
クライアント（１）によって変更されるシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）におけるリストを識別することと、
クライアント（１）によってリスト内のエレメントに対して行われる操作を識別することと、
クライアント（１）によってエレメントに対して行われる操作を取り消すための情報を格納することと、
を含む、請求項２８に記載の物品。
【請求項３３】
操作を識別することは、リストに加えられるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３４】
操作を識別することは、リストから削除されるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３５】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、
リストにおけるホールとして削除されるエレメントを識別することと、
リストが連続するまでホールを繰り返し移動することと、
を含む、請求項３４に記載の物品。
【請求項３６】
操作を識別することは、リスト内で移動されるエレメントを識別することを含む、請求項３２に記載の物品。
【請求項３７】
システム（１）のコントロール構造体内に格納されたコントロールデータ（８１）を修復することは、リスト内のエレメントを元の状態に復元することを含む、請求項３２に記載の物品。
【請求項３８】
クライアント（１）によってシステム（２）のコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）は、
クライアント（１）によって変更されるシステムのコントロール構造体内に格納されたコントロールデータ（８１）のリストを識別することと、
クライアント（１）によってリスト内のエレメントに対して行われる操作を識別することと、
操作についての情報を格納することと、
を含む、請求項２８に記載の物品。
【請求項３９】
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、
クライアント（１）が操作を行っていないエレメントを識別することと、
エレメントに対して操作を繰り返し行うことと、
を含む、請求項３８に記載の物品。
【請求項４０】
操作を識別することは、クライアント（１）によってリスト内のエレメントに対して行われるホール動作操作を識別することを含み、
操作をエレメントに対して繰り返し行うことは、リストが連続するまで、リスト内のエレメントを越えてホールを繰り返し移動することを含む、
請求項３９に記載の物品。
【請求項４１】
クライアント（１）がシステム（２）のコントロール構造体のコントロールデータ（８１）を変更するクライアント（１）アプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）は、クライアント（１）がデータベースシステムのコントロール構造体のコントロール
データ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）を含み、
変更をログすること（６１０）は、クライアント（１）によってデータベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）を含み、
システムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、データベースシステムの可用性を維持しつつ、データベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項２８に記載の物品。
【請求項４２】
クライアント（１）がデータベースシステムのコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）は、クライアント（１）がメモリ内データベースシステムのコントロール構造体のコントロールデータ（８１）を変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすること（６０５）を含み、
変更をログする（６１０）ことは、クライアント（１）によってメモリ内データベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）になされる変更をログすること（６１０）を含み、
システム（２）のコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）は、メモリ内データベースシステムの可用性を維持しつつ、メモリ内データベースシステムのコントロール構造体内に格納されたコントロールデータ（８１）を修復すること（６３０、６３５）を含む、
請求項２８に記載の物品。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、クライアントサーバシステムにおける回復の分野に関する。具体的には、本発明は、クライアントプロセスがサーバプロセスに直接接続するアーキテクチャに関する。より具体的には、本発明は、サーバサブシステムに直接接続する１以上のクライアントプロセスの障害に際し、現在および新規のクライアントに対するサーバサブシステムの可用性を維持する能力に関する。
【背景技術】
【０００２】
発明の背景
コンピュータアプリケーションの一般的なアーキテクチャは、クライアントサーバアーキテクチャである。クライアントサーバアプリケーションは、アプリケーションの機能性がサーバとクライアントにわたって分け合われるコンピュータシステムである。たとえば、クライアントはユーザインタフェイスを提供し、サーバは共有リソースへのアクセスを
提供するであろう。一般的に、クライアントおよびサーバは分離されたプロセスとして実行する。クライアントは、サーバプロセスに、自身の代わりにアクションを行うようにリクエストする、すなわち、クライアントはサーバを介して共有リソースにアクセスする。サーバは、共有リソースを管理し、これらのリソースはマネージドデータ（ｍａｎａｇｅｄ  ｄａｔａ）と名づけられるであろう。アクションの実行を容易にするために（クライアントの代わりに）、サーバはコントロールデータを維持し、これらのアクションの実行を管理する必要がある。コントロールデータの実施例は、同時並行性、許可、マネージドデータへのアクセスなどを制御するための情報である。一般的に、コントロールデータは一時的であり、システム開始にあたって再初期化される；しかし、コントロールデータの部分は永続的であることができる。要約すれば、クライアントサーバシステムのサーバによって取り扱われるデータは、２つの部分に分割されるであろう：マネージドデータとコントロールデータである。
【０００３】
クライアントサーバアーキテクチャにおいて用いられるサーバの一般的な実施例は、データベースマネジメントシステム（ＤＢＭＳ）である。データベースはコンピュータに格納されるデータアイテムの集合である‐これらのデータアイテムは、データベースマネジメントシステム（ＤＢＭＳ）設定におけるマネージドデータを構成する。複数のユーザがこれらの（マネージド）データアイテムに、クライアントを介して同時にアクセスするであろう。クライアントの代わりに実行されるアクションは、トランザクションと呼ばれる。トランザクションは、データベースから読み出し、データベースに書き込み（挿入、削除、もしくは更新）、または両方を行い、したがってトランザクションは多数の読みおよび書き操作から作られるであろう。トランザクションは、データアイテムの変更のみならず、ＤＢＭＳが内部に維持して実行を制御し、内在するデータアイテムにアクセスを提供するコントロールデータの変更をもまたもたらす。本発明者は、ＤＢＭＳからの実施例をしばしば提供するであろう。しかし、ここで留意すべきは、ここに提示される発明は広い適用性を有し、ＤＢＭＳはアプリケーションの一実施例に過ぎないことである。
【０００４】
当業者は、アトミック性が、任意のミッションクリティカルクライアントサーバシステムの所望の挙動であることを理解するであろう。アトミック性は、任意のクライアントリクエストが完全に実行され、もしくは全く実行されないという特性、すなわち、クライアントがリクエストしたアクションの全ての影響が他のクライアントに可視であるか、どの影響も不可視であるかということに言及する。アトミック性が非常に所望されるクライアントサーバシステムの一実施例は、ＤＢＭＳである。トランザクションの全ての影響が他のトランザクションに可視であるべきか、どの影響も不可視であるべきか（これはトランザクションのＡＣＩＤ（アトミック性、同時並行性、分離性、永続性）特性の部分である）である。クライアントリクエストは、マネージドデータに、意図的な直接影響を有する。しかし、コントロールデータは間接的に変更される。これは、クライアントに代わって実行されるサーバプロセスによって変更される。一般的に、アトミック性の特性は、コントロールデータではなくマネージドデータに関連する。
【０００５】
技術的に、ロギングと回復を介して、マネージドデータにアトミック性を実施するテクニックは、汎用的である。先書きロギング（ＷＡＬ）は、ロギングの既知の実施例である。このスキームにおいて、ログ記録が作成され、マネージドデータになされた変更を追跡する。ログ記録は、マネージドデータの古いコピーを、新しいコピーと同じく含む。これらはまた、クライアントアクションの開始と終了とを記録する。ＷＡＬは、ログ記録が、実際のマネージドデータを持続する前に、ディスクなどの不揮発性の媒体まで持続されることを保証する。したがって、任意の障害の場合、サーバは、所与のクライアントアクションが部分的に完了されたか、完全に完了されたかを決定することを存続するログ記録を用いる。部分的に完了したクライアントアクションの影響は、ログ記録に保存されたマネージドデータの古いコピーを用いることにより取り消され、マネージドデータの状態を、
クライアントアクションを開始する前の状態にロールバックする。同様に、ログ記録に保存されたマネージドデータの新しいコピーが用いられて、マネージドデータの状態をロールフォワードして完全に完了したクライアントアクションによって行われた変更を反映する。このようにして、サーバは、マネージドデータにおけるクライアントアクションのアトミック性を、障害に際する場合にも保証する。ロールバックおよびロールフォワードは共に、システムにおけるアトミック性を達成することをサポートする。
【０００６】
アトミック性がマネージドデータについて正確な状態であるのとちょうど同じく、整合性がコントロールデータについての正確な状態である。コントロールデータについての整合性のある状態を、コントロールデータがクライアントアクションによって変更されない任意の状態と規定する。ここで留意すべきは、ロールバックの終了にあたり、コントロールデータは本質的に整合性のある状態にあることである。クライアントアクションが行われた場合、これに限定されるものではないが、アクセスコントロール情報、マネージドデータメタデータ、同時性コントロール情報などを含む、コントロールデータに変更をもたらすであろう。クライアントの障害に際し、コントロールデータは、サーバが、マネージドデータに行われたクライアントアクションの影響を成功理にロールバックできる前に、整合性のある状態にある必要がある。
【０００７】
回復とは、コントロールデータとマネージドデータの両方を正確な状態にするプロセスであると定義する。つまり、回復は、コントロールデータを整合性のある状態にすることと、マネージドデータについてのアトミック性を維持することとを含む。
【０００８】
従来、ＤＢＭＳなどのクライアントサーバシステムにおいて、クライアントリクエストは、クライアントプロセスそのものから分離されてサーバプロセスにおいて実行され、クライアントプロセスは、メッセージなどのプロセス間通信機構を介してサーバに接続する。これらの構成は、間接接続と呼ばれる。このような構成は、クライアントのエラーからの回復力が高い。具体的に、クライアントプロセスが消滅するか終了する場合、サーバはクライアントとの通信の欠如を通じて障害を検出し、障害を起こしたクライアントプロセスに代わって、変更されたであろう任意のコントロールデータを削除し、コントロールデータについて整合性のある状態に達し、障害を起こしたクライアントプロセスの代わりに実行されていた全ての不完全なアクションをロールバックする。従来の間接接続の重大な利益は、クライアントプロセスの障害が、サーバがコントロールデータにもたらす変更を中断しないことである。したがって、クライアントプロセスの障害は、部分的に変更されたコントロールデータをもたらすことはない。たとえば、コントロールデータにおける一般的な変更は、リンクリストへの挿入であるかもしれない。間接接続では、リンクリストを変更する行為は、変更の途中で中断しない；むしろこれは挿入の前後で中断するであろう。リンクリストを変更する行為が途中で中断しないであろうことは、クライアントが消滅した場合にこれらの不連続のポイントでのみサーバがチェックするためである；クライアントが消滅した場合、サーバはさらなるアクションを取ることができる。基本的に、サーバプロセスは、そうすることが都合の良い場合、すなわちコントロールデータが整合性のある状態にある時、クライアントの障害に作用することが自由である。
【０００９】
クライアントプロセスとサーバプロセスとの間のプロセス間通信が、サーバプロセスをクライアントの障害から隔離する一方、これは著しい動作オーバーヘッドを各クライアントリクエストに加える。このオーバーヘッドは、高性能環境において望ましくなく、とりわけメモリ内ＤＢＭＳについて受け入れられない。メモリ内ＤＢＭＳは、６４ビットプロセッサと安価で充分なメインメモリをフルに活用し、大変高い性能を供給するために設計された、最新技術のＤＢＭＳである。このようなシステムにおいて、データベースの全てのデータアイテムは、ランタイムに、ディスクなどの不揮発性メモリにある代わりに、メインメモリにある。
【００１０】
プロセス間通信のオーバーヘッドを克服する一般的な解決法は、いくつかのサーバ機能について、クライアントアプリケーションとリンクされることができる、実行可能なライブラリとしてパッケージ化されることであり、またクライアントアプリケーションについて、またサーバのその部分について、単一のプロセスで実行することである。この構成を、直接接続と呼び、結合したクライアントアプリケーションおよびサーバライブラリを直接接続クライアントサーバシステムと呼ぶ。一般的に、クライアントサーバアプリケーションに多数のクライアントがあるため、コントロールデータおよびいくつかもしくは全てのマネージドデータを共有メモリセグメントに維持することが一般的である。
【００１１】
このような環境において、クライアントプロセスの障害は、クライアントアクションの実行を中断しうる。このようなクライアント障害の結果は、潜在的に整合性のない状態にあるマネージドデータとコントロールデータの両方を含む。たとえば、コントロールデータのリンクリストを変更するクライアントを再び考慮する。直接接続モデルにおいて、クライアントは、リンクリストを変更する途中に消滅するか終了するかであろう。したがって、リンクリストは循環する状態のままにされ、切断され、もしくはいくつかのその他の整合性のない状態のままにされるであろう。サーバが、整合性のない状態からのロールバックを試行する場合、これは無限のループから抜け出せず、メモリをリークし、クラッシュするかもしれない。したがって、コントロールデータが整合性のない状態にあるかもしれないという事実は、障害のあったクライアントによってマネージドデータに行われた変更をロールバックしようとするサーバに問題を生じる。
【００１２】
直接接続クライアントによるコントロールデータへの変更を扱う問題の１つの解決法は、コントロールデータを変更する途中に、直接接続クライアントプロセスに予期しない障害が起きた時はいつでも、サーバへの全てのクライアント接続が無効であると宣言することである。時々、クリティカルセクションが用いられて、コントロールデータを変更するこのような領域を宣言する。これらの領域は粒度の点で変動するであろう；この技術のシンプルな適用は、全てのサーバ実行可能なライブラリがクリティカルセクションであると宣言することである。サーバは、部分的に変更されたコントロールデータを整合性のある状態にすることができず、このスキームは、任意のクライアントがサーバライブラリの中にある時に障害を起こした時に、全てのクライアントが再度接続することを強いる。このことはまた、システムがその回復プロセス（前に説明されたように、マネージドデータのアトミック性を保証するために用いられる）を経てコントロールデータを再初期化するようにする。この解決法は効果的であるが、実用的ではない。６４のプロセッサおよび、おそらくデータベースへの５０のクライアント接続を有する、大きなＳＭＰマシンを考慮する。任意の単一の予期しない終了は、全てのクライアント接続が切断されることをもたらすであろう。これはとりわけ、メモリ内ＤＢＭＳなどの、間接接続が提供する同じ安定性保証を要求するが、直接接続クライアントサーバシステムの速度有利性を所望するミッションクリティカルなアプリケーションにおいて、重大な攻撃である。
【００１３】
これらの問題を扱う他の提案があり、それらは部分的な解決法であった。ＭｏｌｅｓｋｙとＲａｍａｍｒｉｔｈａｍ（Ｒｅｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ｓｈａｒｅｄ  Ｍｅｍｏｒｙ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍｓ、  ｐｕｂｌｉｓｈｅｄ  ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  １９９５  ＡＣＭ  ＳＩＧＭＯＤ  ｉｎｔｅｒｎａｔｉｏｎａｌ  ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｍａｎａｇｅｍｅｎｔ  ｏｆ  ｄａｔａ、ＰＰ１１〜２２、またｐｕｂｌｉｓｈｅｄ  ｉｎ  ＡＣＭ  ＳＩＧＭＯＤ  Ｒｅｃｏｒｄ、Ｖｏｌｕｍｅ  ２４、Ｉｓｓｕｅ  ２、１９９５年５月）は、ノードの障害に際してもコントロール構造体のコヒーレンスを保証することができる、ハードウェアベースのキャッシュコヒーレンスモデルを提案した。彼らは、ノードを、所与のトランザクションを実行する、プロセス／メモリの対であると規定する。しかしこれらのスキームを実
施するには、キャッシュラインをロックするのに特別なハードウェア命令が要求され、正確な識別子でタグをつけるのに、特別なキャッシュライン構造体が必要とされる。これらのハードウェア特性はそこで、データベースへの全ての接続をシャットダウンすることを含まない回復スキームを実施するのに用いられる。プロセスアーキテクチャにおける進展があっても、提案された要求は最新のプロセッサに対応しなかった。したがって、このスキームは今日実施するには実用的ではない。異なるプロセスの間で交わされるメッセージに依る他のスキームが提案された。しかしこれらは、間接接続と同じパフォーマンス欠点を有する。
【００１４】
無効の問題を扱うように変更されることができる他のスキームは、Ｎｅｖｅｓ他（Ａ  Ｃｈｅｃｋｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ａｎ  Ｅｎｔｒｙ  Ｃｏｎｓｉｓｔｅｎｔ  Ｓｈａｒｅｄ  Ｍｅｍｏｒｙ  Ｓｙｓｔｅｍ、ｐｕｂｌｉｓｈｅｄ  ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ｔｈｉｒｔｅｅｎｔｈ  ａｎｎｕａｌ  ＡＣＭ  ｓｙｍｐｏｓｉｕｍ  ｏｎ  ｐｒｉｎｃｉｐｌｅｓ  ｏｆ  ｄｉｓｔｒｉｂｕｔｅｄ  ｃｏｍｐｕｔｉｎｇ、ＰＰ１２１〜１２９）によって提案されたチェックポイントプロトコルである。このプロトコルの主要な欠点は、エントリに整合性のある共有メモリシステムを仮定することである。このようなモデルにおいて、共有メモリの全てのアクセスは、保護されると仮定され、多様なアクセス間に依存はない。このモデルは、ＤＢＭＳなどの複雑なシステムについて実用的ではない。ＤＢＭＳにおいて、共有メモリの複数のセグメントが、単一のユニットとして依存する方法で、アクセスされ、更新されるであろう。さらに他の一連のスキームは、Ｇａｎｅｓｈ他（米国特許第６，２９５，６１０号および第６，６４７，５１０号）によって提案され、障害のあったクライアントから回復するのにかかる時間を短縮した。しかしこれらのスキームはコントロールデータの整合性に達することができない。
【００１５】
したがって、技術を改良して、直接接続クライアントモデルのコントロールデータの整合性を達成することが必要とされる。このようなシステムの実施例は、直接接続クライアントプロセスがＤＢＭＳと同じプロセスで実行する場合であり、とりわけＤＢＭＳがメモリ内ＤＢＭＳである場合である。これらの技術は、全てのハードウェアプラットフォームに広く移植できるべきであり‐すなわち、技術はハードウェアニュートラルであるべきであり‐実用的であり、パフォーマンスもしくは同時並行性を犠牲にすることなく、また大きな記憶装置を必要とすることなく、コントロールデータの整合性を達成すべきである。
【００１６】
上述で、マネージドデータへの変更を追跡するためにロギング技術が用いられ、クライアントアクションのアトミック性を保証することを見た。一般的に、これらの技術はコントロールデータの変更を追跡するのには用いられない。たとえば、Ｆｒｅｕｎｄ他（米国特許第５，９２３，８３３号）は、トランザクション内のマネージドデータをログし、障害の際にはログを用いてマネージドデータの初期状態を回復するシステムを開示している。同様に、Ｗａｎｇ他（米国特許第６，６３１，４７８号）は、高性能で、安定した記憶階層の技術を開示している。しかしＦｒｅｕｎｄもＷａｎｇもログせず、コントロールデータを回復することができない。コントロールデータは、普通は一時的であり、サーバがクライアントの代わりに行うアクションの実行を管理することをサポートするために存在する。さらに、従来の間接接続は、システムを、部分的に変更されたコントロールデータを扱わなければならないことから隔離する；したがって、コントロールデータにおいて整合性を達成することは、これらの従来のシステムにおける課題ではない。しかし、直接接続クライアントにとって、マネージドデータについて整合性のある状態に達することは最優先事項であり、そうでなければ全ての実行は終了しなければならない。
【００１７】
マネージドデータについて上述されたスキームと同様に、永続的な記憶装置にコントロールデータへの全ての変更をログすることを提案できるかもしれない。このことは、生成
されるであろうログの量からして、はるかに大きな不揮発性の記憶装置を要求するであろう。より重要なことに、遅い不揮発性の記憶装置への頻繁なアクセスのために、このようなシステムはより遅く、システムはディスクバウンドするであろう。したがって、このスキームは実用的ではない。
【発明の開示】
【課題を解決するための手段】
【００１８】
発明の概要
本発明者は、直接接続クライアントサーバシステムのコントロールデータにおける整合性を保証する新しい技術を提案する。本発明者は、従来のデータロギングの原理を、コントロールデータとの関連で用い、障害回復サブシステムの設計に用いられる広い原理を規定する技術を提案する。提案された装置は、クリティカルセクション、ｏｐｌｏｇ、ｏｐｌｏｇ生成部、接続監視プロセス、ｏｐｌｏｇクリーナープロセスから成る。この装置は全体で、Ｏｐｌｏｇｇｉｎｇシステムとして知られる。
【００１９】
そこで、本発明の第１の態様にしたがって、
第１のクライアントと第２のクライアントによる同時アクセスをサポートするシステムであって、前記第１のクライアントと前記第２のクライアントはそれぞれ、コントロール構造体のコントロールデータを変更する前記クライアントアプリケーションをサポートする、実行可能なライブラリにリンクされるアプリケーションを含み、
前記第１のクライアントによるシステムの前記コントロール構造体内に格納される前記コントロールデータにおける変更についての情報を格納するｏｐｌｏｇを生成するｏｐｌｏｇ生成器と、
前記第１のクライアントが前記変更を完了する前に障害を起こした場合、システムの前記コントロール構造体内に格納される前記コントロールデータを修復するｏｐｌｏｇクリーナープロセスと、
を備える、コンピュータベースの装置を提供する。
【００２０】
第２の態様にしたがって、
クライアントが、システムのコントロール構造体のコントロールデータを変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすることと、
クライアントによってシステムのコントロール構造体内に格納されるコントロールデータになされる変更をログすることと、
クライアントの障害を監視することと、
クライアントが障害を起こした場合、システムの可用性を維持しつつ、システムのコントロール構造体内に格納されるコントロールデータを修復することと、
を備える、システムを用いる方法を提供する。
【００２１】
第３の態様にしたがって、
データがアクセスされると、
クライアントが、システムのコントロール構造体のコントロールデータを変更するクライアントアプリケーションをサポートする実行可能なライブラリにリンクされたクライアントアプリケーションを用いることを可能にすることと、
クライアントによってシステムのコントロール構造体内に格納されたコントロールデータになされる変更をログすることと、
クライアントの障害を監視することと、
クライアントが障害を起こした場合、システムの可用性を維持しつつ、システムのコントロール構造体内に格納されたコントロールデータを修復することと、
をマシンが行う、関連するデータを有するマシンアクセス可能な媒体を備える項目をま
た提供する。
【発明を実施するための最良の形態】
【００２２】
詳細な説明
この項の以下の部分で、以下のこれらのコンポーネントを規定し、各コンポーネントを詳細に説明する。Ｏｐｌｏｇｇｉｎｇシステムは以下より成る。
【００２３】
・クリティカルセクション：クリティカルセクションは、直接接続クライアントがコントロールデータを操作する時に、強化障害回復が必要とされるであろうところを、規定する。
【００２４】
・Ｏｐｌｏｇ：障害回復を助けるために、ｏｐｌｏｇとして知られるコントロールデータのログが維持される。
【００２５】
・Ｏｐｌｏｇ生成部：これは、（直接接続クライアントの部分である）サーバライブラリの部分である）。実行する直接接続クライアントは、クリティカルセクション内で実行する時、ｏｐｌｏｇ生成部を用いて、ｏｐｌｏｇを維持する。
【００２６】
・接続監視システム：サーバにおけるプロセスは、直接接続クライアントの健全性を監視する。直接接続クライアントの障害の時に、接続監視プロセスは、障害のあったクライアントの影響を取り消す、１以上のｏｐｌｏｇクリーナープロセス（以下に規定される）を開始する。
【００２７】
・Ｏｐｌｏｇクリーナープロセス：このプロセスは、障害のあったクライアントについてのｏｐｌｏｇを読み、コントロールデータを修復して、マネージドデータにロールバックをコールする。
【００２８】
クリティカルセクションの概念は、Ｏｐｌｏｇｇｉｎｇシステムの中核を成す。クリティカルセクションは、直接接続クライアントの消滅や予期しない終了が、コントロールデータを整合性のない状態に放置するであろう、サーバライブラリの一部である。前述において、コントロールデータについての整合性のある状態を、そこからロールバックがマネージドデータに行われることのできる状態であると、規定された。したがって、各クリティカルセクションは、サーバが、直接接続クライアントによって実行されていた未完了のアクションを調査し、修復アクションを取ってコントロールデータについて整合性のある状態に達することができることを保証するため、保護を必要とする；そしてその後、アトミック性を保証するべく、マネージドデータにロールバックを行う。ここで留意すべきは、クリティカルセクションは通常、同期プリミティブによって保護される共有データを変更することである。しかし、同期プリミティブは常に必要とはされない。クリティカルセクションは、どの同時アクセスにもさらされないであろう、接続固有の情報への変更から成るであろう。しかしこの文書における議論について、クリティカルセクションが同期プリミティブによって保護されるという一般条件を前提とする。ここで留意すべきは、複雑なシステムにおけるクリティカルセクションが、同期プリミティブによって保護される複数の共有データ構造体にアクセスするであろうため、大きいであろうことである。したがって、アプリケーションがどこにあったか、またコントロールデータを整合性のある状態にするためにどの修復アクションが用いられることができるかを、サーバが正確に理解することをサポートするために、高機能のスキームが要求される。
【００２９】
各クリティカルセクションについて、ｏｐｌｏｇを規定する。ｏｐｌｏｇは、既知のロギングスキームの、マネージドデータにおけるコントロール構造体への適応である。しかし、マネージドデータの従来のログと異なり、本発明の実施形態についてのｏｐｌｏｇの
設計は、それが保護するクリティカルセクションの構造体に、密接に結びついている。シンプルなクリティカルセクションは、フィールド「Ａ」と識別されるデータフィールドを有し、コントロールデータを保護する同期プリミティブを有するかも知れず、有しないかも知れない。先に言及されたように、この議論のために、クリティカルセクションが常にコントロールデータを保護する同期プリミティブを有するであろうことを前提とする。クリティカルセクションと共に用いるｏｐｌｏｇは、少なくとも２つの構造体を有する‐非アクティブに、もしくはｏｐｌｏｇが関連するクリティカルセクションを識別するように設定されたＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤフィールドと、実行がクリティカルセクションにある場合に識別するＳｔｅｐＮｕｍｂｅｒフィールドである。クリティカルセクションに特有の、より多くのフィールドがあるであろう。たとえば、検討中のシンプルなｏｐｌｏｇは、フィールドＡの古い値を格納する他のフィールドを有することができる。このシンプルな場合において、クリティカルセクションは、同期プリミティブを取得した時に開始し、同期プリミティブが解除された時に終了する。このクリティカルセクションにおいて、同期プリミティブはフィールドＡに取得され、そこでフィールドＡにおける値がインクリメントされ、最後にフィールドＡの同期プリミティブが解除される。
【００３０】
図７は、このコントロール構造体および関連するｏｐｌｏｇの実施例を示す。ｏｐｌｏｇは、クライアント接続がクリティカルセクションにあるときは常に、コントロールデータ状態を反映する必要がある。ここで、シンプルなクリティカルセクションについてｏｐｌｏｇが通過する状態を詳述する。初期状態において、ｏｐｌｏｇは非アクティブであり、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが非アクティブに設定されるであろう。この時点で、ｏｐｌｏｇに情報はなく、このようなｏｐｌｏｇはｏｐｌｏｇクリーナープロセスによって処理されないであろう。同期プリミティブが取得される前に、ｏｐｌｏｇのＳｔｅｐＮｕｍｂｅｒが０に設定され、そこでＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが、実施例においては６５である現在のクリティカルセクション識別子に設定されるであろう。コントロールプリミティブを取得した後で、しかしフィールドＡの値が変更される（実施例においてはインクリメントされる）前に、ｏｐｌｏｇはまず、実施例においては５５であるＯｌｄＶａｌｕｅにおけるＡの現在値を格納するであろう；そしてＳｔｅｐＮｕｍｂｅｒを１に設定するであろう。フィールドＡの値がインクリメントされた後、そのイベントは、ＳｔｅｐＮｕｍｂｅｒを２に変更することによりｏｐｌｏｇに示される。その後、クリティカルセクションは同期プリミティブを解除し、終了する。ｏｐｌｏｇは、そのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤを非アクティブに設定することにより削除される。
【００３１】
より複雑なクリティカルセクションについて、ｏｐｌｏｇは対応してより複雑になることができる。Ｏｐｌｏｇｇｉｎｇについての明確なステップは、同期プリミティブの取得の後で、同期プリミティブの解除の前である。値は、フィールドの変更の前に、しかし同期プリミティブが取得された後に、記録される。このようなクリティカルセクションの実施例は、異なる同期プリミティブの下にあるが、同じクリティカルセクションの部分である２つの値が変更され、１つの論理演算を形成した時である。２つのコントロールデータフィールドＡおよびＢをカバーするクリティカルセクションを考える。それぞれ異なる同期プリミティブの下にある、フィールドＡがまず、次にフィールドＢが、変更される。この実施例において、クリティカルセクションはフィールドＡの同期プリミティブを取得し、フィールドＡにおける値をインクリメントし、そしてフィールドＡの同期プリミティブを解除するであろう。クリティカルセクションはそこで、フィールドＢの同期プリミティブを取得し、フィールドＢにおける値をＡにおいて見つけた値によってインクリメントするであろう。
【００３２】
図８は、このより複雑なクリティカルセクションの実施例を示す。このオペレーションについての関連するｏｐｌｏｇは、必要とされるフィールドＳｔｅｐＮｕｍｂｅｒおよびＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤから成る。２つのさらなるフィールドが用いられて
フィールドＡおよびＢの値：ＯｌｄＶａｌｕｅＡおよびＯｌｄＶａｌｕｅＢ、を格納する。ここで留意すべきは、フィールドＡとフィールドＢが既知の位置にない場合、２つのさらなるフィールドが用いられて、フィールドＡとＢの位置を格納できることである。さらに、フィールドＡとＢの同期プリミティブが既知の位置にない場合、２つのさらなるフィールドが用いられて、これらの同期プリミティブの位置を格納することができる。この実施例において、フィールドＡとＢおよびそれらの同期プリミティブが既知の位置にあることを前提とする。
【００３３】
対応するｏｐｌｏｇが、コントロールデータが通過する全ての遷移を反映するため、ｏｐｌｏｇは７状態を通過するであろう。クリティカルセクションの開始の前に、ｏｐｌｏｇは非アクティブ状態であろう、すなわちそのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩｄフィールドが非アクティブに設定されるであろう。しかし、Ａの同期プリミティブの取得の前に、ＳｔｅｐＮｕｍｂｅｒが０に設定され、ｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤは１２０に設定され、これはクリティカルセクションを一意的に識別する。フィールドＡの同期プリミティブが取得された後、しかしフィールドＡにおける値が変更される前に、ｏｐｌｏｇはフィールドＡの現在値をＯｌｄＶａｌｕｅＡに格納する：この場合は３である；そしてＳｔｅｐＮｕｍｂｅｒが１に設定される。一旦フィールドＡにおける値が変更される（この場合は３から４にインクリメントされる）と、ｏｐｌｏｇのＳｔｅｐＮｕｍｂｅｒは２に変更する。その後、フィールドＡの同期プリミティブが解除され、フィールドＢの同期プリミティブが取得される。ｏｐｌｏｇは、同期プリミティブにおけるこの変更を、この実施例においては８９であるフィールドＢの前回の値を格納することにより反映し、そのＳｔｅｐＮｕｍｂｅｒを３に変更する。フィールドＢにおける値が変更された後、ＳｔｅｐＮｕｍｂｅｒは４に変更される。その後、フィールドＢについての同期プリミティブが解除される。クリティカルセクションがその後終了するので、ｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤフィールドは削除される（すなわち非アクティブに設定される）。
【００３４】
Ｏｐｌｏｇについての重要な考慮は、クライアントのアクションがｏｐｌｏｇを整合性のない状態のままにするか否かである。ｏｐｌｏｇが整合性のない状態のままにされた場合、この項に前述され、後でより詳細に論じられるｏｐｌｏｇクリーナープロセスが、整合性のないコントロールデータについて前に説明された同じ問題に遭遇するかも知れない。これを避けるべく、ｏｐｌｏｇは１以上のイネイブラフラグを有する。上に詳述されたｏｐｌｏｇの実施例について、ＳｔｅｐＮｕｍｂｅｒおよびＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤのフィールドはフラグの役割を果たす。これらの２つのフィールドは、ｏｐｌｏｇクリーナープロセスが整合性のない状態のｏｐｌｏｇを見つけるであろうことを保証するよう用いられる。初めは、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤは非アクティブであり、コントロールデータが変更されていないことを示す。そこでＳｔｅｐＮｕｍｂｅｒフィールドが０に設定され、その時になってＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤがクリティカルセクションの対応する識別子に設定される。ここで留意すべきは、ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが設定される時までに、ＳｔｅｐＮｕｍｂｅｒが既に０に設定されるため、このようなｏｐｌｏｇは整合性があることである。ｏｐｌｏｇクリーナープロセスがこの段階においてこのｏｐｌｏｇに影響しなければならないならば、これは、対応する同期プリミティブが、もし保持される場合に、解除されることを保証しようと試みるだけであろう。ｏｐｌｏｇクリーナープロセスは、コントロールデータにおける何の値も変更しないであろう。その後ｏｐｌｏｇは、ＳｔｅｐＮｕｍｂｅｒを進める前に、全ての必要な値を格納する。ｏｐｌｏｇは常に、所与のＳｔｅｐＮｕｍｂｅｒについて必要なデータを有する。このことは、ｏｐｌｏｇクリーナープロセスが、整合性のある状態にあるｏｐｌｏｇを調査し、したがってコントロールデータを整合性のある状態に進めることができることを保証する。ここで留意すべきは、所与のクライアントリクエストについて、重なるクリティカルセクションはないということである。本質的に、重なる多数の「クリティ
カルセクション」は全て、所与のクライアントリクエストについて実行されなければならず、１つのクリティカルセクションである。しかし、ネスト化したクリティカルセクションを考慮する。
【００３５】
ネスト化したクリティカルセクションの実施例は、図９に示される。クリティカルセクション１および２があるとする。クリティカルセクション１において、フィールドＡの第１の同期プリミティブが取得される。しかし、フィールドＡにおける値を変更する前に、関数呼び出しが行われる。関数呼び出しにおいて、フィールドＢの同期プリミティブを取得する他のクリティカルセクション２が存在し、フィールドＢにおける値を変更し、同期プリミティブを解除し、そして戻る。戻った後、クリティカルセクション１において、フィールドＡにおける値に変更がなされ、そしてＡの同期プリミティブが解除される。理論的には、全てのネスト化されたクリティカルセクションは１つのクリティカルセクションである。しかし、異なる関数呼び出しの組み合わせは、整合性のあるクリティカルセクションの組み合わせである、多くの異なるクリティカルセクションを引き起こすであろう。このスキームは、ネスト化したクリティカルセクションを考慮する、なぜならこれは良いソフトウェアシステム設計についてより実用的であるからである。
【００３６】
このアプローチの１つの結果は、同時に開く複数のｏｐｌｏｇ（クリティカルセクションの各インスタンスに対応する）があるであろうことである。このシステムの動作は、最も新しい（ネスト化レベルにおいては最も深い）ｏｐｌｏｇが、１レベル上がる前に、まずｏｐｌｏｇクリーナープロセスによって削除される必要があるであろうことである。ここで留意すべきは、ｏｐｌｏｇのネスト化深さは特定のアプリケーションに依り、それが何であるべきかに理論的制限はないということである。しかし、ｏｐｌｏｇのネスト化深さを最小化するシンプルなヒューリスティックがある。長く複雑なクライアントアクションは、より小さなアクションに分解されるべきであり、それらの関連するｏｐｌｏｇは、マネージドデータへの任意の影響をロールバックする前に、ロールバックプロセスがコントロールデータを削除するために用いることができる、既知の場所に格納される。クライアントアクションがより小さい場合、対応するクリティカルセクションはより複雑でなく小さい傾向があり、全体的なネスト化深さの全体は同じく小さいであろう。他のヒューリスティックは、長いクライアントアクションを一連のより小さなクライアントアクションに分解することである；そこでクリティカルセクションもまた小さくなる。
【００３７】
Ｏｐｌｏｇｇｉｎｇシステムの設計における目的の１つは、必要メモリが低くあるべきであることであると述べた。ここで留意すべきは、ｏｐｌｏｇは、コントロールデータの状態と、特定の実行があるステップとを格納することである。プロセスの終了の時、この情報は、いくつかのクリーンアッププロセスにとって利用可能である必要がある（ｏｐｌｏｇクリーナープロセスを参照して上述したように）。ｏｐｌｏｇは固定記憶域にログされることができ、ここではこれらはｏｐｌｏｇクリーナープロセスによってピックアップされて、コントロールデータの整合性を達成することができる。しかし、過度のディスク書き込みおよび読み出しは、容認できないパフォーマンスの不利益を有するかもしれない。代替案は、全てのｏｐｌｏｇをディスクの代わりにメインメモリに格納することであろう。この設計は、パフォーマンスの問題を回避する。しかし、ｏｐｌｏｇが、ＷＡＬスキームの下の従来のログが格納されるように、連続的に格納され、チェックポイントのみで消去される場合、これは過度の必要スペースを招き、したがって実用的ではない。
【００３８】
パフォーマンスの不利益と、過度の必要スペースとを回避するべく、本発明の一実施形態において、ｏｐｌｏｇはメインメモリのスタックに格納される。スタックは技術的に既知の格納構造であり、ここでは最も新しい存在が上にあり、最も古い存在が下にある。この設計において、必要スペースはｏｐｌｏｇのネスト化のレベルに等しい。また、この設計において、非アクティブのログが、存在しないｏｐｌｏｇに等しいことを前提とする。
この前提は、何ら新しい要件をもたらすものではなく、事実、ｏｐｌｏｇの設計からすると、非アクティブのｏｐｌｏｇには何らのアクションも取られず、したがってこれは存在しないようなものである。したがって、各接続について、システムが生成する可能性がある最も深いｏｐｌｏｇスタックを保持するのに充分なスペースが割り当てられる。初めは、スタックにはデータがない。ｏｐｌｏｇが必要とされる度に、これはスタックから割り当てられる。割り当てに際してｏｐｌｏｇは非アクティブである。一旦クリティカルセクションが終了して、ｏｐｌｏｇがもはや必要とされなくなると、これは非アクティブとしてマークされ、ｏｐｌｏｇスタックに確保されたスペースに戻る。
【００３９】
他の重要な部分は、ｏｐｌｏｇクリーニング機構である。直接接続クライアントの所与の環境においてさえ、いくつかのプロセスは、どのクライアントからも分離して実行され、保守タスクを行う。クライアント接続を監視するこのような分離したプロセスの１つは、接続監視デーモンである。直接接続クライアントプロセスの予期しないクライアントの消滅もしくは終了に際し、接続監視デーモンはクライアントプロセスの終了を検出し、回復を開始する。直接接続クライアント終了についての回復は、２つの部分から成る：コントロールデータを整合性のある状態にすることと、アトミック性を達成するためのマネージドデータのロールバックである。まず、接続監視デーモンが、サーバに１つの接続を有する単一のクライアントの予期しない障害を回復する方法を詳述する。そして、サーバへの複数の接続を有する複数のクライアントの問題を取り扱う必要のある設計を説明するであろう。
【００４０】
一実施形態において、マネージドデータに影響する前に、（直接接続クライアントサーバシステムにおける）直接接続クライアントは、接続監視デーモンが接続を許可することをリクエストする。接続監視デーモンがそこで、この直接接続クライアントについての情報を格納することができる。一実施形態において、既知のオペレーティングシステム設定であるソケットが用いられ、接続監視デーモンが直接接続クライアントの健全性を監視することができることを保証する。成功理に接続を確立すると、クライアントと接続監視デーモンとの間でソケットが開かれる。そこで、接続プロセスデーモンが、ソケットが予想外に閉じられことを発見した時、これによって、クライアントプロセスの予期しない終了が検出される。接続監視デーモンが、クライアントが予想外に終了したと決定する時、これはｏｐｌｏｇクリーナープロセスを呼び出す。ｏｐｌｏｇクリーナープロセスは呼び出されると、所与の接続についてアクティブである全てのｏｐｌｏｇを調査する（ｏｐｌｏｇそのものは、共有メモリに格納され、前に説明されたように、整合性のある状態である）。
【００４１】
ここで、図７から８で上述されたｏｐｌｏｇについての実施例を用いて、ｏｐｌｏｇクリーナーが取るアクションを詳述する。図７のｏｐｌｏｇについて、ｏｐｌｏｇクリーナーは、ｏｐｌｏｇがまだアクティブであるか否かを決定する。上述のように、ｏｐｌｏｇは、クリティカルセクションの前と後で非アクティブである。しかし、ＳｔｅｐＮｕｍｂｅｒ０、１および２に対応するｏｐｌｏｇについての３つの状態がある。ＳｔｅｐＮｕｍｂｅｒ  ０において、コントロールデータに何ら変更はなされなかった。したがって、ｏｐｌｏｇクリーナーは、同期プリミティブが保持されている場合、これを解除しようと試みるのみである。ＳｔｅｐＮｕｍｂｅｒが１の場合、ｏｐｌｏｇクリーナーは、ｏｐｌｏｇに記録された前回の値（ＯｌｄＶｌｕｅ）をフィールドＡに再インストールする。ＳｔｅｐＮｕｍｂｅｒが２の場合、コントロールデータは整合性があると考えられるため、ｏｐｌｏｇクリーナーは削除を行わない。しかし、クライアントアクションは同期プリミティブを解除していなかったかもしれない。クリーナーは、関連する同期プリミティブが解除されていない場合、これを解除するであろう。その後、ロールバックがこの接続に呼び出され、マネージドデータのアトミック性を保証するであろう。ロールバックの前に、ｏｐｌｏｇクリーナープロセスは、アクティブであることがわかったｏｐｌｏｇに関する全
ての同期プリミティブが解除されることを保証する。また、所与の接続によって保持される任意の同期プリミティブがロールバックの終了に際して解除される。
【００４２】
図８の複雑なｏｐｌｏｇは、対応して複雑なｏｐｌｏｇクリーナーを有する。ここで留意すべきは、この実施例には７つの状態と２つの同期プリミティブがあることである。まず、ｏｐｌｏｇクリーナープロセスは、クライアントアクションが終了したＳｔｅｐＮｕｍｂｅｒに注目する。ｏｐｌｏｇがＳｔｅｐＮｕｍｂｅｒ  ０または４にある場合、コントロールデータには何のアクションも必要とされない。ＳｔｅｐＮｕｍｂｅｒ  １において、ｏｐｌｏｇクリーナープロセスは、フィールドＡについての古い値をＯｌｄＶａｌｕｅ  Ａから再インストールする。ＳｔｅｐＮｕｍｂｅｒ  ２について、ｏｐｌｏｇクリーナープロセスは、フィールドＡについて、同期プリミティブが保持されている場合、これを解除し、アクションの残りを実行する：すなわち、フィールドＢにおける値を変更する。ＳｔｅｐＮｕｍｂｅｒ  ３について、ｏｐｌｏｇクリーナープロセスは、フィールドＢに古い値をＯｌｄＶａｌｕｅＢから再インストールし、フィールドＢの値を変更するアクションの残りを実行する。各ステップの終了時に、ｏｐｌｏｇクリーナープロセスは、フィールドＡとフィールドＢの両方について、いずれかがまだ保持されている場合、同期プリミティブを解除する。ここで留意すべきは、第２、第３のステップについての修復アクションは上述よりもさらに複雑であろうことである。修復アクションは、ｏｐｌｏｇクリーニングの終了にあたって初期化されるであろうマネージドデータについて、ロールバックの構造体に依るであろう。ロールバックが、クライアントアクションについてのクリティカルセクションが完了されることを必要とする場合、ｏｐｌｏｇクリーナープロセスは上述のステップを行う。さもなければ、ｏｐｌｏｇクリーナープロセスは、単にフィールドＡとフィールドＢについての値の変更をロールバックすることを選択することができる。たとえば、フィールドＡにおける変更がインクリメントであった場合、ｏｐｌｏｇクリーナープロセスは、ＳｔｅｐＮｕｍｂｅｒフィールドの値が２である後にデクリメントしてＡを復元することができる。最後に、この接続にロールバックが呼び出されて、マネージドデータのアトミック性を保証するであろう。
【００４３】
マルチクライアントシステムにおいて、サーバへのいくつかの接続を有する多くのクライアントが、同時に予期しない障害を起こすであろう。所与のクライアントが、他の接続されたクライアントと同時に実行するため、任意の所与のクライアントは同期プリミティブを保持して消滅するかもしれず、このことは新規の、もしくは現在接続しているクライアントの実行をブロックするか、予期しない障害を起こした他のクライアントの回復をブロックするか、である。したがって、全てのコントロールデータが整合性のある状態にされることと、またマネージドデータのロールバックが、予期しない障害を起こした全てのクライアントについて成功理に終了することとを保証し、同時に、全ての既に接続した、および新規のクライアントが進展することを保証する、特別な取り扱いが要求される。
【００４４】
この時点で、共通のタイプの同期プリミティブについてコメントが必要とされる。２つの共通の種類の同期プリミティブがある‐アプリケーションロック（通常、順序づけ、待機、およびその他のサービスと保証を提供する複雑な同期プリミティブを実行したアプリケーション）およびシステムラッチ（セマフォなどのような基本システムロック）である。全ての同期プリミティブに共通する問題は、デッドロックである。デッドロックとは、２つ以上のプロセスが互いによって取得される同期プリミティブを待機する状態である。これは、デッドロックサイクル内の任意の参加者による進展も妨げる。アプリケーションロックにおけるデッドロックは、比較的容易に見つけられる；すなわち、アプリケーションはこれらのデッドロックについての全ての情報へのアクセスを有するため、アプリケーションは、これが任意のこのようなデッドロックを発見した場合、何らかの修復アクションを取ることができる。しかしシステムラッチデッドロックに作用することは困難である。このような状態において、デッドロックサイクルに参加するプロセスは進展しない；ア
プリケーションはデッドロックの何の情報も持たず、いかなる修復アクションも不可能である。この状態は、予期しないクライアントの消滅によって、より複雑になる‐アプリケーションロックとシステムラッチの両方は、接続監視デーモンによって適切な時に解除され、現在接続されているクライアントの正確な実行を保証する必要がある。
【００４５】
接続監視デーモンが、障害を起こした各クライアントについて連続してｏｐｌｏｇクリーナープロセスを開始した場合、これはデッドロックに遭遇するであろう。代わりに、本発明の実施形態は、ｏｐｌｏｇクリーナープロセスを開始する大いに協働する設計を用いる。この解決法は、デッドロックがないであろうことを保証する。接続監視デーモンは、現在障害を起こした各クライアントの各接続について、新しいｏｐｌｏｇクリーナープロセスを開始する。当業者は、ｏｐｌｏｇクリーナープロセスは同じプロセスのスレッドでもよいこと、すなわち接続監視デーモンは新しいスレッドもしくはプロセスとしてｏｐｌｏｇクリーナーを生じる選択を有することを認識するであろう。たとえば、それぞれサーバに２つの接続を有する３人のクライアントが消滅した場合、それぞれ１つの特定の接続を削除する、６つのｏｐｌｏｇクリーナープロセスが同時に開始されることができる。プロセスが開始される順番は、それらが全て開始されるならば、問題にならない。この設計は、障害を起こしたプロセスによって取得された全ての同期プリミティブが最終的には解除され、任意のこのような同期プリミティブの無限の待機を防ぐであろうため、ｏｐｌｏｇクリーニングプロセスが行き詰まらないことを保証する。
【００４６】
上述されたＯｐｌｏｇｇｉｎｇシステムの装置は、広い適用性を有する。たとえばこれは、図表作成、インデックス作成などの部分の、データベースの分野における既知のクリティカルセクションに適用されるであろう。他のクリティカルセクションは、カーソルオープン、表カーソル、インデックスカーソル、ハッシュカーソルなど多種のカーソルの次の操作および閉じる操作を含む。クリティカルセクションのさらに他の実施例は、ツリーインデックス、ハッシュインデックスなどの一時インデックスの作成である。さらに、Ｏｐｌｏｇｇｉｎｇシステムが、内在する表および多様なインデックスの、挿入、削除、更新操作において用いられることができる。これらのクリティカルセクションは、表ページのスロットの作成もしくは削除を引き起こし、カウントおよびディレクトリなどを変更するであろう。Ｏｐｌｏｇｇｉｎｇシステムはまた、新しいログファイルを作成したり、ログファイルを開いたり、ログファイルを閉じたりといったアクションを保護するのに用いられることができる。Ｏｐｌｏｇｇｉｎｇシステムが用いられることのできるさらに他の一連の操作はロックマネージャで、ロックしたりロックを解除したりといった操作についてである。本発明の実施形態はまた、これらの技術を、ＤＢＭＳにおけるＳＱＬコマンドの編集において用いることができる。データベースのフィールドからの上述の実施例は、Ｏｐｌｏｇｇｉｎｇシステムを用いるであろうクリティカルセクションの完全なリストであるよう意図されてはいない。代わりにこれらは、ｏｐｌｏｇｇｉｎｇの恩恵を受けることができるクリティカルセクションの種類を与えるよう意図されている；潜在的使用はより広い。
【００４７】
Ｏｐｌｏｇｇｉｎｇシステムは複雑で扱いにくく見えるであろう。しかし、Ｏｐｌｏｇｇｉｎシステムの実際の実施の結果は大変有望である。ある試験において、たった１２５のクリティカルセクションおよび対応するｏｐｌｏｇだけが必要とされた。ｏｐｌｏｇは、ｏｐｌｏｇについての最大のネスト化深さが１１であるため、深さ１１のスタックに格納された、したがって、コントロールデータ内の全ての変化をｏｐｌｏｇするのに最小のメモリオーバーヘッドがある。さらに、パフォーマンス結果は良好である。Ｏｐｌｏｇｇｉｎｇシステムの付加は、１人のクライアントがサーバに直接接続する時にスループットの減少を１０％より少なくした；複数のクライアントがサーバに接続する時、認識できる減速はない。試験は、Ｏｐｌｏｇｇｉｎｇシステムが、直接接続クライアントに障害がある時にサーバコンポーネントの連続可用性を保証するのに効果的な技術であることを示す
。
【００４８】
図１は、データ（マネージドデータといくつかの永続コントロールデータの両方）６と、プロセッサ４（中央演算装置（ＣＰＵ））と、プロセッサ４と通信するメインメモリモジュール８とを含む、直接接続クライアントサーバシステムと示す。一実施例におけるプロセッサ４とメモリ８を含むコンピュータ機器２はサーバである。コンピュータ機器２は、直接接続クライアントサーバシステム１０のためのソフトウェアを格納し、実行する。直接接続クライアントサーバ１０は、Ｏｐｌｏｇｇｉｎｇシステム２０と呼ばれるモジュールを含む。プロセッサ４は、サーバ２において、アドレス可能な共有メモリ６と共に動作する単一のＣＰＵもしくは複数のＣＰＵであろう。データ８は一般的に、このような装置は１つしか図１に示されないが、複数の直接アクセス記憶装置（ＤＡＳＤ）に格納される。所望であれば、データ６は唯一のＤＡＳＤにのみ格納されることができることを、当業者は認識するであろう。さらに、当業者は、任意のその他のコンピュータ読みとり可能な媒体が用いられてデータ６を格納できることを認識するであろう。ＤＡＳＤは、たとえばディスクパックであり、データベースシステムは、データ６とプロセッサ４との間の通信を確立する、要求されるＤＡＳＤコントローラおよびチャネルを含むということが当業者にとって理解されるであろう。他の実施形態において、データ８は、メインメモリ８そのものの中に格納されるであろう。図１に示されないものは、サーバ２の他のコンポーネントである：たとえば、キーボード、マウス、またはモニタである。さらに、サーバ２は「サーバ」と呼ばれるが、任意のマシンが、特に「サーバ」と呼ばれることなく目的を果たすことができることを、当業者は認識するであろう。たとえば、デスクトップコンピュータ、ノートブックコンピュータ、もしくは適切に調整された任意のその他のコンピュータ機器が、「サーバ」２として目的を果たすことができる。
【００４９】
ターミナル１は、ユーザからリクエストを受け入れ、ユーザに結果を戻す、任意の入力／出力（Ｉ／Ｏ）装置である。たとえばターミナルは、パーソナルコンピュータ（ＰＣ）、もしくは広告アプリケーションプログラマインタフェイス（ＡＰＩ）を用いるアプリケーションであろう。リクエストはクライアントによって、ターミナル１から投稿され、直接接続クライアントサーバシステム１０によって、そのＯｐｌｏｇｇｉｎｇシステム２０と連動して同時に処理される。
【００５０】
ターミナル１は、サーバ２に直接接続されてもよく、サーバ２にネットワーク（図１には示されない）を介して接続されてもよい。ターミナル１がサーバ２にネットワークを介して接続される場合、ネットワークは任意の形状であってよい。たとえば、ネットワークは、ローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）を介して接続される直接ケーブル接続（ターミナル１とサーバ２の間に何らの媒介リンクがない場合）であってよく、もしくはインターネットなどのグローバルネットワークであってよい。さらに、ターミナル１とサーバ２との間の接続は、ワイヤ接続であってもよく、またはワイヤレス接続であってもよい。接続がワイヤレスである場合、任意のワイヤレスタイプの接続が用いられることができる。たとえば、ＩＥＥＥ  ８０２．１１ａ／ｂ／ｇスタンダードに、もしくはＢｌｕｅｔｏｏｔｈ（登録商標）スタンダードに、適合する任意の接続が用いられることができる。
【００５１】
図２は、Ｏｐｌｏｇｇｉｎｇシステム２０のより詳細を示す。Ｏｐｌｏｇｇｉｎｇシステムはコントロールデータの整合性を維持することをサポートする。まず、新しいクライアントアクションを実行し、障害のないクライアントについて連続のクライアントアクションを実行する能力を、いかにＯｐｌｏｇｇｉｎｇシステムが提供するかを説明し、次いで図２に提示される概略図を詳細に説明する。従来のログ３０は、１つのデータ６が格納されているように、記憶装置に保持される。これらのログは、障害がある場合にシステムを回復し、マネージドデータのアトミック性を維持することをサポートするのに用いられ
る。これらのログは、直接接続クライアントサーバシステム１０の、マネージドデータの変更についてのみ書き込まれ、コントロールデータの変更については書き込まれない。一実施形態において、メモリ内のデータ８のイメージは、３つのセグメントに分割される。第１のセグメント８１は、コントロールデータである。このデータは、データベースの構造体についてのメタデータと、現在開いているクライアントアクションとそれらの状態についての情報とを定義し、本質的に、これはコントロールデータである。Ｏｐｌｏｇ８２は、クライアントプロセスを実行する代わりにコントロールデータについての情報を格納するために確保されている領域である。データ８３は、直接接続クライアントサーバシステムのマネージドデータを格納するセグメントである。データ８の前のイメージは、データイメージ６として任意のＤＡＳＤに格納される。データへの任意の変更について、マネージドデータログ３０が生成され、ＤＡＳＤに送られる。このことは、クリティカルセクションの途中に消滅した、障害のあったクライアント１０１などの、クライアントの予期しない障害に際し、ｏｐｌｏｇシステム２０が引き継ぐことができ、障害のあったクライアントプロセスに対応する任意のｏｐｌｏｇ８２を発見し、コントロールデータに対する任意の影響を取り消してこれを整合性のある状態にし、次いでクライアントの代わりに実行するアクションにロールバックを呼び出すことを保証する。このことは、マネージドデータログ３０とデータイメージ６とを用いて、マネージドデータに従来のロールバックを遂行するであろう。したがって、Ｏｐｌｏｇｇｉｎｇシステム２０は、クライアントプロセス１０１の予期しない障害に際しても、他のクライアントへの直接接続クライアントサーバシステムの連続的な可用性を保証する。
【００５２】
ここで、図２に提示される概略図を詳細に規定する。ここで留意すべきは、直接接続クライアント１０１の相互作用と、直接接続クライアントサーバシステム１０のクライアントパートと、Ｏｐｌｏｇｇｉｎｇシステム２０、ｏｐｌｏｇ生成部２０１、ｏｐｌｏｇ８２、接続監視デーモン２０２、およびｏｐｌｏｇクリーナープロセス２０３の精成とに注目することである。直接接続クライアント１０１は、メーカー供給のサーバライブラリ１０１１を用いるアプリケーションから成る。ｏｐｌｏｇ生成部２０１は、サーバライブラリ１０１１の一部である。Ｏｐｌｏｇ生成部２０１は、直接接続クライアント１０１がクリティカルセクションにある時、ｏｐｌｏｇを生成する。クライアント接続１０１がクリティカルセクションに入る時、ｏｐｌｏｇ生成部２０１は、共有メモリ８のｏｐｌｏｇ領域８２にｏｐｌｏｇを作成する。接続監視デーモン２０２は、各直接接続クライアント１０１と開かれるソケットを有する。特定のクライアントが予期せず終了する時、接続監視デーモンとのソケット接続は切られる。このことは、図２の第２の直接接続クライアントに示される。接続監視デーモン２０２は、ソケット接続のこの予期しない切断を、直接接続クライアントの予期しない終了の指示として用いる。任意の直接接続クライアントサーバ１０１の予期しない障害に際し、接続監視デーモン２０２は、障害のあったプロセスにおいてアクティブであった各接続についてｏｐｌｏｇクリーナープロセス２０３を開始する。ここで留意すべきは、図２に示されるように、複数のｏｐｌｏｇクリーナープロセス２０３が開始されるであろうことである。ｏｐｌｏｇクリーナープロセス２０３は接続を引き継ぎ、障害のあったクライアントについてｏｐｌｏｇ領域８２に存在する任意のアクティブなｏｐｌｏｇを探し、障害のあったクライアントによってコントロールデータになされた任意の変更を取り消す。これは、マネージドデータログ３０を用いてロールバックを受けることができる、コントロールデータをマネージドデータについて障害のあったクライアントの全てのアクティブなアクションから、整合性のある状態に戻す。共有データとコントロールデータの両方についてデータベースを整合性のある状態に戻すプロセスおよび、障害のあったクライアントアクティブなアクションをロールバックするプロセスは、障害のなかった他のアクティブなクライアントに対してサーバシステムが連続的に可用であり続ける間に行われる。
【００５３】
コントロールデータを変更するクリティカルセクションの間におけるプロセスの障害が
ある際にも、直接接続クライアントサーバシステムの連続的な可用性を提供するために、ｏｐｌｏｇをどのように用いられることができるかについての多くの実施例がある。前に言及されたように、本書において全ての可能性を列挙することは不可能である；しかし、本書に概説された装置の３つの異なる適用を見ることにより、可能性の種類を提供することを目指す。まず、シンプルなクリティカルセクション操作「所与の表上でカーソルを開く」におけるｏｐｌｏｇｇｉｎｇテクニックの比較的シンプルな適用を説明する。このような操作は、クライアント接続によりデータを利用するためにしばしば用いられる。データアクセスの不可欠な部分を形成する他の操作は、「カーソルを考慮し次の値を得る」と「カーソルを閉じる」である。いかに連続的可用性が達成されるかを説明するため、初めのものを説明する。次に、クライアントプロセスの障害に際してリンクリストの完全性を維持することが必要な場合に、二重にリンクリストを変更する、ｏｐｌｏｇの適用を説明する、さもなければ次のクライアント接続が無制限にループするか、割り当てられないメモリにアクセスして、それ自身が障害を起こすかである。第３に、ループ状態にあるｏｐｌｏｇｇｉｎｇテクニックの適用を説明する。ここで、操作は、同様のアクションを繰り返し行うことから成り、ループの実行は整合性を保証するために、完結するか、ロールバックするかする必要がある。これらの実施例は、ｏｐｌｏｇｇｉｎｇテクニックの広い適用性の種類を提供するであろう。
【００５４】
図３は、クライアントの終了に際して直接接続クライアントサーバシステム８の可用性を保証する、シンプルなクリティカルセクション操作と、ｏｐｌｏｇの設計との詳細を示す。ＤＢＭＳの実施例を取り上げる。コントロールデータ８１が３つの部分から成ることを前提とする。カーソル構造体８１１は、カーソルについての情報をデータ８に格納する。トランザクション構造体８１２は、トランザクションについての情報をシステムに格納する。表構造体８１３は、所与の表についての情報を格納する。クライアントプロセスがメーカー供給のライブラリ１２を用いてデータ８内のデータにアクセスする時、「所与の表上にカーソルを開く」操作が行われるであろう。
【００５５】
コントロール構造体８１１、８１２、および８１３の初期および最終の状態を示し、「所与の表上にカーソルを開く」操作がいかにコントロール構造体に影響を及ぼすかを説明する。初期状態において、トランザクション８１２２はカーソルを開いていなかった。したがって、そのカーソルフィールド８１２３は空値である。同様に、カーソル８１１１は用いられておらず、したがってその表フィールド８１１２は空値である。同様に、表ヘッダ８１３１は、表上でどのカーソルも開いておらず、したがってカーソルカウント８１３２は０の値を有することに留意する。トランザクション８１２２についての「所与の表上にカーソルを開く」操作が、表８１３１について成功理に終了する時、最終段階に到達する。最終段階において、トランザクション８１２２は、そのフィールド８１２３に格納され、カーソル８１１１を指すカーソルポインタを有する。カーソル８１１１は同様に、表８１３１を指すよう初期化された表ポインタ８１１２を有する。表ヘッダ８１３１は、その上で開くカーソルを有したので、そのカーソルカウントフィールド８１３２はここで１である。
【００５６】
このクリティカルセクション操作の実行の間、任意の時に何らかの障害がクライアントプロセスに起きた場合、コントロールデータ８１は、どのカーソルもそれを指さない時に表ヘッダ（８１３１）のカーソルカウントフィールド８１３２がゼロでない、整合性のない状態のままであろう。もしくは、カーソル８１１１がそれを指すその表ポインタフィールド８１１２を有する場合に、これはゼロであろう。障害が起こった時に無関係であり、実際、整合性のある初期もしくは最終状態へ進むことができることを確認することが必要である。
【００５７】
ｏｐｌｏｇ構造体８２１は、コントロール構造体になされる変更を追跡するのに用いら
れるｏｐｌｏｇの１状態の詳細を提供する。ＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤおよびＳｔｅｐＮｕｍｂｅｒ以外に、これはトランザクションナンバー（ＸＡＣＴ）、カーソル識別子（ＣＵＲＳＯＲ）、表識別子（ＴＡＢＬＥ）、および表の前回のカーソルカウント（ＣＯＵＮＴ）を格納する。したがって、操作「所与の表上にカーソルを開く」が成功理に終了する前に、すなわちシステムが最終状態に到達してｏｐｌｏｇのＣｒｉｔｉｃａｌＳｅｃｔｉｏｎＩＤが非アクティブに設定される前に、何らかの障害がクライアントプロセスに起きれば、Ｏｐｌｏｇｇｉｎｇシステムはｏｐｌｏｇ８２１を用いて、クリティカルセクション操作「所与の表上にカーソルを開く」の実行の任意の影響を取り消すことができる。とりわけ、ｏｐｌｏｇクリーナープロセスが、実施例に言及される状態のｏｐｌｏｇ８２１をピックアップする場合、これはシンプルに、トランザクション８１２２のカーソルポインタフィールド８１２３に空値を再インストールするであろう。これは、カーソル８１１１の表ポインタフィールド８１１２に空値をインストールし、表ヘッダ８１３１のカーソルカウントフィールド８１３２を、所与の場合は０である操作ｏｐｌｏｇ８２１に格納されたカウントに、リセットする。したがって、ｏｐｌｏｇｇｉｇシステムは、これがクライアントプロセスについて発見する任意のアクティブなｏｐｌｏｇ８２１の影響を取り消す。この時点で、ｏｐｌｏｇｇｉｇシステムは、クライアントプロセスにロールバックを呼び出し、これは、クライアントプロセスが有したであろう任意のマネージドデータ影響を取り消す。したがって、ｏｐｌｏｇｇｉｇシステムは、クライアントサーバシステム内のコントロールデータとマネージドデータの両方に整合性があり、連続的に可用であることを保証する。
【００５８】
図４は、上述したｏｐｌｏｇｇｉｎｇ原理の適用の、さらに他の実施例を提供する。データベースにおける既知かつ一般的な操作は、リンクリストの保守である。図４は、このような実施例を示す。データ８のコントロールデータセグメントは、２つのリンクリスト、リスト１とリスト２とから成る。各リストはアイテム８０から作られる。アイテム８０は、データ８０１、次８０２および前８０３の３つのフィールドから成る。操作はエレメントをリスト２のヘッドからリスト１のヘッドに送る。
【００５９】
８１４の初期状態において、リスト１は２つの部分アイテム１．１とアイテム１．２とを有する。これらは、二重リンクリストとして既知のテクニックにリンクされる。このスキーム下で、リストはアイテム８０を指す。アイテム８０の次のフィールド８０２は、次のアイテム８０を指し、前のフィールド８０３は、リストの前のアイテム８０を指す。同様に、リスト２は、２つの部分アイテム２．１とアイテムとから成る。操作は、リスト２からリスト１のヘッドへ送られるアイテム２．１を識別する。コントロール構造体セグメント８１４の最終状態において、アイテム２．１がリスト１のヘッドに送られたことが発見される。ここで留意すべきは、このことはリスト１、リスト２、アイテム２．１の次のフィールド８０２、アイテム２．２の前のフィールド８０３、アイテム２．１の前のフィールドにおける変更を必要とすることである。ｏｐｌｏｇｇｉｇ（登録商標）システム２０を介するアトミック性と整合性を保証するため、新しいｏｐｌｏｇ８２２を作成する。通常のフィールド以外に、このｏｐｌｏｇは、第１のリストを指すフィールドＬＩＳＴＡ、第１のリストの次のＬＩＳＴＡＮＥＸＴ、第２のリストのＬＩＳＴＢ、ＬＩＳＴＢからＬＩＳＴＡへ動かす必要があるアイテムであるＬＩＳＴＢＣＵＲ、ＬＩＳＴＢＣＵＲからのＬＩＳＴＢの次のアイテムであるＬＩＳＴＢＮＥＸＴ、およびＬＩＳＴＢＣＵＲアイテムからのＬＩＳＴＢの前のアイテムであるＬＩＳＴＢＰＲＥＶから成る。クライアントプロセスがクリティカルセクション操作「リスト間でエレメントを送る」を実行する場合、まず、８２２のリストフィールドのそれぞれについて詳細を格納するｏｐｌｏｇ８２２を作成する。
【００６０】
操作「リスト間でエレメントを送る」の実行中に何らかの障害がある場合、ｏｐｌｏｇｇｉｇシステム２０は、クライアントプロセスに代わって実行していたトランザクション
を引き継ぎ、削除するであろう。ここで留意すべきは、整合性のある状態に達するため、操作を完了する、すなわち最終状態に達することができ、もしくは初期状態で終了することができることである。この操作の動作を考慮し、初期状態で終了する必要があることを前提としよう。また、ここで留意すべきは、ｏｐｌｏｇは、ＳｔｅｐＮｕｍｂｅｒが３である所与の状態にあることである。Ｏｐｌｏｇｇｉｇシステム２０はまず、ｏｐｌｏｇ８２を探し、消滅したクライアントプロセスに関連するｏｐｌｏｇ８２２を発見するであろう。状態３を考慮し、ｏｐｌｏｇｇｉｇシステムは次のステップを取り、リスト１およびリスト２を初期状態に修復するであろう。
【００６１】
・この場合はリスト１であるＬＩＳＴＡへ行く。
・リスト１が、この場合はアイテム１．１であるＬＩＳＴＡＮＥＸＴを指すようにする。
【００６２】
・アイテム１．１へ行き、前回ポインタ８０３を空値に設定する。したがって、リスト１はここで元と同じに見える。
【００６３】
・次に、この場合はリスト２であるＬＩＳＴＢが実行される。リスト２は、この場合はアイテム２．１であるＬＩＳＴＢＣＵＲを指すように設定される。
【００６４】
・アイテム２．１の次のフィールド８０２が、この場合はアイテム２．２であるＬＩＳＴＢＮＥＸＴを指すように設定される。
【００６５】
・最後に、アイテム２．１の前のフィールド８０３が、この場合は空値であるＬＩＳＴＢＰＲＥＶを指すように設定される。
したがって、Ｏｐｌｏｇｇｉｎｇシステムは、コントロールデータセグメント８１４がここで初期状態であることを保証する。これは次いで、まだ保持されている任意の同期プリミティブを解除するであろう。その後ロールバックがクライアント接続に呼び出される。
【００６６】
図５は、繰り返されるクリティカルセクション操作の詳細を提供する。この操作は、これがループを終了するまで完了すると考えられない。したがって、データベースシステム１０について整合性のある唯一の状態は、コントロールデータセグメントが最終状態にある時であろう。これは、一旦クリティカルセクション操作「ループしない」が開始すると、唯一の受け入れ可能な最終状態である。インデックスノート８１５１を考慮する。これは、ヘッダ情報以外に、以下のサブコンポーネントを有する；エントリ８１５１２から８１５１８の７エントリについて、ノードおよびスペースにおけるエントリの数を格納する、フィールド長さ８１５１１である。このノードについて留意すべきは、値はコンパクトに格納される、すなわち値は常に一緒にあり、エントリフィールドにおける値はエントリ８１５１２から開始することである。エントリ８１５１３における値を削除したばかりであることを前提としよう。それを行った後、インデックスノードについて唯一の整合性のある状態は最終状態にある。エントリ８１５１３における値を削除した時、値がコンパクトに格納されることを保証するため、ホール移動プログラムを呼び出す。ここで留意すべきは、一旦エントリ８１５１３における値が削除されると、値がもう存在しないと考え、そのエントリをホールと呼ぶことである。整合性を維持するため、全てのホールはリストの最後にあるべきである。長さ８１５１１を４に設定する。ホール移動は、ホールがリストの最後に移動することを保証するであろう。繰り返しは、ＭＨ．２からＭＨ．７のラインにある。繰り返しは、ホール変動が８１５１１＋長さ（８１５１１における）よりも大きくなるまで続く。またｏｐｌｏｇ８２３を用いてｏｐｌｏｇｇｉｎｇを行うということにまた留意すべきである。ｏｐｌｏｇに、ノード識別子、ノードの長さ、ホールの位置を格納する。一旦ホール移動が完了すると、インデックスノード８１５１は最終状態にあり、ｏｐｌｏｇ８２３は非アクティブ化される。
【００６７】
直接接続クライアントサーバシステム１０におけるマネージドデータのコントロールデータの整合性と、トランザクションのアトミック性とを保証するため、Ｏｐｌｏｇｇｉｎｇシステム２０は、ホール移動プログラムの実行の間にクライアントが障害を起こしたときはいつでも、引き継ぐであろう。その時点で、Ｏｐｌｏｇｇｉｎｇシステムはホール移動プログラムを再度実行するであろうが、これはラインＭＨ．１のループの状態にあるホールを、ｏｐｌｏｇ８２３．ＨＯＬＥに設定するであろう。たとえば、ホール移動におけるコード実行が、ホールが８１５１５だった時に、クライアントプロセスが消滅した場合、Ｏｐｌｏｇｇｉｎｇシステム２０はホール移動において再度繰り返し、インデックスノード８１５１について最終状態をもたらすであろう。その時点で、Ｏｐｌｏｇｇｉｎｇシステムは、クライアントプロセスについて実行中であったトランザクションにロールバックを呼び出し、データ整合性とアトミック性とを保証することができる。
【００６８】
図６Ａおよび６Ｂは、本発明の実施形態にしたがった、図１のｏｐｌｏｇを用いて図１の直接接続クライアントサーバシステムを修復する手順を要約する。図６Ａにおいて、ステップ６０５で、直接接続クライアントサーバシステムは、クライアントがデータベースに直接接続することを許可する。ステップ６１０で、Ｏｐｌｏｇｇｉｎｇシステムはクライアントによってデータになされる変更をログする。ステップ６１５で、システムはチェックしてクライアントに障害が起きたかどうかを見る。起きていたら、次にステップ６２０で、システムは、クライアントによってなされた変更を識別する。
【００６９】
ステップ６２５（図６Ｂ）において、システムは、変更が取り消せるかどうかを決定する（それらが完了していなかったことを前提として）。その場合は、次にステップ６３０で、システムはクライアントによってなされた変更を取り消す。このような変更の実施例は、図３および４を参照して上述したように、表を開いた状態のままにすることと、もしくはリスト間でエレメントを動かすこととを含む。そうでなければ、ステップ６３５で、システムは変更を完了する。このような変更の実施例は、図５を参照して上述したように、ホールをリストの最後に動かすことである。ここで留意すべきは、全ての場合において、クライアントによってなされる変更が取り消され、もしくは完了され、コントロールデータが整合性のある状態にされたことを保証する充分な情報が、利用可能であることが必要であることである。ステップ６３０および６３５のうちの一方が行われることは意味がない：コントロールデータへの変更は、状況に依って、ロールバックされるか完了されるかされる。システムの構造は、コントロールデータが１つの方法もしくは他の方法で整合性のある状態に置かれるようなものである；コントロールデータは整合性のない状態のままにされない。
【００７０】
以下の論議は、本発明のいくつかの態様が実施されるであろう適切なマシンの、簡潔な、一般的な説明を提供しようと意図される。一般的に、マシンは、プロセッサ、メモリ、たとえばランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、もしくはその他の状態保持媒体、記憶装置、ビデオインタフェイス、および入力／出力インタフェイスポートが取り付けられる、システムバスを含む。マシンは、少なくとも部分的に、キーボード、マウスなどの従来の入力装置からの入力によって、および他のマシンから受け取った指示、バーチャルリアリティ（ＶＲ）環境との相互作用、バイオメトリックフィードバック、もしくはその他の入力信号によって、制御されるであろう。ここでは、「マシン」の用語は、単一のマシン、もしくは共に動作する、通信で結合されたマシンもしくは装置のシステムを広く包含するよう意図される。典型的なマシンは、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、ハンドヘルド装置、電話、タブレットなどのコンピュータ装置を含む。
【００７１】
マシンは、プログラム可能もしくはプログラム不可能な論理回路もしくはアレイ、特定
用途向け集積回路、内蔵コンピュータ、スマートカード、などの内蔵されたコントローラを含むであろう。マシンは、ネットワークインタフェイス、モデム、もしくはその他の通信結合などを通じるなどして、１以上のリモートマシンへの１以上の接続を用いるであろう。マシンは、イントラネット、インターネット、ローカルエリアネットワーク、広域ネットワークなどの物理的および／もしくは論理的ネットワークを手段として、相互接続されるであろう。ネットワーク通信は、無線（ＲＦ）、人工衛星、マイクロ波、電子電気技術者協会（ＩＥＥＥ）８０２．１１、Ｂｌｕｅｔｏｏｔｈ（登録商標）、可視光線、赤外線、ケーブル、レーザーなどを含む、多様な有線および／もしくはワイヤレスの短距離もしくは長距離キャリアおよびプロトコルを用いるであろうことを、当業者は理解するであろう。
【００７２】
本発明は、機能、手順、データ構造体、アプリケーションプログラムなどを含む、関連するデータを参照することにより、もしくはそれとともに、説明され、これは、マシンによってアクセスされた時、タスクを行う、もしくは抽象データ型もしくは低レベルハードウェアコンテキストを規定するマシンをもたらす。関連するデータは、たとえば、たとえばＲＡＭ、ＲＯＭなどの揮発性および／もしくは不揮発性メモリ、もしくはその他の記憶装置、および、ハードドライブ、フロッピー（登録商標）ディスク、光学式記憶、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、生物学的記憶装置などを含む、それらに関連した記憶媒体に格納されるであろう。関連するデータは、パケット、シリアルデータ、パラレルテータ、伝播信号などの形状である物理的および／もしくは論理的ネットワークを含む、伝送環境を越えて配信され、圧縮された、もしくは暗号化されたフォーマットで用いられるであろう。関連するデータは分散環境で用いられ、マシンアクセスについて局所的におよび／もしくは離れて格納される。
【００７３】
説明された実施形態を参照して、本発明の原理を説明し、図解したが、説明された実施形態が、このような原理から離れることなく、配置および詳細において変更されることが認識されるであろう。また、前述の論議は特定の実施形態に焦点が当てられたが、他の構成が意図される。とりわけ、「一実施形態において」などという表現がここで用いられるが、これらのフレーズは通常、実施形態の可能性を参照するよう意味され、本発明を特定の実施形態の構成に限定するよう意図されるものではない。ここでは、これらの用語は、他の実施形態と組み合わせ可能な、同じ、もしくは異なる実施形態を参照するであろう。
【００７４】
結果として、ここに説明される実施形態への多種多様な置換を考慮して、この詳細な説明および関連する構成要素は一例に過ぎず、本発明の範囲を限定するものとして考えられるべきではない。したがって、本発明として請求されるのは、以下の請求項の範囲と精神の中に入るであろうこのような変更の全てと、その同等物であろう。
【図面の簡単な説明】
【００７５】
【図１】本発明の実施形態にしたがった、ｏｐｌｏｇｇｉｎｇをサポートする、直接接続クライアントサーバシステムの線図である。
【図２】本発明の実施形態にしたがった、図１の直接接続クライアントサーバシステムにおけるｏｐｌｏｇｇｉｎｇの詳細を示す概略図である。
【図３】本発明の実施形態にしたがった、代表的なクリティカルセクション「表上でカーソルを開く」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図４】本発明の実施形態にしたがった、代表的なクリティカルセクション「リンクリスト間でエレメントを送る」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図５】本発明の実施形態にしたがった、代表的なクリティカルセクション「リストからホールを移動させる」についての図１のｏｐｌｏｇのインスタンスを示す概略図である。
【図６Ａ】本発明の実施形態にしたがった、コントロールデータを整合性のある状態にし、図１のクライアントサーバのマネージドデータになされた任意の変更をロールバックする、図１のｏｐｌｏｇを用いる手順を示す。
【図６Ｂ】本発明の実施形態にしたがった、コントロールデータを整合性のある状態にし、図１のクライアントサーバのマネージドデータになされた任意の変更をロールバックする、図１のｏｐｌｏｇを用いる手順を示す。
【図７】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【図８】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【図９】本発明の実施形態にしたがった、クリティカルセクションと、関連するｏｐｌｏｇの実施例を示す。
【国際調査報告】
2008517374.tif 000013
2008517374.tif 000014
2008517374.tif 000015