JP2000035912A - ディレクトリ・サーバ - Google Patents

Abstract

(57)【要約】 【課題】 高ヒット率を確保する。高キャッシュ効率を
確保する。 【解決手段】 ディレクトリ情報を記憶するデータベー
スＤＢ９を備えたディレクトリ・サーバ１において、ア
クセス別分割ＬＲＵ管理部５は、アクセス別ＬＲＵリス
ト７を用い、キャッシュ格納をアクセス要求の種類別に
分割してＬＲＵ管理する。属性管理部８は、アクセス要
求毎に必要属性リストを作成し、必要属性のみをキャッ
シュに格納する。 【効果】 ある１つの種類の検索要求によって大量のエ
ントリがＤＢから抽出されても他の種類のエントリがキ
ャッシュから削除されず、高ヒット率を確保できる。ア
クセス頻度の低い属性がキャッシュを消費することを防
止でき、高いキャッシュ効率を確保できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディレクトリ・サ
ーバに関し、さらに詳しくは、高ヒット率、高キャッシ
ュ効率を確保可能なディレクトリ・サーバに関する。

【０００２】

【従来の技術】ＣＣＩＴＴの勧告であるＸ．５００（Ｉ
ＳＯ９５９４）準拠のディレクトリ・サービスは、図３
５に示すディレクトリ・ツリー１０２のような木構造と
して階層管理されたデータモデルを有する。木の枝葉に
相当する個所には、ディレクトリ・エントリ１０３が配
置される。各々のエントリ１０３は、階層情報を含む名
称（ＤＮ：Distinguished Ｎame）で一意に識別され
る。図３５に示すように、エントリ１０３には、ユーザ
のメールアドレス、姓名、電話番号、ＦＡＸ番号、写真
等、様々な情報を属性として記憶可能である。このよう
なディレクトリ・サービスは、電子メールシステムにお
ける電子的な電話帳として利用できる。またＸ．５００
は、クライアント−サーバ型の分散システムアーキテク
チャを採用しており、クライアントおよびサーバの役割
を担う情報処理装置間の通信プロトコルとしてＯＳＩ
（Open Systems Interconnection）の７レイヤ構造に従
ったＤＡＰ（Directory Access Protocol）を規定して
いる。

【０００３】一方、インターネットにおける標準化機関
であるＩＥＴＦ（Internet Engineering Task Force）
は、ＴＣＰ／ＩＰ上のクライアント−サーバ間プロトコ
ルとして「ＬＤＡＰ：Lightweight Directory Access P
rotocol（ＲＦＣ１７７７）」を標準化した。図２２お
よび図２３は、ＲＦＣ１７７７として規定されたＬＤＡ
Ｐのアクセス要求の一部であり、ＩＳＯ８８２４として
規定された抽象構文記法１（ＡＳＮ．１：Abstract Syn
tax Notation One）を用いて表記している。

【０００４】図２２において、Search６１は、ディレク
トリ・エントリを検索するアクセス要求である。検索系
のアクセス要求は、リード、リスト、サーチの３種に大
別できる。この３種の検索系のアクセス要求を指示する
手段として、３つのスコープがSearch６１に定義されて
いる。リード要求は、特定の１エントリを抽出する要求
である。クライアントは、スコープとして、baseObject
６２を指定する。リスト要求は、あるエントリの直下に
位置するエントリ（子エントリ）を抽出する要求であ
る。スコープとして、singleLevel６３を指定する。サ
ーチ要求は、ディレクトリ・ツリーの部分木を対象に、
条件を満足するエントリをすべて抽出する要求である。
スコープとして、wholeSubtree６４を指定する。

【０００５】図２３において、Add６５はエントリを追
加するアクセス要求、Delete６６はエントリを削除する
アクセス要求、Modify６７はエントリ中の属性値を変更
するアクセス要求、ModifyRDN６８はエントリ名を変更
するアクセス要求である。

【０００６】図２２と図２３に示すアクセス要求以外に
も、コネクションを開始するBind、コネクションを切断
するUnbind、エントリ中の属性値を比較するCompare等
のアクセス要求がプロトコル要素としてＲＦＣ１７７７
で規定されている。

【０００７】ディレクトリ・サーバは、ディレクトリ・
クライアントが発行したアクセス要求（図２２、図２
３）を受け取り、ディレクトリ・エントリの情報が格納
されたデータベース（以下、ＤＢと記す）にアクセスす
る。アクセス要求がSearch６１等の検索系である場合、
指定された条件に合致したエントリをＤＢから抽出し、
ディレクトリ・クライアントへ返す。一方、アクセス要
求がAdd６５、Delete６６、Modify６７等の更新系であ
る場合、ＤＢ上のディレクトリ情報を更新し、結果をク
ライアントへ返す。これらアクセス要求によって、ディ
レクトリ・サーバは、ＤＢから抽出したエントリのすべ
ての情報を内部メモリ上のキャッシュに格納する。これ
はエントリ・キャッシュと呼ばれる。次回の同一エント
リへのアクセス時は、キャッシュに格納されたエントリ
・データを利用することにより、ＤＢへのアクセス頻度
を減らし、応答性能を向上している。

【０００８】一般に、ディレクトリ・サーバは、ＬＲＵ
（Least Recently Used）と呼ばれるキャッシュ置換ア
ルゴリズムを用いてキャッシュ格納を管理する。ＬＲＵ
は、エントリのアクセス順序を記憶しておき、キャッシ
ュに格納されたエントリ数が予め設定された最大数を越
えそうになると、最も過去にアクセスされたエントリを
キャッシュから破棄した上で新たなエントリを格納する
アルゴリズムである。

【０００９】従来のディレクトリ・サーバは、エントリ
を一本のＬＲＵリストとして管理しており、最新に使用
したエントリをＬＲＵリストの先頭に加えると共に、Ｌ
ＲＵリストのエントリ数が予め設定された最大数を越え
そうになればＬＲＵリストの末尾のエントリから順に削
除する。前記最大数は、ディレクトリ・サーバの起動時
に運用管理者が設定可能である。

【００１０】

【発明が解決しようとする課題】前記リスト要求または
前記サーチ要求を用いた場合、ディレクトリ・ツリーの
規模によっては、１つの検索要求に対して大量のエント
リがＤＢから抽出される場合がある。ところが、従来の
ディレクトリ・サーバでは、キャッシュが１本のＬＲＵ
リストで管理されていたため、大量のエントリがＤＢか
ら抽出された場合、１つの検索要求によりキャッシュの
内容が一掃されることがある。つまり、それまでアクセ
ス頻度の高かったエントリが、１つの検索要求によりキ
ャッシュから削除されてしまい、ヒット率を低下させる
という問題点があった。

【００１１】また、従来のディレクトリ・サーバは、ア
クセスされたエントリが持つ全ての属性をキャッシュに
格納するため、アクセス頻度の低い属性がキャッシュを
消費してしまい、キャッシュ効率を低下させるという問
題点があった。

【００１２】そこで、本発明の第１の目的は、１つの検
索要求によって大量のエントリがＤＢから抽出されて
も、ヒット率の高かったエントリを一掃せずに、高ヒッ
ト率を確保可能なディレクトリ・サーバを提供すること
にある。

【００１３】また、本発明の第２の目的は、アクセス頻
度の低い属性がキャッシュを消費することを防止でき、
高いキャッシュ効率を確保可能なディレクトリ・サーバ
を提供することにある。

【００１４】

【課題を解決するための手段】第１の観点では、本発明
は、ディレクトリ情報を記憶するデータベースを備えた
ディレクトリ・サーバにおいて、エントリのキャッシュ
格納をアクセス要求の種類別に分割してＬＲＵ管理（Ｌ
ＲＵアルゴリズムによるキャッシュ管理）するアクセス
別分割ＬＲＵ管理手段と、アクセス要求毎に必要属性の
みをキャッシュ格納する属性管理手段とを有することを
特徴とするディレクトリ・サーバを提供する。上記第１
の観点のディレクトリ・サーバでは、アクセス要求の種
類別に分割してＬＲＵ管理するため、ある１つの種類の
検索要求によって大量のエントリがＤＢから抽出されて
も、他の種類のエントリがキャッシュから削除されず、
高ヒット率を確保できる。また、すべての属性をキャッ
シュに格納せず、必要な属性のみをキャッシュに格納す
るため、アクセス頻度の低い属性がキャッシュを消費す
ることを防止でき、高いキャッシュ効率を確保できる。

【００１５】第２の観点では、本発明は、ディレクトリ
情報を記憶するデータベースを備えたディレクトリ・サ
ーバにおいて、エントリのキャッシュ格納をアクセス要
求の種類別に分割してＬＲＵ管理するアクセス別分割Ｌ
ＲＵ管理手段を有することを特徴とするディレクトリ・
サーバを提供する。上記第２の観点のディレクトリ・サ
ーバでは、アクセス要求の種類別に分割してＬＲＵ管理
するため、ある１つの種類の検索要求によって大量のエ
ントリがＤＢから抽出されても、他の種類のエントリが
キャッシュから削除されず、高ヒット率を確保できる。

【００１６】第３の観点では、本発明は、ディレクトリ
情報を記憶するデータベースを備えたディレクトリ・サ
ーバにおいて、アクセス要求毎に必要属性のみをキャッ
シュ格納する属性管理手段を有することを特徴とするデ
ィレクトリ・サーバ。上記第３の観点のディレクトリ・
サーバでは、すべての属性をキャッシュに格納せず、必
要な属性のみをキャッシュに格納するため、アクセス頻
度の低い属性がキャッシュを消費することを防止でき、
高いキャッシュ効率を確保できる。

【００１７】第４の観点では、本発明は、上記第１また
は第２の観点のディレクトリ・サーバにおいて、前記ア
クセス別分割ＬＲＵ管理手段は、データベースから新た
に抽出したエントリをアクセス要求の種類別ＬＲＵリス
トに加えることによってキャッシュ格納を行い、アクセ
ス要求の種類別ＬＲＵリスト毎にカウントしたエントリ
数に基づいてアクセス要求の種類別のＬＲＵ管理を行う
ことを特徴とするディレクトリ・サーバを提供する。ま
た、第５の観点では、本発明は、上記第４の観点のディ
レクトリ・サーバにおいて、前記アクセス別分割ＬＲＵ
管理手段は、エントリを加えようとしたアクセス要求の
種類別ＬＲＵリストのエントリ数が当該アクセス要求の
種類別ＬＲＵリストに設定されている最大数に達してい
た場合、そのアクセス要求の種類別ＬＲＵリストから最
も過去に加えたエントリを削除し、エントリを加えるこ
とを特徴とするディレクトリ・サーバを提供する。上記
第４および第５の観点のディレクトリ・サーバでは、ア
クセス要求の種類別に分割したＬＲＵリストを用い、そ
れらＬＲＵリスト毎にＬＲＵ管理するため、アクセス要
求の種類別のＬＲＵ管理を好適に行うことが出来る。

【００１８】第６の観点では、本発明は、上記第１、第
２、第４または第５の観点のディレクトリ・サーバにお
いて、前記アクセス別分割ＬＲＵ管理手段は、アクセス
要求が更新系である場合、アクセス要求の処理に必要な
エントリを新たにデータベースから抽出しても、そのエ
ントリをキャッシュに格納しないことを特徴とするディ
レクトリ・サーバを提供する。上記第６の観点のディレ
クトリ・サーバでは、アクセス頻度が低い更新系のアク
セス要求に対してはキャッシュを使用しない。このた
め、アクセス頻度が高い検索系のアクセス要求が優先的
にキャッシュを使用できるようになり、全体としてキャ
ッシュ効率を向上できる。

【００１９】第７の観点では、上記第５の観点のディレ
クトリ・サーバにおいて、現在のアクセス要求の処理に
必要なエントリがキャッシュに既に格納されており且つ
現在のアクセス要求の種類とは異なるアクセス要求の種
類別ＬＲＵリストに所属している場合、現在のアクセス
要求の種類別ＬＲＵリストに当該エントリを加えると共
に現在のアクセス要求の種類別ＬＲＵリストのエントリ
数を“１”増やさないことを特徴とするディレクトリ・
サーバを提供する。アクセス要求の種類別に分割したＬ
ＲＵリスト毎にＬＲＵ管理する場合、ＬＲＵリスト毎に
エントリ数をカウントすることが原則であるが、あるエ
ントリが複数のＬＲＵリストに所属するとき、そのエン
トリのカウントが重複して行われ、実際にはキャッシュ
に余裕があるのに、エントリの入れ換えが行われてしま
うことがある。上記第７の観点のディレクトリ・サーバ
では、あるエントリが複数のＬＲＵリストに所属すると
き、そのエントリのカウントは、最初に所属したＬＲＵ
リストのみで行う。これにより、１つのエントリが重複
してカウントすることが防止されるため、必要のないエ
ントリの入れ換えが抑制され、キャッシュの使用効率を
向上できる。

【００２０】第８の観点では、本発明は、上記第１、第
２または第４から第７の観点のいずれかのディレクトリ
・サーバにおいて、エントリを加えようとしたアクセス
要求の種類別ＬＲＵリストのエントリ数が当該アクセス
要求の種類別ＬＲＵリストに設定されている最大数に達
していなくても、キャッシュに格納しているエントリの
総数が設定されている最大数に達していた場合、そのア
クセス要求の種類別ＬＲＵリストから最も過去に加えた
エントリを削除し、エントリを加えることを特徴とする
ディレクトリ・サーバを提供する。アクセス要求の種類
別に分割したＬＲＵリスト毎にＬＲＵ管理する場合、Ｌ
ＲＵリスト毎にエントリ数をカウントすることが原則で
あるが、あるエントリが複数のＬＲＵリストに所属する
とき、そのエントリのカウントが重複して行われ、実際
にはキャッシュに余裕があるのに、エントリの入れ換え
が行われてしまうことがある。上記第８の観点のディレ
クトリ・サーバでは、アクセス要求の種類別に分割した
ＬＲＵリスト毎にＬＲＵ管理を行うのに加えて、キャッ
シュに格納しているエントリの総数でもＬＲＵ管理を行
う。これにより、アクセス要求の種類別に分割したＬＲ
Ｕリスト毎に設定する最大数を大きめに設定しても、全
体としてのキャッシュ動作に支障を生じない。そして、
アクセス要求の種類別に分割したＬＲＵリスト毎に設定
する最大数を大きめに設定しておけば、１つのエントリ
を重複してカウントしても、必要のないエントリの入れ
換えが起らず、キャッシュの使用効率を向上できる。

【００２１】第９の観点では、本発明は、上記第１、第
２または第４から第８の観点のいずれかのディレクトリ
・サーバにおいて、前記アクセス要求の種類別が、検索
系アクセス要求のスコープ別であることを特徴とするデ
ィレクトリ・サーバを提供する。上記第９の観点のディ
レクトリ・サーバでは、検索系アクセス要求のスコープ
別にＬＲＵ管理を行うため、前記リスト要求または前記
サーチ要求を用いた１つの検索要求に対して大量のエン
トリがＤＢから抽出されても、前記リード要求で抽出さ
れたエントリがキャッシュから削除されることはない。
一般に、リード要求のエントリの使用の頻度が高いた
め、全体として高ヒット率を確保できる。

【００２２】第１０の観点では、本発明は、上記第１ま
たは第３の観点のディレクトリ・サーバにおいて、前記
属性管理手段は、必要な属性の属性名の代りにそれに対
応する属性番号をキャッシュに格納することを特徴とす
るディレクトリ・サーバを提供する。上記第１０の観点
のディレクトリ・サーバでは、文字列の属性名の代りに
数値の属性番号を用いるため、属性名の長さに関わら
ず、キャッシュのメモリ所要量を小さく抑えることが出
来る。

【００２３】第１１の観点では、本発明は、上記第１、
第３または第１０の観点のディレクトリ・サーバにおい
て、前記属性管理手段は、キャッシュに全属性が格納さ
れているか否かを調べ、キャッシュに全属性が格納され
ていない場合のみ必要な属性をリストアップし、その必
要な属性がキャッシュに格納されているか否かを調べ、
必要な属性がキャッシュに格納されていない場合のみデ
ータベースにアクセスすることを特徴とするディレクト
リ・サーバを提供する。上記第１１の観点のディレクト
リ・サーバでは、キャッシュに全属性が格納されている
か否かを調べ、全属性が格納されている場合は、必要な
属性のリストアップやデータベースへのアクセスを行わ
ない。全属性が格納されていない場合には、必要な属性
のリストアップを行うが、そのリストアップした必要な
属性がキャッシュに格納されているか否かを調べ、格納
されている場合は、データベースへのアクセスを行わな
い。これにより、作業量を最小限に抑制することが出来
る。

【００２４】第１２の観点では、本発明は、上記第１、
第３、第１０または第１１の観点のディレクトリ・サー
バにおいて、前記必要な属性は、アクセス要求により抽
出を指示された属性の外に、ディレクトリ情報のアクセ
ス制御に必要な属性を含むことを特徴とするディレクト
リ・サーバを提供する。上記第１２の観点のディレクト
リ・サーバでは、ディレクトリ情報のアクセス制御に必
要な属性もキャッシュに格納するため、キャッシュに格
納しない場合に比べて応答性を向上できる。

【００２５】

【発明の実施の形態】以下、本発明の実施形態について
図面を用いて説明する。なお、これにより本発明が限定
されるものではない。

【００２６】−第一の実施形態− 図１は、本発明の第一の実施形態にかかるディレクトリ
・サーバの機能構成図である。このディレクトリ・サー
バ１は、ディレクトリ情報を記憶管理するＤＢ９を備え
ている。また、ディレクトリ・サーバ１は、ＬＡＮ等の
ネットワーク１０を介してディレクトリ・クライアント
２と通信するための通信処理を実行する通信制御部３
と、ディレクトリ・クライアント２からディレクトリ情
報に対するアクセス要求を受け付け内容を解析するプロ
トコル解析部４と、アクセス要求の種類別に分割された
ＬＲＵリスト７を持つエントリ・キャッシュ６と、エン
トリのキャッシュ６への格納をアクセス要求の種類別に
分割してＬＲＵ管理するアクセス別分割ＬＲＵ管理部５
と、アクセス要求毎に必要な属性のみを抽出しキャッシ
ュ６に格納する属性管理部８とを具備している。ＤＢ９
は、各ディレクトリ・エントリの情報を記憶管理するＤ
Ｂ管理システムであり、例えばＩＳＡＭ（Indexed Sequ
ential Access Method）が挙げられる。

【００２７】図２は、ディレクトリ・サーバ１のシステ
ム構成図である。図中、図１の構成要素と対応する構成
要素には同一符号を付している。ディレクトリ・サーバ
１は、ＣＰＵ１６と、主メモリ１１と、ハードディスク
装置等の磁気ディスク１７と、バス１２と、ディスプレ
イ１３と、キーボード１４と、マウス等のポインティン
グデバイス１５とから構成される。主メモリ１１には、
エントリ・キャッシュ６と、通信制御プログラム（部）
３と、プロトコル解析プログラム（部）４と、アクセス
別分割ＬＲＵ管理プログラム（部）５と、属性管理プロ
グラム（部）８と、ＤＢ管理プログラム１９とが格納さ
れる。これらのプログラムは、当初磁気ディスク１７に
格納され、必要に応じて主メモリ１１に転送された後、
ＣＰＵ１６で実行される。磁気ディスク１７には、ディ
レクトリ・データ１８がファイルとして格納される。デ
ィレクトリ・データ１８は、エントリ・データ１００
と、インデックス１０１とから成る。エントリ・データ
１００は、ディレクトリ・サーバ１が保持するすべての
エントリと各々のエントリが持つすべての属性とを格納
している。エントリ・データ１００に格納されているす
べてのエントリは、各々が一意な番号であるＩＤを持
つ。このＩＤをキーとして、ディレクトリ・サーバ１は
ＤＢ９へのアクセスを行う。インデックス１０１は、エ
ントリのＤＮや属性値についてのインデックスであり、
ＤＮや属性値とそれを持つエントリのＩＤの関係を保持
する。なお、ＤＢ管理プログラム１９とディレクトリ・
データ１８とからＤＢ９が構成される。

【００２８】図３は、エントリ・キャッシュ６の機能構
成図である。エントリ・キャッシュ６は、キャッシュ管
理情報を格納するキャッシュ管理テーブル２０と、キャ
ッシュ中のエントリとＩＤとの関係を記憶するエントリ
ＩＤテーブル２１と、キャッシュ中のエントリとＤＮの
関係を記憶するエントリＤＮテーブル２２と、図１５の
Search６１のbaseObject６２を用いた検索によってＤＢ
９から抽出されキャッシュに格納されたエントリを管理
するbase ＬＲＵリスト２３と、図１５のSearch６１のs
ingleLevel６３を用いた検索によってＤＢ９から抽出さ
れキャッシュに格納されたエントリを管理するone-leve
l ＬＲＵリスト２４と、図１５のSearch６１のwholeSub
tree６４を用いた検索によってＤＢ９から抽出されキャ
ッシュに格納されたエントリを管理するsubtree ＬＲＵ
リスト２５とを具備している。前記３本のＬＲＵリスト
２３，２４，２５からアクセス別ＬＲＵリスト７が構成
される。

【００２９】図４は、キャッシュ管理テーブル２０の構
成図である。「base ＬＲＵリストの最大エントリ数」
２６、「one-level ＬＲＵリストの最大エントリ数」３
０および「subtree ＬＲＵリストの最大エントリ数」３
４は、それぞれbase ＬＲＵリスト２３、one-level Ｌ
ＲＵリスト２４およびsubtreeＬＲＵリスト２５で管理
できるエントリの最大数であり、ディレクトリ・サーバ
起動時に運用管理者等が設定した値が登録されている。
「base ＬＲＵリストの現エントリ数」２７、「one-lev
el ＬＲＵリストの現エントリ数」３１および「subtree
ＬＲＵリストの現エントリ数」３５は、それぞれbase
ＬＲＵリスト２３、one-level ＬＲＵリスト２４および
subtree ＬＲＵリスト２５で現在管理しているエントリ
数を記憶している。「base ＬＲＵリストの先頭ポイン
タ」２８および「base ＬＲＵリストの末尾ポインタ」
２９は、base ＬＲＵリスト２３の先頭および末尾のエ
ントリをそれぞれ指している。同様に、「one-level Ｌ
ＲＵリストの先頭ポインタ」３２および「one-level Ｌ
ＲＵリストの末尾ポインタ」３３は、one-level ＬＲＵ
リスト２４の先頭および末尾のエントリをそれぞれ指し
ている。また、「subtree ＬＲＵリストの先頭ポイン
タ」３６および「subtree ＬＲＵリストの末尾ポイン
タ」３７は、subtree ＬＲＵリスト２５の先頭および末
尾のエントリをそれぞれ指している。

【００３０】図３３は、base ＬＲＵリスト２３、one-l
evel ＬＲＵリスト２４およびsubtree ＬＲＵリスト２
５で管理するエントリの最大数（サイズ）を運用管理者
等が設定するための画面の例示図である。この画面９０
には、base ＬＲＵリスト２３での最大数を入力する領
域９１、one-level ＬＲＵリスト２４での最大数を入力
する領域９２、subtree ＬＲＵリスト２５での最大数を
入力する領域９３および入力した情報を登録するための
ボタン９４とがある。この画面９０は、ディレクトリ・
サーバ１の起動時に、アクセス別分割ＬＲＵ管理部５
が、ディスプレイ１３に表示する。また、アクセス別分
割ＬＲＵ管理部５は、キーボード１４やマウス１５によ
る入力等を制御する。運用管理者は、キーボード１４を
用いてbase ＬＲＵリスト２３の領域９１、one-level
ＬＲＵリスト２４の領域９２、subtree ＬＲＵリスト２
５の領域９３にそれぞれ最大数を入力し、ＯＫボタン９
４をマウス１５でクリックする。これを受けて、アクセ
ス別分割ＬＲＵ管理部５は、各領域９１、９２および９
３に入力された最大数を、キャッシュ管理テーブル２０
の「base ＬＲＵリストの最大エントリ数」２６、「one
-level ＬＲＵリストの最大エントリ数」３０および「s
ubtree ＬＲＵリストの最大エントリ数」３４に登録す
る。

【００３１】図５は、エントリＩＤテーブル２１の構造
図である。エントリＩＤテーブル２１は、複数個のノー
ド３８を組み合わせて構成されるバランスツリー構造と
なっている。ノード３８は、あるエントリを指すエント
リポインタ３９と、左右のノードを指すノードポインタ
４０，４１とを持っている。ＩＤをキーとしてエントリ
ＩＤテーブル２１のノードをたどれば、そのＩＤを持つ
エントリを得ることが出来る。エントリＤＮテーブル２
２も同様の構造であり、ＤＮをキーとしてエントリＤＮ
テーブル２２のノードをたどれば、そのＤＮを持つエン
トリを得ることが出来る。

【００３２】図６は、キャッシュに格納されるエントリ
５５の構造図である。エントリ名（ＤＮ）４２とエント
リＩＤ４３には、このエントリ５５のＤＮとＩＤを格納
する。全属性フラグ４４には、このエントリ５５の全て
の属性をキャッシュに格納している場合は“１”を設定
し、一部の属性だけをキャッシュに格納している場合は
“０”を設定する。属性値リストポインタ４５は、属性
値リスト５６を指している。属性値リスト５６は、属性
名５７と属性値５８を１セットとする配列構造をなして
おり、このエントリ５５の全属性もしくは一部の属性を
格納している。

【００３３】base ＬＲＵ所属フラグ４６には、このエ
ントリ５５がbase ＬＲＵリスト２３に所属していれば
“１”を設定し、所属していなければ“０”を設定す
る。one-level ＬＲＵ所属フラグ４９には、このエント
リ５５がone-level ＬＲＵリスト２４に所属していれば
“１”を設定し、所属していなければ“０”を設定す
る。subtree ＬＲＵ所属フラグ５２には、このエントリ
５５がsubtree ＬＲＵリスト２５に所属していれば
“１”を設定し、所属していなければ“０”を設定す
る。

【００３４】base ＬＲＵ nextポインタ４７およびbase
ＬＲＵ prevポインタ４８には、このエントリ５５がba
se ＬＲＵリスト２３に所属していれば、このエントリ
５５の前後のエントリを指すポインタをそれぞれ格納す
る。このエントリ５５がbaseＬＲＵリスト２３の先頭エ
ントリであれば、base ＬＲＵ prevポインタ４８には
“ＮＵＬＬ”を格納する。一方、このエントリ５５が末
尾エントリであれば、base ＬＲＵ nextポインタ４７に
は“ＮＵＬＬ”を格納する。one-level ＬＲＵ nextポ
インタ５０およびone-level ＬＲＵ prevポインタ５１
には、このエントリ５５がone-level ＬＲＵリスト２４
に所属していれば、このエントリ５５の前後のエントリ
を指すポインタをそれぞれ格納する。このエントリ５５
がone-level ＬＲＵリスト２４の先頭エントリであれ
ば、one-level ＬＲＵ prevポインタ５１には“ＮＵＬ
Ｌ”を格納する。一方、このエントリ５５が末尾エント
リであれば、one-level ＬＲＵ nextポインタ５０には
“ＮＵＬＬ”を格納する。subtree ＬＲＵ nextポイン
タ５３およびsubtree ＬＲＵ prevポインタ５４には、
このエントリ５５がsubtree ＬＲＵリスト２５に所属し
ていれば、このエントリ５５の前後のエントリを指すポ
インタをそれぞれ格納する。このエントリ５５がsubtre
e ＬＲＵリスト２５の先頭エントリであれば、subtree
ＬＲＵ prevポインタ５４には“ＮＵＬＬ”を格納す
る。一方、このエントリ５５が末尾エントリであれば、
subtree ＬＲＵ nextポインタ５３には“ＮＵＬＬ”を
格納する。

【００３５】図７は、必要属性リスト５９の構造図であ
る。必要属性リスト５９は、属性名６０を要素とする配
列構造をなしており、ディレクトリ・サーバ１が受け取
ったアクセス要求を処理するのに必要となる属性の名前
のリストである。

【００３６】図８は、アクセス別ＬＲＵリスト７の構成
図である。アクセス別ＬＲＵリスト７は、base ＬＲＵ
リスト２３、one-level ＬＲＵリスト２４およびsubtre
e ＬＲＵリスト２５から構成されている。複数のＬＲＵ
リストが集まっているエントリ５５は、複数のＬＲＵリ
ストに所属しているエントリである。

【００３７】図９は、アクセス要求を受け付けたときの
ディレクトリ・サーバ１の動作を表すフローチャートで
ある。通信制御部３がディレクトリ・クライアント２か
らのアクセス要求を受信すると（Ｓ０９０１）、プロト
コル解析部４がアクセス要求を解析し（Ｓ０９０２）、
アクセス要求が検索系要求でなければ更新系要求処理を
行い（Ｓ０９０４）、検索系要求であれば検索系要求処
理を行う（Ｓ０９０５）。

【００３８】図１０は、図９の更新系要求処理（Ｓ０９
０４）を表すフローチャートである。アクセス要求がAd
d要求であった場合は（Ｓ１００１）、Add要求処理を行
い（Ｓ１００２）、Delete要求であった場合は（Ｓ１０
０３）は、Delete要求処理を行い（Ｓ１００４）、Modi
fy要求であった場合は（Ｓ１００５）、Modify要求処理
を行い（Ｓ１００６）、それ以外の場合はModifyRDN要
求処理を行う（Ｓ１００７）。

【００３９】図１１は、図９の検索要求処理（Ｓ０９０
５）を表すフローチャートである。（Ｓ１１１２）で
は、アクセス別分割ＬＲＵ管理部５は、ディレクトリデ
ータ１８のインデックス１０１を用いて、検索条件に指
定されている属性を持つエントリのＩＤをリストアップ
する。（Ｓ１１０１）では、リストアップしたＩＤを基
にエントリ・キャッシュ６のエントリＩＤテーブル２１
およびエントリＤＮテーブル２２を参照し、検索対象の
エントリがキャッシュ中に格納されているかを確認す
る。（Ｓ１１０２）では、検索対象のエントリがキャッ
シュ中に格納されている場合は（Ｓ１１０３）へ進み、
格納されていない場合は（Ｓ１１１３）へ進む。

【００４０】（Ｓ１１０３）では、キャッシュに格納さ
れていたエントリ５５の全属性フラグ４４の値が“０”
であった場合は（Ｓ１１０５）へ進み、“１”であった
場合は（Ｓ１１１０）へ進む。（Ｓ１１０５）では、属
性管理部８が、主メモリ１１上に新たに領域を確保し、
検索要求のスコープおよび要求属性から必要属性リスト
５９を作成する。（Ｓ１１０６）では、その必要属性が
エントリ５５が持つ属性値リスト５６にすべて存在する
なら（Ｓ１１１０）へ進み、一部しか存在しないなら
（Ｓ１１０７）へ進む。

【００４１】（Ｓ１１０７）では、アクセス別分割ＬＲ
Ｕ管理部５はＤＢ９にアクセスしてエントリの情報を取
り出し、属性管理部８に渡す。属性管理部８は、渡され
たエントリを、図３４に示すように、ワーク領域９５に
エントリ５５’として格納する。（Ｓ１１０８）では、
属性管理部８は、必要属性リスト５９に従って必要な属
性のみをキャッシュ中のエントリ５５に加える。この
時、検索要求の内容がエントリのすべての属性を取り出
すものであればエントリ５５の全属性フラグ４４に
“１”を設定する。例えば、アクセス要求Search６１の
内容を確認し、検索条件に合致したエントリのどの属性
を要求しているかを表すattribute９９の内容がすべて
の属性を要求していることを表す“ＮＵＬＬ”であれ
ば、エントリ５５の全属性フラグ４４に“１”を設定す
る。そして、（Ｓ１１１０）へ進む。

【００４２】（Ｓ１１１０）では、アクセス別分割ＬＲ
Ｕ管理部５は、検索要求のスコープに該当するＬＲＵリ
スト２３または２４または２５を更新する。そして、
（Ｓ１１１１）へ進む。

【００４３】（Ｓ１１１１）では、検索結果をディレク
トリ・クライアント２に送信する。そして、処理を終了
する。

【００４４】（Ｓ１１１３）では、アクセス別分割ＬＲ
Ｕ管理部５は、ＤＢ９から読み出したエントリを格納す
るための領域（空のエントリ５５）と、属性を格納する
ための属性値リストの領域（空の属性値リスト５６）を
確保する。その空のエントリ５５のエントリ名（ＤＮ）
４２および各ＬＲＵポインタ４７、４８、５０、５１、
５３、５４は“ＮＵＬＬ”に設定し、エントリＩＤ４３
および各フラグ４４、４６、４９、５２は“０”に設定
し、属性値リストポインタ４５は空の属性値リスト５６
を指すよう設定する。空の属性値リスト５６の属性名５
７および属性値５８には“ＮＵＬＬ”を設定する。（Ｓ
１１０４）では、属性管理部８は、必要属性リスト５９
を作成する。（Ｓ１１０７）では、アクセス別分割ＬＲ
Ｕ管理部５は、ＤＢ９にアクセスしてエントリの情報を
取り出し、属性管理部８に渡す。属性管理部８は、図３
４に示すように、渡されたエントリ５５’をワーク領域
９５に格納する。（Ｓ１１０８）では、属性管理部８
は、必要な属性のみを属性値リスト５６に加える。この
時、検索要求の内容がエントリのすべての属性を取り出
すものであればエントリ５５の全属性フラグ４４に
“１”を設定する。（Ｓ１１０９）では、アクセス別分
割ＬＲＵ管理部５は検索要求のスコープに該当するＬＲ
Ｕリスト２３または２４または２５にエントリ５５を加
える。そして、前記（Ｓ１１１１）へ進む。

【００４５】図１２は、図１０のAdd要求処理（Ｓ１０
０２）を表すフローチャートである。アクセス別分割Ｌ
ＲＵ管理部５はエントリ・キャッシュ６のエントリＩＤ
テーブル２１およびエントリＤＮテーブル２２を参照
し、Add要求で指示された追加対象のエントリがキャッ
シュ中に格納されているかを確認し（Ｓ１２０１）、格
納されている場合（Ｓ１２０２）、処理結果としてエラ
ーを返す（Ｓ１２０９）。キャッシュ中に格納されてな
かった場合（Ｓ１２０２）、ＤＢ９にアクセスし（１２
０３）、追加するエントリがＤＢ９に存在するかを確認
し存在した場合（Ｓ１２０４）、処理結果としてエラー
を返す（Ｓ１２０９）。ＤＢ９に存在しなかった場合
（Ｓ１２０４）、Add要求で指示されたエントリをＤＢ
９に追加し（Ｓ１２０６）、処理結果を送信する（Ｓ１
２０８）。

【００４６】図１３は、図１０のDelete要求処理（Ｓ１
００４）を表すフローチャートである。アクセス別分割
ＬＲＵ管理部５はエントリ・キャッシュ６のエントリＩ
Ｄテーブル２１およびエントリＤＮテーブル２２を参照
し、Delete要求で指示された削除対象のエントリがキャ
ッシュ中に格納されているかを確認する（Ｓ１３０
１）。格納されていた場合（Ｓ１３０２）、それをキャ
ッシュから削除し（Ｓ１３０４）、ＤＢ９にアクセスし
てDelete要求で指示された削除を行い（Ｓ１３０５）、
結果を送信する（Ｓ１３０６）。キャッシュ中に格納さ
れていなかった場合（Ｓ１３０２）、ＤＢ９にアクセス
してDelete要求で指示された削除を行い（Ｓ１３０
５）、結果を送信する（Ｓ１３０６）。

【００４７】図１４は、図１０のModify要求処理（Ｓ１
００６）を表すフローチャートである。アクセス別分割
ＬＲＵ管理部５はエントリ・キャッシュ６のエントリＩ
Ｄテーブル２１およびエントリＤＮテーブル２２を参照
し、Modify要求で指示された更新対象のエントリがキャ
ッシュ中に格納されているかを確認する（Ｓ１４０
１）。格納されていた場合（Ｓ１４０２）、そのエント
リ５５が持つ属性値リスト５６を参照して更新対象の属
性が存在した場合（Ｓ１４０３）は更新対象の属性の値
５８をModify要求にしたがって変更し（Ｓ１４０４）、
ＤＢ９にアクセスしてModify要求で指示された更新を行
い（Ｓ１４０５）、結果を送信する（Ｓ１４０６）。更
新対象の属性が存在しなかった場合（Ｓ１４０３）、Ｄ
Ｂ９にアクセスしてModify要求で指示された更新を行い
（Ｓ１４０５）、結果を送信する（Ｓ１４０６）。キャ
ッシュ中にエントリが格納されていなかった場合（Ｓ１
４０２）、ＤＢ９にアクセスしてModify要求で指示され
た属性の更新を行い（Ｓ１４０５）、結果を送信する
（Ｓ１４０６）。

【００４８】図１５は、図１０のModifyRDN要求処理
（Ｓ１００７）を表すフローチャートである。アクセス
別分割ＬＲＵ管理部５はエントリ・キャッシュ６のエン
トリＩＤテーブル２１およびエントリＤＮテーブル２２
を参照し、ModifyRDN要求で指示された更新対象のエン
トリがキャッシュ中に格納されているかを確認する（Ｓ
１５０１）。格納されていた場合（Ｓ１５０２）、該エ
ントリ５５のＤＮを変更し（Ｓ１５０３）、ＤＢ９にア
クセスしModifyRDN要求で指示されたＤＮの変更を行い
（Ｓ１５０４）、結果を送信する（Ｓ１５０５）。キャ
ッシュに格納されていなかった場合（Ｓ１５０２）、Ｄ
Ｂ９にアクセスしModifyRDN要求で指示されたＤＮの変
更を行い（Ｓ１５０４）、結果を送信する（Ｓ１５０
５）。

【００４９】図１６は、図１１の属性格納処理（Ｓ１１
０８）を表すフローチャートである。（Ｓ１６０１）で
は、属性管理部８は、必要属性リスト５９の一つの属性
名６０に着目する。（Ｓ１６０２）では、キャッシュに
格納されているエントリ５５の属性値リスト５６の属性
名５７を参照し、前記着目した属性名６０がなければ
（Ｓ１６０３）へ進み、前記着目した属性名６０があれ
ば（Ｓ１６０４）へ進む。（Ｓ１６０３）では、ワーク
領域９５のエントリ５５’の属性値リスト５６の属性名
５７と属性値５８を取り出し、キャッシュのエントリ５
５の属性値リスト５６の最後に追加する。（Ｓ１６０
４）では、必要属性リスト５９の次の一つの属性名６０
に着目する。（Ｓ１６０５）では、前記（Ｓ１６０４）
で未処理の属性名６０があれば前記（Ｓ１６０２）に戻
り、未処理の属性名６０がなければ処理を終わる。

【００５０】図１７は、図１１のキャッシュエントリ追
加処理（Ｓ１１０９）を表すフローチャートである。ア
クセス別分割ＬＲＵ管理部５は、ノード３８の領域を２
つ確保し、追加するエントリ５５を指すようにそれらノ
ード３８のエントリポインタ３９を設定し、エントリＩ
Ｄテーブル２１のツリーのノードを頂点から辿って挿入
点を探索し、２つのノード３８のうちの一つをエントリ
ＩＤテーブル２１のツリーに挿入し、左右のノードを指
すようノードポインタ４０，４１を適宜セットし、同様
にしてもう一つのノード３８をエントリＤＮテーブル２
２のツリーに挿入する（Ｓ１７０１）。次に、検索要求
のスコープを確認し（Ｓ１７０２）、そのスコープのＬ
ＲＵリストの先頭にエントリ５５を追加する（Ｓ１７０
３）。さらに追加したＬＲＵリストの現エントリ数を確
認し（Ｓ１７０４）、該ＬＲＵリストの最大数を超えて
いない場合（Ｓ１７０５）、処理を終了する。該ＬＲＵ
リストの最大数を超えた場合（Ｓ１７０５）、該ＬＲＵ
リストの末尾のエントリ５５を確認し（Ｓ１７０６）、
ＬＲＵリスト削除処理を行う（Ｓ１７０７）。さらにそ
の末尾のエントリ５５の該ＬＲＵリスト以外の所属フラ
グの値がどちらも“０”であった場合（Ｓ１７０８）は
そのエントリ５５が他のＬＲＵに属していないので、キ
ャッシュから完全に削除するためキャッシュエントリ削
除処理（Ｓ１３０４）を行う。前記末尾のエントリ５５
の該ＬＲＵリスト以外の所属フラグの値の少なくとも一
つが“１”であった場合（Ｓ１７０８）は他のＬＲＵに
属しているので、キャッシュエントリ削除処理（Ｓ１３
０４）は行わないで、処理を終了する。

【００５１】図１８は、図１３および図１７のキャッシ
ュエントリ削除処理（Ｓ１３０４）を表すフローチャー
トである。（Ｓ１８０１）では、アクセス別分割ＬＲＵ
管理部５は、削除対象のエントリ５５のbase ＬＲＵ所
属フラグ４６の値が“１”であれば（Ｓ１８０２）へ進
み、“０”であれば（Ｓ１８０４）へ進む。（Ｓ１８０
２）では、キャッシュ管理テーブル２０の「base ＬＲ
Ｕリストの現エントリ数」２７を“１”減らす。（Ｓ１
８０３）では、削除対象のエントリをbase ＬＲＵリス
ト２３から削除する。

【００５２】（Ｓ１８０４）では、削除対象のエントリ
５５のone-level ＬＲＵ所属フラグ４９の値が“１”で
あれば（Ｓ１８０５）へ進み、“０”であれば（Ｓ１８
０４）へ進む。（Ｓ１８０５）では、キャッシュ管理テ
ーブル２０の「one-level ＬＲＵリストの現エントリ
数」３１を“１”減らす（Ｓ１８０５）。（Ｓ１８０
６）では、削除対象のエントリをone-level ＬＲＵリス
ト２４から削除する（Ｓ１８０６）。

【００５３】（Ｓ１８０７）では、削除対象のエントリ
５５のsubtree ＬＲＵ所属フラグ５２の値が“１”であ
れば（Ｓ１８０８）へ進み、“０”であれば（Ｓ１８１
０）へ進む。（Ｓ１８０８）では、キャッシュ管理テー
ブル２０の「subtree ＬＲＵリストの現エントリ数」３
５を“１”減らす。（Ｓ１８０９）では、削除対象のエ
ントリをsubtree ＬＲＵリスト２５から削除する。

【００５４】（Ｓ１８１０）では、削除対象のエントリ
５５および属性リスト５６を格納していた主メモリ１１
上の領域を開放して終了する。

【００５５】図１９は、図１１中のＬＲＵリスト更新処
理（Ｓ１１１０）を表すフローチャートである。アクセ
ス別分割ＬＲＵ管理部５は、アクセス要求のスコープを
確認し（Ｓ１９０１）、そのスコープのＬＲＵリストか
らエントリを削除し（Ｓ１７０７）、同じエントリをＬ
ＲＵリストの先頭に追加する（Ｓ１７０３）。以上の処
理により、ＬＲＵリスト中のエントリが、そのＬＲＵリ
ストの先頭に移動する。

【００５６】図２０は、図１７および図１９中のＬＲＵ
リスト追加処理（Ｓ１７０３）を表すフローチャートで
ある。（Ｓ２００１）では、アクセス別分割ＬＲＵ管理
部５は、検索要求のスコープがbaseObject６２であれば
（Ｓ２００２）へ進み、そうでなければ（Ｓ２００５）
へ進む。（Ｓ２００２）では、キャッシュ管理テーブル
２０の「base ＬＲＵリストの現エントリ数」２７を
“１”増やす。（Ｓ２００３）では、エントリをbase
ＬＲＵリスト２３の先頭に追加する。すなわち、キャッ
シュ管理テーブル２０の「base ＬＲＵリストの先頭ポ
インタ」２８の内容を、このエントリ５５のbase ＬＲ
Ｕ nextポインタ４７にコピーし、次に「base ＬＲＵリ
ストの先頭ポインタ」２８がこのエントリ５５を指すよ
うにセットする。また、このエントリ５５のbase ＬＲ
Ｕ prevポインタ４８には“ＮＵＬＬ”をセットする。
（Ｓ２００４）では、エントリ５５のbase ＬＲＵ所属
フラグ４６の値を“１”にセットする。そして、処理を
終了する。

【００５７】（Ｓ２００５）では、検索要求のスコープ
がsingleLevel６３であれば（Ｓ２００６）へ進み、そ
うでなければ（Ｓ２００９）へ進む。（Ｓ２００６）で
は、キャッシュ管理テーブル２０の「one-level ＬＲＵ
リストの現エントリ数」３１を“１”増やす。（Ｓ２０
０７）では、エントリ５５をone-level ＬＲＵリスト２
４の先頭に追加する。すなわち、キャッシュ管理テーブ
ル２０の「one-level ＬＲＵリストの先頭ポインタ」３
２の内容を、このエントリ５５のone-level ＬＲＵ nex
tポインタ５０にコピーし、次に「one-level ＬＲＵリ
ストの先頭ポインタ」３２がこのエントリ５５を指すよ
うにセットする。また、このエントリ５５のone-level
ＬＲＵ prevポインタ５１には“ＮＵＬＬ”をセットす
る。（Ｓ２００８）では、エントリ５５のone-level Ｌ
ＲＵ所属フラグ４９の値を“１”にセットする。そし
て、処理を終了する。

【００５８】（Ｓ２００９）では、検索要求のスコープ
がwholeSubtree６４であれば（Ｓ２０１０）へ進み、そ
うでなければ処理を終了する。（Ｓ２０１０）では、キ
ャッシュ管理テーブル２０の「subtree ＬＲＵリストの
現エントリ数」３５を“１”増やす。（Ｓ２０１１）で
は、エントリ５５をsubtree ＬＲＵリスト２５の先頭に
追加する。すなわち、キャッシュ管理テーブル２０の
「subtree ＬＲＵリストの先頭ポインタ」３６の内容
を、このエントリ５５のsubtree ＬＲＵ nextポインタ
５３にコピーし、次に「subtree ＬＲＵリストの先頭ポ
インタ」３６がこのエントリ５５を指すようにセットす
る。また、このエントリ５５のsubtree ＬＲＵ prevポ
インタ５４には“ＮＵＬＬ”をセットする。（Ｓ２０１
２）では、エントリ５５のsubtree ＬＲＵ所属フラグ５
２の値を“１”にセットする（Ｓ２０１２）。そして、
処理を終了する。

【００５９】図２１は、図１７および図１９中のＬＲＵ
リスト削除処理（Ｓ１７０７）を表すフローチャートで
ある。（Ｓ２１０１）では、アクセス別分割ＬＲＵ管理
部５は、検索要求のスコープがbaseObject６２であれば
（Ｓ２１０２）へ進み、そうでなければ（Ｓ２１０５）
へ進む。（Ｓ２１０２）では、キャッシュ管理テーブル
２０の「base ＬＲＵリストの現エントリ数」２７を
“１”減らす。（Ｓ２１０３）では、エントリをbase
ＬＲＵリスト２３から削除する。すなわち、削除対象の
エントリ５５のbase ＬＲＵ nextポインタ４７の内容
を、削除対象のエントリ５５のbase ＬＲＵ prevポイン
タ４８が指すエントリのbase ＬＲＵ nextポインタ４７
にコピーし、次に削除対象のエントリ５５のbase ＬＲ
Ｕprevポインタ４８の内容を、削除対象のエントリ５５
のbase ＬＲＵ nextポインタ４７が指すエントリのbase
ＬＲＵ prevポインタ４８にコピーする。（Ｓ２１０
４）では、エントリ５５のbase ＬＲＵ所属フラグ４６
の値を“０”にセットする。そして、処理を終了する。

【００６０】（Ｓ２１０５）では、検索要求のスコープ
がsingleLevel６３であれば（Ｓ２１０６）へ進み、そ
うでなければ（Ｓ２１０９）へ進む。（Ｓ２１０６）で
は、キャッシュ管理テーブル２０の「one-level ＬＲＵ
リストの現エントリ数」３１を“１”減らす。（Ｓ２１
０７）では、エントリをone-level ＬＲＵリスト２４か
ら削除する。すなわち、削除対象のエントリ５５のone-
level ＬＲＵ nextポインタ５０の内容を、削除対象の
エントリ５５のone-level ＬＲＵ prevポインタ５１が
指すエントリのone-level ＬＲＵ nextポインタ５０に
コピーし、次に削除対象のエントリ５５のone-level Ｌ
ＲＵ prevポインタ５１の内容を、削除対象のエントリ
５５のone-level ＬＲＵ nextポインタ５０が指すエン
トリのone-level ＬＲＵprevポインタ５１にコピーす
る。（Ｓ２１０８）では、エントリ５５のone-level Ｌ
ＲＵ所属フラグ４９の値を“０”にセットする。

【００６１】（Ｓ２１０９）では、検索要求のスコープ
がwholeSubtree６４であれば（Ｓ２１１０）へ進み、そ
うでなければ処理を終了する。（Ｓ２１１０）では、キ
ャッシュ管理テーブル２０の「subtree ＬＲＵリストの
現エントリ数」３５を“１”減らす。（Ｓ２１１１）で
は、エントリ５５をsubtree ＬＲＵリスト２５から削除
する。すなわち、削除対象のエントリ５５のsubtree Ｌ
ＲＵ nextポインタ５３の内容を、削除対象のエントリ
５５のsubtree ＬＲＵ prevポインタ５４が指すエント
リのsubtree ＬＲＵ nextポインタ５３にコピーし、次
に削除対象のエントリ５５のsubtree ＬＲＵ prevポイ
ンタ５４の内容を、削除対象のエントリ５５のsubtree
ＬＲＵ nextポインタ５３が指すエントリのsubtree Ｌ
ＲＵ prevポインタ５４にコピーする。（Ｓ２１１２）
では、エントリ５５のsubtree ＬＲＵ所属フラグ５２の
値を“０”にセットする。そして、処理を終了する。

【００６２】上記第一の実施形態にかかるディレクトリ
・サーバ１によれば、検索要求Search６１によってＤＢ
９から抽出したエントリを、その検索スコープ（baseOb
ject６２、singleLevel６３およびwholeSubtree６４）
別に分割した３本のＬＲＵリスト２３、２４、２５に加
えて、スコープ別にＵＲＬ管理するので、ある検索スコ
ープでＤＢ９から大量のエントリが抽出された場合で
も、別の検索スコープのヒット率の高かったエントリを
一掃せず、高ヒット率を確保可能となる。また、必要な
属性のみをキャッシュに格納するので、アクセス頻度の
低い属性がキャッシュを消費することを防止でき、高い
キャッシュ効率を確保可能となる。

【００６３】なお、上記第一の実施形態では、検索要求
で指定された属性のみをキャッシュに格納しているが、
指定されていない属性（例えばディレクトリ・サーバ１
がエントリへのアクセス制御を実施するために必要な属
性）をもキャッシュに格納するようにしても良い。ま
た、上記第一の実施形態では、更新系要求によってＤＢ
９から読み出されたエントリについてはキャッシュへの
格納を行っていないが、これをキャッシュに格納し、任
意のＬＲＵリスト（例えばbase ＬＲＵリスト２３）を
用いて管理するようにしてもよい。

【００６４】−第二の実施形態− 第一の実施形態では、各ＬＲＵリストがエントリ数を独
立にカウントしているため、１つのエントリが複数のＬ
ＲＵリストに所属している場合（図８）、１つのエント
リが各ＬＲＵリストで重複してカウントされる。このた
め、各ＬＲＵリストの現エントリ数が全て最大数に達し
ていても、キャッシュに格納している実際のエントリ数
は最大数の総和に達しておらず、利用されない領域がキ
ャッシュに生じてしまうことがある。これを回避するた
め、第二の実施形態では、１つのエントリが複数のＬＲ
Ｕリストに所属している場合、最初に所属したＬＲＵリ
ストにおいてのみエントリ数としてカウントする。次
に、第二の実施形態を、第一の実施形態との相違点に関
して説明する。

【００６５】図２４は、第二の実施形態におけるエント
リ５５ａの構造図である。このエントリ５５ａと第一の
実施形態におけるエントリ５５（図６）との相違点は、
第一の実施形態におけるエントリ５５のbase ＬＲＵ所
属フラグ４６、one-level ＬＲＵ所属フラグ４９、subt
ree ＬＲＵ所属フラグ５２に代えて、このエントリ５５
ａでは、第１所属コード７１、第２所属コード７２、第
３所属コード７３を持つことである。これら所属コード
７１〜７３には、図２２のSearch６１の検索スコープで
あるbaseObject６２、singleLevel６３、wholeSubtree
６４の値（１、２、３のいずれか）をセットし、該エン
トリ５５ａがどのような順序でどのＬＲＵリストに所属
したかを表す。

【００６６】エントリ・キャッシュ６に新たにエントリ
５５ａを格納する場合、アクセス要求のスコープに該当
するＬＲＵリストの先頭にエントリ５５ａを加え、第１
所属コード７１にスコープの値（“１”“２”“３”の
いずれか）をセットし、第２所属コード７２と第３所属
コード７３には、ＬＲＵリストに所属していないことを
示す値“０”をセットする。また、キャッシュ管理テー
ブル２０の該当するＬＲＵリストの現エントリ数を
“１”増やす。エントリ・キャッシュ６にエントリ５５
ａがすでに存在した場合、そのエントリ５５ａの第１所
属コード７１、第２所属コード７２、第３所属コード７
３を順に検査し、現在のアクセス要求のスコープの値が
いずれかにセットされていれば、そのスコープのＬＲＵ
リストの先頭にエントリ５５ａを移動させる。一方、現
在のアクセス要求のスコープの値がいずれにもセットさ
れていなければ、現在のアクセス要求のスコープに該当
するＬＲＵリストにそのエントリを加え、第２所属コー
ド７２が“０”であればそれを現在のアクセス要求のス
コープの値に変更し、第２所属コード７２が“０”でな
ければ第３所属コード７３に現在のアクセス要求のスコ
ープの値をセットする。

【００６７】キャッシュからエントリ５５ａを削除する
場合は、現在のアクセス要求のスコープに該当するＬＲ
Ｕリストを末尾エントリから先頭エントリへ向かって走
査していき、第１所属コード７１の値が現在のアクセス
要求のスコープの値と同じであるエントリが見つかれ
ば、そのエントリの第２所属コード７２を確認し、その
第２所属コード７２の値が“０”でなければ、その第２
所属コード７２の値に対応するスコープのＬＲＵリスト
の現エントリ数を確認し、最大数に達していなければ
“１”増やし、現在のアクセス要求のスコープに該当す
るＬＲＵリストの現エントリ数を“１”減らす。第２所
属コード７２の値が“０”であるか又は第２所属コード
７２の値に対応するスコープのＬＲＵリストの現エント
リ数が最大数に達していれば、第３所属コード７３を確
認し、その第３所属コード７３の値が“０”でなけれ
ば、第３所属コード７３の値に対応するスコープのＬＲ
Ｕリストの現エントリ数を確認し、最大数に達していな
ければ“１”増やし、現在のアクセス要求のスコープに
該当するＬＲＵリストの現エントリ数を“１”減らす。
第３所属コード７３の値が“０”であるか又は第３所属
コード７３の値に対応するスコープのＬＲＵリストの現
エントリ数が最大数に達していれば、第１所属コード７
１のスコープの値に該当するＬＲＵリストからエントリ
を削除し、そのＬＲＵリストの現エントリ数を“１”減
らす。

【００６８】上記第二の実施形態によれば、キャッシュ
に格納されるエントリ５５ａは、複数のＬＲＵリストに
所属していても、最初に所属したＬＲＵリストにおいて
のみエントリ数としてカウントされ、重複してカウント
されることはない。これにより、キャッシュ管理テーブ
ル２０の各ＬＲＵの現エントリ数の総和は、キャッシュ
に格納されている実際のエントリ数と常に等しくなり、
利用されない領域がキャッシュに生じてしまうことを回
避できる。また、運用管理者は、ディレクトリ・サーバ
１に搭載すべきメモリ容量を正確に見積ることが出来
る。

【００６９】−第三の実施形態− 第二の実施形態の最初に述べたように、第一の実施形態
によれば、各ＬＲＵリストの現エントリ数が全て最大数
に達していても、キャッシュに格納している実際のエン
トリ数が最大数の総和に達しておらず、利用されない領
域がキャッシュに生じてしまうことがある。これを回避
するため、第三の実施形態では、カウントの重複を見込
んで各ＬＲＵリストのエントリ数の最大数を大きめに設
定可能とし且つキャッシュに格納している全体のエント
リ数を管理する。次に、第三の実施形態を、第一の実施
形態との相違点に関して説明する。

【００７０】図２５は、第三の実施形態におけるエント
リ・キャッシュ６ｂの構造図である。このエントリ・キ
ャッシュ６ｂと第一の実施形態におけるエントリ・キャ
ッシュ６（図３）との相違点は、このエントリ・キャッ
シュ６ｂでは、キャッシュ管理テーブル２０ｂを持つこ
とである。また、全体ＬＲＵリスト８０を持つことであ
る。

【００７１】図２６は、第三の実施形態におけるキャッ
シュ管理テーブル２０ｂの構造図である。このキャッシ
ュ管理テーブル２０ｂと第一の実施形態におけるキャッ
シュ管理テーブル２０（図４）との相違点は、このキャ
ッシュ管理テーブル２０ｂが、サーバ起動時に設定され
るキャッシュ全体で格納できるエントリ数を記憶してお
く「全体ＬＲＵリストの最大エントリ数」７４と、現在
キャッシュに格納しているエントリ数を記憶している
「全体ＬＲＵリストの現エントリ数」７５と、全体ＬＲ
Ｕリスト８０の先頭エントリを指す「全体ＬＲＵリスト
の先頭ポインタ」７６および全体ＬＲＵリスト８０の末
尾エントリを指す「全体ＬＲＵリストの末尾ポインタ」
７７とを持つことである。

【００７２】図２７は、第三の実施形態におけるエント
リ５５ｂの構造図である。このエントリ５５ｂと第一の
実施形態におけるエントリ５５（図６）との相違点は、
このエントリ５５ｂでは、全体ＬＲＵ nextポインタ７
８と、全体ＬＲＵprevポインタ７９とが追加されている
ことである。

【００７３】図２８は、全体ＬＲＵリスト８０の構造図
である。この全体ＬＲＵリスト８０は、キャッシュに格
納されているすべてのエントリ５５ｂが所属する一本の
ＬＲＵリストとなっている。

【００７４】キャッシュに新たにエントリ５５ｂを格納
する場合、アクセス別分割ＬＲＵリスト７に格納するの
と同時に全体ＬＲＵリスト８０にも格納する。その際、
「全体ＬＲＵリストの現エントリ数」７５の確認を行
い、それが「全体ＬＲＵリストの最大エントリ数」７４
に達していれば、全体ＬＲＵリスト８０の末尾エントリ
を削除する。削除する際、そのエントリが所属していた
他のＬＲＵリストからの削除も行い、そのＬＲＵリスト
の現エントリ数を“１”減らす。

【００７５】上記第三の実施形態によれば、キャッシュ
に格納している全体のエントリ数を管理するため、カウ
ントの重複を見込んで各ＬＲＵリストのエントリ数の最
大数を大きめに設定することが可能であり、これによ
り、利用されない領域がキャッシュに生じてしまうこと
を回避できる。

【００７６】−第四の実施形態− 第一の実施形態では、図６に示すように、属性値リスト
５６に属性名５７と属性値５８のセットを格納している
が、ここで属性名５７は文字列としてキャッシュ領域を
消費しているため、属性名５７の文字列が長くなればキ
ャッシュ領域の消費量が大きくなってしまう。これを回
避するため、第四の実施形態では、属性名を番号で管理
する。次に、第四の実施形態を、第一の実施形態との相
違点に関して説明する。

【００７７】図２９は、第四の実施形態におけるエント
リ・キャッシュ６ｃの構造図である。このエントリ・キ
ャッシュ６ｃと第一の実施形態におけるエントリ・キャ
ッシュ６（図３）との相違点は、このエントリ・キャッ
シュ６ｃが、属性番号テーブル８１を持つことである。

【００７８】図３０は、属性番号テーブル８１の構造図
である。この属性番号テーブル８１は、エントリが持ち
得るすべての属性名８２とその通し番号である属性番号
８３を対応付けたテーブルとなっている。

【００７９】図３１は、第四の実施形態における属性値
リスト５６ｃの構造図である。この属性値リスト５６ｃ
と第一の実施形態における属性値リスト５６（図６）の
相違点は、第一の実施形態における属性値リスト５６で
は文字列の属性名５７を格納していたが、この属性値リ
スト５６ｃでは、数値の属性番号８４を格納している点
である。

【００８０】ディレクトリ・サーバ１は、各種エントリ
が持ち得るすべての属性を定義したオブジェクトクラス
定義ファイルを起動時に読み込み、それを基に属性番号
テーブル８１を作成する。アクセス要求処理を行う際に
は、属性番号テーブル８１を参照して必要な属性名８２
の属性番号８３を得て、図３２に示す必要属性番号リス
ト８５を作成する。エントリの属性をキャッシュに格納
する際は、属性名でなく、属性番号を格納する。

【００８１】上記第四の実施形態によれば、文字列の属
性名の代りに数値の属性番号を用いるため、属性名の長
さに関わらず、キャッシュのメモリ所要量を小さく抑え
ることが出来る。

【００８２】

【発明の効果】本発明のディレクトリ・サーバによれ
ば、次の効果が得られる。 （１）アクセス要求の種類別に分割してＬＲＵ管理する
ため、ある１つの種類の検索要求によって大量のエント
リがＤＢから抽出されても、他の種類のエントリがキャ
ッシュから削除されず、高ヒット率を確保できる。 （２）すべての属性をキャッシュに格納せず、必要な属
性のみをキャッシュに格納するため、アクセス頻度の低
い属性がキャッシュを消費することを防止でき、高いキ
ャッシュ効率を確保できる。

【図面の簡単な説明】

【図１】本発明の第一の実施形態にかかるディレクトリ
・サーバの機能構成図である。

【図２】本発明の第一の実施形態にかかるディレクトリ
・サーバのシステム構成図である。

【図３】第一および第二の実施形態におけるエントリ・
キャッシュの構成図である。

【図４】第一および第二の実施形態におけるキャッシュ
管理テーブルのデータ構造図である。

【図５】エントリＩＤテーブルおよびエントリＤＮテー
ブルのデータ構造図である。

【図６】第一の実施形態におけるエントリのデータ構造
図である。

【図７】第一、第二および第三の実施形態における必要
属性リストのデータ構造図である。

【図８】第一、第二、第三および第四の実施形態におけ
るアクセス別ＬＲＵリストの構造図である。

【図９】第一、第二、第三および第四の実施形態におけ
るディレクトリアクセス処理を説明するフロー図であ
る。

【図１０】第一、第二、第三および第四の実施形態にお
ける更新系要求処理を説明するフロー図である。

【図１１】第一、第二、第三および第四の実施形態にお
ける検索系要求処理を説明するフロー図である。

【図１２】第一、第二、第三および第四の実施形態にお
けるAdd要求処理を説明するフロー図である。

【図１３】第一、第二、第三および第四の実施形態にお
けるDelete要求処理を説明するフロー図である。

【図１４】第一、第二、第三および第四の実施形態にお
けるModify要求処理を説明するフロー図である。

【図１５】第一、第二、第三および第四の実施形態にお
けるModifyRDN要求処理を説明するフロー図である。

【図１６】第一、第二および第三の実施形態における属
性格納処理を説明するフロー図である。

【図１７】第一および第四の実施形態におけるキャッシ
ュエントリ追加処理を説明するフロー図である。

【図１８】第一および第四の実施形態におけるキャッシ
ュエントリ削除処理を説明するフロー図である。

【図１９】第一および第四の実施形態におけるＬＲＵリ
スト更新処理を説明するフロー図である。

【図２０】第一および第四の実施形態におけるＬＲＵリ
スト追加処理を説明するフロー図である。

【図２１】第一および第四の実施形態におけるＬＲＵリ
スト削除処理を説明するフロー図である。

【図２２】検索に関する通信プロトコル要素の説明図で
ある。

【図２３】更新に関する通信プロトコル要素の説明図で
ある。

【図２４】第二の実施形態におけるエントリのデータ構
造図である。

【図２５】第三の実施形態におけるエントリ・キャッシ
ュの構成図である。

【図２６】第三の実施形態におけるキャッシュ管理テー
ブルのデータ構造図である。

【図２７】第三の実施形態におけるエントリのデータ構
造図である。

【図２８】第三の実施形態における全体ＬＲＵリストの
説明図である。

【図２９】第四の実施形態におけるエントリ・キャッシ
ュの構成図である。

【図３０】第四の実施形態における属性番号テーブルの
データ構造図である。

【図３１】第四の実施形態におけるエントリのデータ構
造図である。

【図３２】第四の実施形態における必要属性番号リスト
のデータ構造図である。

【図３３】第一、第二、第三および第四の実施形態にお
けるエントリ・キャッシュのサイズ定義時の画面表示の
例示図である

【図３４】第一、第二、第三および第四の実施形態にお
ける属性格納処理に用いるワーク領域の説明図である。

【図３５】ディレクトリ・ツリーの説明図である。

【符号の説明】

１…ディレクトリ・サーバ、２…ディレクトリ・クライ
アント、３…通信制御部、４…プロトコル解析部、５…
アクセス別分割ＬＲＵ管理部、６…エントリキャッシ
ュ、７…アクセス別ＬＲＵリスト、８…属性管理部、９
…ＤＢ、１０…ネットワーク、１１…主メモリ、１２…
バス、１３…ディスプレイ、１４…キーボード、１５…
マウス、１６…ＣＰＵ、１７…磁気ディスク。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 菊地 聡 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 小瀧 伯泰 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウエア開発本部内 (72)発明者 石川 和男 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウエアエンジニアリング株式会 社内

Claims (12)

【特許請求の範囲】
1. 【請求項１】 ディレクトリ情報を記憶するデータベー
   スを備えたディレクトリ・サーバにおいて、エントリの
   キャッシュ格納をアクセス要求の種類別に分割してＬＲ
   Ｕ管理するアクセス別分割ＬＲＵ管理手段と、アクセス
   要求毎に必要属性のみをキャッシュ格納する属性管理手
   段とを有することを特徴とするディレクトリ・サーバ。
2. 【請求項２】 ディレクトリ情報を記憶するデータベー
   スを備えたディレクトリ・サーバにおいて、エントリの
   キャッシュ格納をアクセス要求の種類別に分割してＬＲ
   Ｕ管理するアクセス別分割ＬＲＵ管理手段を有すること
   を特徴とするディレクトリ・サーバ。
3. 【請求項３】 ディレクトリ情報を記憶するデータベー
   スを備えたディレクトリ・サーバにおいて、アクセス要
   求毎に必要属性のみをキャッシュ格納する属性管理手段
   を有することを特徴とするディレクトリ・サーバ。
4. 【請求項４】 請求項１または請求項２に記載のディレ
   クトリ・サーバにおいて、前記アクセス別分割ＬＲＵ管
   理手段は、データベースから新たに抽出したエントリを
   アクセス要求の種類別ＬＲＵリストに加えることによっ
   てキャッシュ格納を行い、アクセス要求の種類別ＬＲＵ
   リスト毎にカウントしたエントリ数に基づいてアクセス
   要求の種類別のＬＲＵ管理を行うことを特徴とするディ
   レクトリ・サーバ。
5. 【請求項５】 請求項４に記載のディレクトリ・サーバ
   において、前記アクセス別分割ＬＲＵ管理手段は、エン
   トリを加えようとしたアクセス要求の種類別ＬＲＵリス
   トのエントリ数が当該アクセス要求の種類別ＬＲＵリス
   トに設定されている最大数に達していた場合、そのアク
   セス要求の種類別ＬＲＵリストから最も過去に加えたエ
   ントリを削除し、エントリを加えることを特徴とするデ
   ィレクトリ・サーバ。
6. 【請求項６】 請求項１、請求項２、請求項４または請
   求項５に記載のディレクトリ・サーバにおいて、前記ア
   クセス別分割ＬＲＵ管理手段は、アクセス要求が更新系
   である場合、アクセス要求の処理に必要なエントリを新
   たにデータベースから抽出しても、そのエントリをキャ
   ッシュに格納しないことを特徴とするディレクトリ・サ
   ーバ。
7. 【請求項７】 請求項５に記載のディレクトリ・サーバ
   において、現在のアクセス要求の処理に必要なエントリ
   がキャッシュに既に格納されており且つ現在のアクセス
   要求の種類とは異なるアクセス要求の種類別ＬＲＵリス
   トに所属している場合、現在のアクセス要求の種類別Ｌ
   ＲＵリストに当該エントリを加えると共に現在のアクセ
   ス要求の種類別ＬＲＵリストのエントリ数を“１”増や
   さないことを特徴とするディレクトリ・サーバ。
8. 【請求項８】 請求項１、請求項２または請求項４から
   請求項７のいずれかに記載のディレクトリ・サーバにお
   いて、エントリを加えようとしたアクセス要求の種類別
   ＬＲＵリストのエントリ数が当該アクセス要求の種類別
   ＬＲＵリストに設定されている最大数に達していなくて
   も、キャッシュに格納しているエントリの総数が設定さ
   れている最大数に達していた場合、そのアクセス要求の
   種類別ＬＲＵリストから最も過去に加えたエントリを削
   除し、エントリを加えることを特徴とするディレクトリ
   ・サーバ。
9. 【請求項９】 請求項１、請求項２または請求項４から
   請求項８のいずれかに記載のディレクトリ・サーバにお
   いて、前記アクセス要求の種類別が、検索系アクセス要
   求のスコープ別であることを特徴とするディレクトリ・
   サーバ。
10. 【請求項１０】 請求項１または請求項３に記載のディ
    レクトリ・サーバにおいて、前記属性管理手段は、必要
    な属性の属性名の代りにそれに対応する属性番号をキャ
    ッシュに格納することを特徴とするディレクトリ・サー
    バ。
11. 【請求項１１】 請求項１、請求項３または請求項１０
    に記載のディレクトリ・サーバにおいて、前記属性管理
    手段は、キャッシュに全属性が格納されているか否かを
    調べ、キャッシュに全属性が格納されていない場合のみ
    必要な属性をリストアップし、その必要な属性がキャッ
    シュに格納されているか否かを調べ、必要な属性がキャ
    ッシュに格納されていない場合のみデータベースにアク
    セスすることを特徴とするディレクトリ・サーバ。
12. 【請求項１２】 請求項１、請求項３、請求項１０また
    は請求項１１に記載のディレクトリ・サーバにおいて、
    前記必要な属性は、アクセス要求により抽出を指示され
    た属性の外に、ディレクトリ情報のアクセス制御に必要
    な属性を含むことを特徴とするディレクトリ・サーバ。