JP2000035912A - ディレクトリ・サーバ - Google Patents
ディレクトリ・サーバInfo
- Publication number
- JP2000035912A JP2000035912A JP10287396A JP28739698A JP2000035912A JP 2000035912 A JP2000035912 A JP 2000035912A JP 10287396 A JP10287396 A JP 10287396A JP 28739698 A JP28739698 A JP 28739698A JP 2000035912 A JP2000035912 A JP 2000035912A
- Authority
- JP
- Japan
- Prior art keywords
- entry
- lru
- cache
- list
- access request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
確保する。 【解決手段】 ディレクトリ情報を記憶するデータベー
スDB9を備えたディレクトリ・サーバ1において、ア
クセス別分割LRU管理部5は、アクセス別LRUリス
ト7を用い、キャッシュ格納をアクセス要求の種類別に
分割してLRU管理する。属性管理部8は、アクセス要
求毎に必要属性リストを作成し、必要属性のみをキャッ
シュに格納する。 【効果】 ある1つの種類の検索要求によって大量のエ
ントリがDBから抽出されても他の種類のエントリがキ
ャッシュから削除されず、高ヒット率を確保できる。ア
クセス頻度の低い属性がキャッシュを消費することを防
止でき、高いキャッシュ効率を確保できる。
Description
ーバに関し、さらに詳しくは、高ヒット率、高キャッシ
ュ効率を確保可能なディレクトリ・サーバに関する。
SO9594)準拠のディレクトリ・サービスは、図3
5に示すディレクトリ・ツリー102のような木構造と
して階層管理されたデータモデルを有する。木の枝葉に
相当する個所には、ディレクトリ・エントリ103が配
置される。各々のエントリ103は、階層情報を含む名
称(DN:Distinguished Name)で一意に識別され
る。図35に示すように、エントリ103には、ユーザ
のメールアドレス、姓名、電話番号、FAX番号、写真
等、様々な情報を属性として記憶可能である。このよう
なディレクトリ・サービスは、電子メールシステムにお
ける電子的な電話帳として利用できる。またX.500
は、クライアント−サーバ型の分散システムアーキテク
チャを採用しており、クライアントおよびサーバの役割
を担う情報処理装置間の通信プロトコルとしてOSI
(Open Systems Interconnection)の7レイヤ構造に従
ったDAP(Directory Access Protocol)を規定して
いる。
であるIETF(Internet Engineering Task Force)
は、TCP/IP上のクライアント−サーバ間プロトコ
ルとして「LDAP:Lightweight Directory Access P
rotocol(RFC1777)」を標準化した。図22お
よび図23は、RFC1777として規定されたLDA
Pのアクセス要求の一部であり、ISO8824として
規定された抽象構文記法1(ASN.1:Abstract Syn
tax Notation One)を用いて表記している。
トリ・エントリを検索するアクセス要求である。検索系
のアクセス要求は、リード、リスト、サーチの3種に大
別できる。この3種の検索系のアクセス要求を指示する
手段として、3つのスコープがSearch61に定義されて
いる。リード要求は、特定の1エントリを抽出する要求
である。クライアントは、スコープとして、baseObject
62を指定する。リスト要求は、あるエントリの直下に
位置するエントリ(子エントリ)を抽出する要求であ
る。スコープとして、singleLevel63を指定する。サ
ーチ要求は、ディレクトリ・ツリーの部分木を対象に、
条件を満足するエントリをすべて抽出する要求である。
スコープとして、wholeSubtree64を指定する。
加するアクセス要求、Delete66はエントリを削除する
アクセス要求、Modify67はエントリ中の属性値を変更
するアクセス要求、ModifyRDN68はエントリ名を変更
するアクセス要求である。
も、コネクションを開始するBind、コネクションを切断
するUnbind、エントリ中の属性値を比較するCompare等
のアクセス要求がプロトコル要素としてRFC1777
で規定されている。
クライアントが発行したアクセス要求(図22、図2
3)を受け取り、ディレクトリ・エントリの情報が格納
されたデータベース(以下、DBと記す)にアクセスす
る。アクセス要求がSearch61等の検索系である場合、
指定された条件に合致したエントリをDBから抽出し、
ディレクトリ・クライアントへ返す。一方、アクセス要
求がAdd65、Delete66、Modify67等の更新系であ
る場合、DB上のディレクトリ情報を更新し、結果をク
ライアントへ返す。これらアクセス要求によって、ディ
レクトリ・サーバは、DBから抽出したエントリのすべ
ての情報を内部メモリ上のキャッシュに格納する。これ
はエントリ・キャッシュと呼ばれる。次回の同一エント
リへのアクセス時は、キャッシュに格納されたエントリ
・データを利用することにより、DBへのアクセス頻度
を減らし、応答性能を向上している。
(Least Recently Used)と呼ばれるキャッシュ置換ア
ルゴリズムを用いてキャッシュ格納を管理する。LRU
は、エントリのアクセス順序を記憶しておき、キャッシ
ュに格納されたエントリ数が予め設定された最大数を越
えそうになると、最も過去にアクセスされたエントリを
キャッシュから破棄した上で新たなエントリを格納する
アルゴリズムである。
を一本のLRUリストとして管理しており、最新に使用
したエントリをLRUリストの先頭に加えると共に、L
RUリストのエントリ数が予め設定された最大数を越え
そうになればLRUリストの末尾のエントリから順に削
除する。前記最大数は、ディレクトリ・サーバの起動時
に運用管理者が設定可能である。
前記サーチ要求を用いた場合、ディレクトリ・ツリーの
規模によっては、1つの検索要求に対して大量のエント
リがDBから抽出される場合がある。ところが、従来の
ディレクトリ・サーバでは、キャッシュが1本のLRU
リストで管理されていたため、大量のエントリがDBか
ら抽出された場合、1つの検索要求によりキャッシュの
内容が一掃されることがある。つまり、それまでアクセ
ス頻度の高かったエントリが、1つの検索要求によりキ
ャッシュから削除されてしまい、ヒット率を低下させる
という問題点があった。
クセスされたエントリが持つ全ての属性をキャッシュに
格納するため、アクセス頻度の低い属性がキャッシュを
消費してしまい、キャッシュ効率を低下させるという問
題点があった。
索要求によって大量のエントリがDBから抽出されて
も、ヒット率の高かったエントリを一掃せずに、高ヒッ
ト率を確保可能なディレクトリ・サーバを提供すること
にある。
度の低い属性がキャッシュを消費することを防止でき、
高いキャッシュ効率を確保可能なディレクトリ・サーバ
を提供することにある。
は、ディレクトリ情報を記憶するデータベースを備えた
ディレクトリ・サーバにおいて、エントリのキャッシュ
格納をアクセス要求の種類別に分割してLRU管理(L
RUアルゴリズムによるキャッシュ管理)するアクセス
別分割LRU管理手段と、アクセス要求毎に必要属性の
みをキャッシュ格納する属性管理手段とを有することを
特徴とするディレクトリ・サーバを提供する。上記第1
の観点のディレクトリ・サーバでは、アクセス要求の種
類別に分割してLRU管理するため、ある1つの種類の
検索要求によって大量のエントリがDBから抽出されて
も、他の種類のエントリがキャッシュから削除されず、
高ヒット率を確保できる。また、すべての属性をキャッ
シュに格納せず、必要な属性のみをキャッシュに格納す
るため、アクセス頻度の低い属性がキャッシュを消費す
ることを防止でき、高いキャッシュ効率を確保できる。
情報を記憶するデータベースを備えたディレクトリ・サ
ーバにおいて、エントリのキャッシュ格納をアクセス要
求の種類別に分割してLRU管理するアクセス別分割L
RU管理手段を有することを特徴とするディレクトリ・
サーバを提供する。上記第2の観点のディレクトリ・サ
ーバでは、アクセス要求の種類別に分割してLRU管理
するため、ある1つの種類の検索要求によって大量のエ
ントリがDBから抽出されても、他の種類のエントリが
キャッシュから削除されず、高ヒット率を確保できる。
情報を記憶するデータベースを備えたディレクトリ・サ
ーバにおいて、アクセス要求毎に必要属性のみをキャッ
シュ格納する属性管理手段を有することを特徴とするデ
ィレクトリ・サーバ。上記第3の観点のディレクトリ・
サーバでは、すべての属性をキャッシュに格納せず、必
要な属性のみをキャッシュに格納するため、アクセス頻
度の低い属性がキャッシュを消費することを防止でき、
高いキャッシュ効率を確保できる。
は第2の観点のディレクトリ・サーバにおいて、前記ア
クセス別分割LRU管理手段は、データベースから新た
に抽出したエントリをアクセス要求の種類別LRUリス
トに加えることによってキャッシュ格納を行い、アクセ
ス要求の種類別LRUリスト毎にカウントしたエントリ
数に基づいてアクセス要求の種類別のLRU管理を行う
ことを特徴とするディレクトリ・サーバを提供する。ま
た、第5の観点では、本発明は、上記第4の観点のディ
レクトリ・サーバにおいて、前記アクセス別分割LRU
管理手段は、エントリを加えようとしたアクセス要求の
種類別LRUリストのエントリ数が当該アクセス要求の
種類別LRUリストに設定されている最大数に達してい
た場合、そのアクセス要求の種類別LRUリストから最
も過去に加えたエントリを削除し、エントリを加えるこ
とを特徴とするディレクトリ・サーバを提供する。上記
第4および第5の観点のディレクトリ・サーバでは、ア
クセス要求の種類別に分割したLRUリストを用い、そ
れらLRUリスト毎にLRU管理するため、アクセス要
求の種類別のLRU管理を好適に行うことが出来る。
2、第4または第5の観点のディレクトリ・サーバにお
いて、前記アクセス別分割LRU管理手段は、アクセス
要求が更新系である場合、アクセス要求の処理に必要な
エントリを新たにデータベースから抽出しても、そのエ
ントリをキャッシュに格納しないことを特徴とするディ
レクトリ・サーバを提供する。上記第6の観点のディレ
クトリ・サーバでは、アクセス頻度が低い更新系のアク
セス要求に対してはキャッシュを使用しない。このた
め、アクセス頻度が高い検索系のアクセス要求が優先的
にキャッシュを使用できるようになり、全体としてキャ
ッシュ効率を向上できる。
クトリ・サーバにおいて、現在のアクセス要求の処理に
必要なエントリがキャッシュに既に格納されており且つ
現在のアクセス要求の種類とは異なるアクセス要求の種
類別LRUリストに所属している場合、現在のアクセス
要求の種類別LRUリストに当該エントリを加えると共
に現在のアクセス要求の種類別LRUリストのエントリ
数を“1”増やさないことを特徴とするディレクトリ・
サーバを提供する。アクセス要求の種類別に分割したL
RUリスト毎にLRU管理する場合、LRUリスト毎に
エントリ数をカウントすることが原則であるが、あるエ
ントリが複数のLRUリストに所属するとき、そのエン
トリのカウントが重複して行われ、実際にはキャッシュ
に余裕があるのに、エントリの入れ換えが行われてしま
うことがある。上記第7の観点のディレクトリ・サーバ
では、あるエントリが複数のLRUリストに所属すると
き、そのエントリのカウントは、最初に所属したLRU
リストのみで行う。これにより、1つのエントリが重複
してカウントすることが防止されるため、必要のないエ
ントリの入れ換えが抑制され、キャッシュの使用効率を
向上できる。
2または第4から第7の観点のいずれかのディレクトリ
・サーバにおいて、エントリを加えようとしたアクセス
要求の種類別LRUリストのエントリ数が当該アクセス
要求の種類別LRUリストに設定されている最大数に達
していなくても、キャッシュに格納しているエントリの
総数が設定されている最大数に達していた場合、そのア
クセス要求の種類別LRUリストから最も過去に加えた
エントリを削除し、エントリを加えることを特徴とする
ディレクトリ・サーバを提供する。アクセス要求の種類
別に分割したLRUリスト毎にLRU管理する場合、L
RUリスト毎にエントリ数をカウントすることが原則で
あるが、あるエントリが複数のLRUリストに所属する
とき、そのエントリのカウントが重複して行われ、実際
にはキャッシュに余裕があるのに、エントリの入れ換え
が行われてしまうことがある。上記第8の観点のディレ
クトリ・サーバでは、アクセス要求の種類別に分割した
LRUリスト毎にLRU管理を行うのに加えて、キャッ
シュに格納しているエントリの総数でもLRU管理を行
う。これにより、アクセス要求の種類別に分割したLR
Uリスト毎に設定する最大数を大きめに設定しても、全
体としてのキャッシュ動作に支障を生じない。そして、
アクセス要求の種類別に分割したLRUリスト毎に設定
する最大数を大きめに設定しておけば、1つのエントリ
を重複してカウントしても、必要のないエントリの入れ
換えが起らず、キャッシュの使用効率を向上できる。
2または第4から第8の観点のいずれかのディレクトリ
・サーバにおいて、前記アクセス要求の種類別が、検索
系アクセス要求のスコープ別であることを特徴とするデ
ィレクトリ・サーバを提供する。上記第9の観点のディ
レクトリ・サーバでは、検索系アクセス要求のスコープ
別にLRU管理を行うため、前記リスト要求または前記
サーチ要求を用いた1つの検索要求に対して大量のエン
トリがDBから抽出されても、前記リード要求で抽出さ
れたエントリがキャッシュから削除されることはない。
一般に、リード要求のエントリの使用の頻度が高いた
め、全体として高ヒット率を確保できる。
たは第3の観点のディレクトリ・サーバにおいて、前記
属性管理手段は、必要な属性の属性名の代りにそれに対
応する属性番号をキャッシュに格納することを特徴とす
るディレクトリ・サーバを提供する。上記第10の観点
のディレクトリ・サーバでは、文字列の属性名の代りに
数値の属性番号を用いるため、属性名の長さに関わら
ず、キャッシュのメモリ所要量を小さく抑えることが出
来る。
第3または第10の観点のディレクトリ・サーバにおい
て、前記属性管理手段は、キャッシュに全属性が格納さ
れているか否かを調べ、キャッシュに全属性が格納され
ていない場合のみ必要な属性をリストアップし、その必
要な属性がキャッシュに格納されているか否かを調べ、
必要な属性がキャッシュに格納されていない場合のみデ
ータベースにアクセスすることを特徴とするディレクト
リ・サーバを提供する。上記第11の観点のディレクト
リ・サーバでは、キャッシュに全属性が格納されている
か否かを調べ、全属性が格納されている場合は、必要な
属性のリストアップやデータベースへのアクセスを行わ
ない。全属性が格納されていない場合には、必要な属性
のリストアップを行うが、そのリストアップした必要な
属性がキャッシュに格納されているか否かを調べ、格納
されている場合は、データベースへのアクセスを行わな
い。これにより、作業量を最小限に抑制することが出来
る。
第3、第10または第11の観点のディレクトリ・サー
バにおいて、前記必要な属性は、アクセス要求により抽
出を指示された属性の外に、ディレクトリ情報のアクセ
ス制御に必要な属性を含むことを特徴とするディレクト
リ・サーバを提供する。上記第12の観点のディレクト
リ・サーバでは、ディレクトリ情報のアクセス制御に必
要な属性もキャッシュに格納するため、キャッシュに格
納しない場合に比べて応答性を向上できる。
図面を用いて説明する。なお、これにより本発明が限定
されるものではない。
・サーバの機能構成図である。このディレクトリ・サー
バ1は、ディレクトリ情報を記憶管理するDB9を備え
ている。また、ディレクトリ・サーバ1は、LAN等の
ネットワーク10を介してディレクトリ・クライアント
2と通信するための通信処理を実行する通信制御部3
と、ディレクトリ・クライアント2からディレクトリ情
報に対するアクセス要求を受け付け内容を解析するプロ
トコル解析部4と、アクセス要求の種類別に分割された
LRUリスト7を持つエントリ・キャッシュ6と、エン
トリのキャッシュ6への格納をアクセス要求の種類別に
分割してLRU管理するアクセス別分割LRU管理部5
と、アクセス要求毎に必要な属性のみを抽出しキャッシ
ュ6に格納する属性管理部8とを具備している。DB9
は、各ディレクトリ・エントリの情報を記憶管理するD
B管理システムであり、例えばISAM(Indexed Sequ
ential Access Method)が挙げられる。
ム構成図である。図中、図1の構成要素と対応する構成
要素には同一符号を付している。ディレクトリ・サーバ
1は、CPU16と、主メモリ11と、ハードディスク
装置等の磁気ディスク17と、バス12と、ディスプレ
イ13と、キーボード14と、マウス等のポインティン
グデバイス15とから構成される。主メモリ11には、
エントリ・キャッシュ6と、通信制御プログラム(部)
3と、プロトコル解析プログラム(部)4と、アクセス
別分割LRU管理プログラム(部)5と、属性管理プロ
グラム(部)8と、DB管理プログラム19とが格納さ
れる。これらのプログラムは、当初磁気ディスク17に
格納され、必要に応じて主メモリ11に転送された後、
CPU16で実行される。磁気ディスク17には、ディ
レクトリ・データ18がファイルとして格納される。デ
ィレクトリ・データ18は、エントリ・データ100
と、インデックス101とから成る。エントリ・データ
100は、ディレクトリ・サーバ1が保持するすべての
エントリと各々のエントリが持つすべての属性とを格納
している。エントリ・データ100に格納されているす
べてのエントリは、各々が一意な番号であるIDを持
つ。このIDをキーとして、ディレクトリ・サーバ1は
DB9へのアクセスを行う。インデックス101は、エ
ントリのDNや属性値についてのインデックスであり、
DNや属性値とそれを持つエントリのIDの関係を保持
する。なお、DB管理プログラム19とディレクトリ・
データ18とからDB9が構成される。
成図である。エントリ・キャッシュ6は、キャッシュ管
理情報を格納するキャッシュ管理テーブル20と、キャ
ッシュ中のエントリとIDとの関係を記憶するエントリ
IDテーブル21と、キャッシュ中のエントリとDNの
関係を記憶するエントリDNテーブル22と、図15の
Search61のbaseObject62を用いた検索によってDB
9から抽出されキャッシュに格納されたエントリを管理
するbase LRUリスト23と、図15のSearch61のs
ingleLevel63を用いた検索によってDB9から抽出さ
れキャッシュに格納されたエントリを管理するone-leve
l LRUリスト24と、図15のSearch61のwholeSub
tree64を用いた検索によってDB9から抽出されキャ
ッシュに格納されたエントリを管理するsubtree LRU
リスト25とを具備している。前記3本のLRUリスト
23,24,25からアクセス別LRUリスト7が構成
される。
成図である。「base LRUリストの最大エントリ数」
26、「one-level LRUリストの最大エントリ数」3
0および「subtree LRUリストの最大エントリ数」3
4は、それぞれbase LRUリスト23、one-level L
RUリスト24およびsubtreeLRUリスト25で管理
できるエントリの最大数であり、ディレクトリ・サーバ
起動時に運用管理者等が設定した値が登録されている。
「base LRUリストの現エントリ数」27、「one-lev
el LRUリストの現エントリ数」31および「subtree
LRUリストの現エントリ数」35は、それぞれbase
LRUリスト23、one-level LRUリスト24および
subtree LRUリスト25で現在管理しているエントリ
数を記憶している。「base LRUリストの先頭ポイン
タ」28および「base LRUリストの末尾ポインタ」
29は、base LRUリスト23の先頭および末尾のエ
ントリをそれぞれ指している。同様に、「one-level L
RUリストの先頭ポインタ」32および「one-level L
RUリストの末尾ポインタ」33は、one-level LRU
リスト24の先頭および末尾のエントリをそれぞれ指し
ている。また、「subtree LRUリストの先頭ポイン
タ」36および「subtree LRUリストの末尾ポイン
タ」37は、subtree LRUリスト25の先頭および末
尾のエントリをそれぞれ指している。
evel LRUリスト24およびsubtree LRUリスト2
5で管理するエントリの最大数(サイズ)を運用管理者
等が設定するための画面の例示図である。この画面90
には、base LRUリスト23での最大数を入力する領
域91、one-level LRUリスト24での最大数を入力
する領域92、subtree LRUリスト25での最大数を
入力する領域93および入力した情報を登録するための
ボタン94とがある。この画面90は、ディレクトリ・
サーバ1の起動時に、アクセス別分割LRU管理部5
が、ディスプレイ13に表示する。また、アクセス別分
割LRU管理部5は、キーボード14やマウス15によ
る入力等を制御する。運用管理者は、キーボード14を
用いてbase LRUリスト23の領域91、one-level
LRUリスト24の領域92、subtree LRUリスト2
5の領域93にそれぞれ最大数を入力し、OKボタン9
4をマウス15でクリックする。これを受けて、アクセ
ス別分割LRU管理部5は、各領域91、92および9
3に入力された最大数を、キャッシュ管理テーブル20
の「base LRUリストの最大エントリ数」26、「one
-level LRUリストの最大エントリ数」30および「s
ubtree LRUリストの最大エントリ数」34に登録す
る。
図である。エントリIDテーブル21は、複数個のノー
ド38を組み合わせて構成されるバランスツリー構造と
なっている。ノード38は、あるエントリを指すエント
リポインタ39と、左右のノードを指すノードポインタ
40,41とを持っている。IDをキーとしてエントリ
IDテーブル21のノードをたどれば、そのIDを持つ
エントリを得ることが出来る。エントリDNテーブル2
2も同様の構造であり、DNをキーとしてエントリDN
テーブル22のノードをたどれば、そのDNを持つエン
トリを得ることが出来る。
55の構造図である。エントリ名(DN)42とエント
リID43には、このエントリ55のDNとIDを格納
する。全属性フラグ44には、このエントリ55の全て
の属性をキャッシュに格納している場合は“1”を設定
し、一部の属性だけをキャッシュに格納している場合は
“0”を設定する。属性値リストポインタ45は、属性
値リスト56を指している。属性値リスト56は、属性
名57と属性値58を1セットとする配列構造をなして
おり、このエントリ55の全属性もしくは一部の属性を
格納している。
ントリ55がbase LRUリスト23に所属していれば
“1”を設定し、所属していなければ“0”を設定す
る。one-level LRU所属フラグ49には、このエント
リ55がone-level LRUリスト24に所属していれば
“1”を設定し、所属していなければ“0”を設定す
る。subtree LRU所属フラグ52には、このエントリ
55がsubtree LRUリスト25に所属していれば
“1”を設定し、所属していなければ“0”を設定す
る。
LRU prevポインタ48には、このエントリ55がba
se LRUリスト23に所属していれば、このエントリ
55の前後のエントリを指すポインタをそれぞれ格納す
る。このエントリ55がbaseLRUリスト23の先頭エ
ントリであれば、base LRU prevポインタ48には
“NULL”を格納する。一方、このエントリ55が末
尾エントリであれば、base LRU nextポインタ47に
は“NULL”を格納する。one-level LRU nextポ
インタ50およびone-level LRU prevポインタ51
には、このエントリ55がone-level LRUリスト24
に所属していれば、このエントリ55の前後のエントリ
を指すポインタをそれぞれ格納する。このエントリ55
がone-level LRUリスト24の先頭エントリであれ
ば、one-level LRU prevポインタ51には“NUL
L”を格納する。一方、このエントリ55が末尾エント
リであれば、one-level LRU nextポインタ50には
“NULL”を格納する。subtree LRU nextポイン
タ53およびsubtree LRU prevポインタ54には、
このエントリ55がsubtree LRUリスト25に所属し
ていれば、このエントリ55の前後のエントリを指すポ
インタをそれぞれ格納する。このエントリ55がsubtre
e LRUリスト25の先頭エントリであれば、subtree
LRU prevポインタ54には“NULL”を格納す
る。一方、このエントリ55が末尾エントリであれば、
subtree LRU nextポインタ53には“NULL”を
格納する。
る。必要属性リスト59は、属性名60を要素とする配
列構造をなしており、ディレクトリ・サーバ1が受け取
ったアクセス要求を処理するのに必要となる属性の名前
のリストである。
図である。アクセス別LRUリスト7は、base LRU
リスト23、one-level LRUリスト24およびsubtre
e LRUリスト25から構成されている。複数のLRU
リストが集まっているエントリ55は、複数のLRUリ
ストに所属しているエントリである。
ディレクトリ・サーバ1の動作を表すフローチャートで
ある。通信制御部3がディレクトリ・クライアント2か
らのアクセス要求を受信すると(S0901)、プロト
コル解析部4がアクセス要求を解析し(S0902)、
アクセス要求が検索系要求でなければ更新系要求処理を
行い(S0904)、検索系要求であれば検索系要求処
理を行う(S0905)。
04)を表すフローチャートである。アクセス要求がAd
d要求であった場合は(S1001)、Add要求処理を行
い(S1002)、Delete要求であった場合は(S10
03)は、Delete要求処理を行い(S1004)、Modi
fy要求であった場合は(S1005)、Modify要求処理
を行い(S1006)、それ以外の場合はModifyRDN要
求処理を行う(S1007)。
5)を表すフローチャートである。(S1112)で
は、アクセス別分割LRU管理部5は、ディレクトリデ
ータ18のインデックス101を用いて、検索条件に指
定されている属性を持つエントリのIDをリストアップ
する。(S1101)では、リストアップしたIDを基
にエントリ・キャッシュ6のエントリIDテーブル21
およびエントリDNテーブル22を参照し、検索対象の
エントリがキャッシュ中に格納されているかを確認す
る。(S1102)では、検索対象のエントリがキャッ
シュ中に格納されている場合は(S1103)へ進み、
格納されていない場合は(S1113)へ進む。
れていたエントリ55の全属性フラグ44の値が“0”
であった場合は(S1105)へ進み、“1”であった
場合は(S1110)へ進む。(S1105)では、属
性管理部8が、主メモリ11上に新たに領域を確保し、
検索要求のスコープおよび要求属性から必要属性リスト
59を作成する。(S1106)では、その必要属性が
エントリ55が持つ属性値リスト56にすべて存在する
なら(S1110)へ進み、一部しか存在しないなら
(S1107)へ進む。
U管理部5はDB9にアクセスしてエントリの情報を取
り出し、属性管理部8に渡す。属性管理部8は、渡され
たエントリを、図34に示すように、ワーク領域95に
エントリ55’として格納する。(S1108)では、
属性管理部8は、必要属性リスト59に従って必要な属
性のみをキャッシュ中のエントリ55に加える。この
時、検索要求の内容がエントリのすべての属性を取り出
すものであればエントリ55の全属性フラグ44に
“1”を設定する。例えば、アクセス要求Search61の
内容を確認し、検索条件に合致したエントリのどの属性
を要求しているかを表すattribute99の内容がすべて
の属性を要求していることを表す“NULL”であれ
ば、エントリ55の全属性フラグ44に“1”を設定す
る。そして、(S1110)へ進む。
U管理部5は、検索要求のスコープに該当するLRUリ
スト23または24または25を更新する。そして、
(S1111)へ進む。
トリ・クライアント2に送信する。そして、処理を終了
する。
U管理部5は、DB9から読み出したエントリを格納す
るための領域(空のエントリ55)と、属性を格納する
ための属性値リストの領域(空の属性値リスト56)を
確保する。その空のエントリ55のエントリ名(DN)
42および各LRUポインタ47、48、50、51、
53、54は“NULL”に設定し、エントリID43
および各フラグ44、46、49、52は“0”に設定
し、属性値リストポインタ45は空の属性値リスト56
を指すよう設定する。空の属性値リスト56の属性名5
7および属性値58には“NULL”を設定する。(S
1104)では、属性管理部8は、必要属性リスト59
を作成する。(S1107)では、アクセス別分割LR
U管理部5は、DB9にアクセスしてエントリの情報を
取り出し、属性管理部8に渡す。属性管理部8は、図3
4に示すように、渡されたエントリ55’をワーク領域
95に格納する。(S1108)では、属性管理部8
は、必要な属性のみを属性値リスト56に加える。この
時、検索要求の内容がエントリのすべての属性を取り出
すものであればエントリ55の全属性フラグ44に
“1”を設定する。(S1109)では、アクセス別分
割LRU管理部5は検索要求のスコープに該当するLR
Uリスト23または24または25にエントリ55を加
える。そして、前記(S1111)へ進む。
02)を表すフローチャートである。アクセス別分割L
RU管理部5はエントリ・キャッシュ6のエントリID
テーブル21およびエントリDNテーブル22を参照
し、Add要求で指示された追加対象のエントリがキャッ
シュ中に格納されているかを確認し(S1201)、格
納されている場合(S1202)、処理結果としてエラ
ーを返す(S1209)。キャッシュ中に格納されてな
かった場合(S1202)、DB9にアクセスし(12
03)、追加するエントリがDB9に存在するかを確認
し存在した場合(S1204)、処理結果としてエラー
を返す(S1209)。DB9に存在しなかった場合
(S1204)、Add要求で指示されたエントリをDB
9に追加し(S1206)、処理結果を送信する(S1
208)。
004)を表すフローチャートである。アクセス別分割
LRU管理部5はエントリ・キャッシュ6のエントリI
Dテーブル21およびエントリDNテーブル22を参照
し、Delete要求で指示された削除対象のエントリがキャ
ッシュ中に格納されているかを確認する(S130
1)。格納されていた場合(S1302)、それをキャ
ッシュから削除し(S1304)、DB9にアクセスし
てDelete要求で指示された削除を行い(S1305)、
結果を送信する(S1306)。キャッシュ中に格納さ
れていなかった場合(S1302)、DB9にアクセス
してDelete要求で指示された削除を行い(S130
5)、結果を送信する(S1306)。
006)を表すフローチャートである。アクセス別分割
LRU管理部5はエントリ・キャッシュ6のエントリI
Dテーブル21およびエントリDNテーブル22を参照
し、Modify要求で指示された更新対象のエントリがキャ
ッシュ中に格納されているかを確認する(S140
1)。格納されていた場合(S1402)、そのエント
リ55が持つ属性値リスト56を参照して更新対象の属
性が存在した場合(S1403)は更新対象の属性の値
58をModify要求にしたがって変更し(S1404)、
DB9にアクセスしてModify要求で指示された更新を行
い(S1405)、結果を送信する(S1406)。更
新対象の属性が存在しなかった場合(S1403)、D
B9にアクセスしてModify要求で指示された更新を行い
(S1405)、結果を送信する(S1406)。キャ
ッシュ中にエントリが格納されていなかった場合(S1
402)、DB9にアクセスしてModify要求で指示され
た属性の更新を行い(S1405)、結果を送信する
(S1406)。
(S1007)を表すフローチャートである。アクセス
別分割LRU管理部5はエントリ・キャッシュ6のエン
トリIDテーブル21およびエントリDNテーブル22
を参照し、ModifyRDN要求で指示された更新対象のエン
トリがキャッシュ中に格納されているかを確認する(S
1501)。格納されていた場合(S1502)、該エ
ントリ55のDNを変更し(S1503)、DB9にア
クセスしModifyRDN要求で指示されたDNの変更を行い
(S1504)、結果を送信する(S1505)。キャ
ッシュに格納されていなかった場合(S1502)、D
B9にアクセスしModifyRDN要求で指示されたDNの変
更を行い(S1504)、結果を送信する(S150
5)。
08)を表すフローチャートである。(S1601)で
は、属性管理部8は、必要属性リスト59の一つの属性
名60に着目する。(S1602)では、キャッシュに
格納されているエントリ55の属性値リスト56の属性
名57を参照し、前記着目した属性名60がなければ
(S1603)へ進み、前記着目した属性名60があれ
ば(S1604)へ進む。(S1603)では、ワーク
領域95のエントリ55’の属性値リスト56の属性名
57と属性値58を取り出し、キャッシュのエントリ5
5の属性値リスト56の最後に追加する。(S160
4)では、必要属性リスト59の次の一つの属性名60
に着目する。(S1605)では、前記(S1604)
で未処理の属性名60があれば前記(S1602)に戻
り、未処理の属性名60がなければ処理を終わる。
加処理(S1109)を表すフローチャートである。ア
クセス別分割LRU管理部5は、ノード38の領域を2
つ確保し、追加するエントリ55を指すようにそれらノ
ード38のエントリポインタ39を設定し、エントリI
Dテーブル21のツリーのノードを頂点から辿って挿入
点を探索し、2つのノード38のうちの一つをエントリ
IDテーブル21のツリーに挿入し、左右のノードを指
すようノードポインタ40,41を適宜セットし、同様
にしてもう一つのノード38をエントリDNテーブル2
2のツリーに挿入する(S1701)。次に、検索要求
のスコープを確認し(S1702)、そのスコープのL
RUリストの先頭にエントリ55を追加する(S170
3)。さらに追加したLRUリストの現エントリ数を確
認し(S1704)、該LRUリストの最大数を超えて
いない場合(S1705)、処理を終了する。該LRU
リストの最大数を超えた場合(S1705)、該LRU
リストの末尾のエントリ55を確認し(S1706)、
LRUリスト削除処理を行う(S1707)。さらにそ
の末尾のエントリ55の該LRUリスト以外の所属フラ
グの値がどちらも“0”であった場合(S1708)は
そのエントリ55が他のLRUに属していないので、キ
ャッシュから完全に削除するためキャッシュエントリ削
除処理(S1304)を行う。前記末尾のエントリ55
の該LRUリスト以外の所属フラグの値の少なくとも一
つが“1”であった場合(S1708)は他のLRUに
属しているので、キャッシュエントリ削除処理(S13
04)は行わないで、処理を終了する。
ュエントリ削除処理(S1304)を表すフローチャー
トである。(S1801)では、アクセス別分割LRU
管理部5は、削除対象のエントリ55のbase LRU所
属フラグ46の値が“1”であれば(S1802)へ進
み、“0”であれば(S1804)へ進む。(S180
2)では、キャッシュ管理テーブル20の「base LR
Uリストの現エントリ数」27を“1”減らす。(S1
803)では、削除対象のエントリをbase LRUリス
ト23から削除する。
55のone-level LRU所属フラグ49の値が“1”で
あれば(S1805)へ進み、“0”であれば(S18
04)へ進む。(S1805)では、キャッシュ管理テ
ーブル20の「one-level LRUリストの現エントリ
数」31を“1”減らす(S1805)。(S180
6)では、削除対象のエントリをone-level LRUリス
ト24から削除する(S1806)。
55のsubtree LRU所属フラグ52の値が“1”であ
れば(S1808)へ進み、“0”であれば(S181
0)へ進む。(S1808)では、キャッシュ管理テー
ブル20の「subtree LRUリストの現エントリ数」3
5を“1”減らす。(S1809)では、削除対象のエ
ントリをsubtree LRUリスト25から削除する。
55および属性リスト56を格納していた主メモリ11
上の領域を開放して終了する。
理(S1110)を表すフローチャートである。アクセ
ス別分割LRU管理部5は、アクセス要求のスコープを
確認し(S1901)、そのスコープのLRUリストか
らエントリを削除し(S1707)、同じエントリをL
RUリストの先頭に追加する(S1703)。以上の処
理により、LRUリスト中のエントリが、そのLRUリ
ストの先頭に移動する。
リスト追加処理(S1703)を表すフローチャートで
ある。(S2001)では、アクセス別分割LRU管理
部5は、検索要求のスコープがbaseObject62であれば
(S2002)へ進み、そうでなければ(S2005)
へ進む。(S2002)では、キャッシュ管理テーブル
20の「base LRUリストの現エントリ数」27を
“1”増やす。(S2003)では、エントリをbase
LRUリスト23の先頭に追加する。すなわち、キャッ
シュ管理テーブル20の「base LRUリストの先頭ポ
インタ」28の内容を、このエントリ55のbase LR
U nextポインタ47にコピーし、次に「base LRUリ
ストの先頭ポインタ」28がこのエントリ55を指すよ
うにセットする。また、このエントリ55のbase LR
U prevポインタ48には“NULL”をセットする。
(S2004)では、エントリ55のbase LRU所属
フラグ46の値を“1”にセットする。そして、処理を
終了する。
がsingleLevel63であれば(S2006)へ進み、そ
うでなければ(S2009)へ進む。(S2006)で
は、キャッシュ管理テーブル20の「one-level LRU
リストの現エントリ数」31を“1”増やす。(S20
07)では、エントリ55をone-level LRUリスト2
4の先頭に追加する。すなわち、キャッシュ管理テーブ
ル20の「one-level LRUリストの先頭ポインタ」3
2の内容を、このエントリ55のone-level LRU nex
tポインタ50にコピーし、次に「one-level LRUリ
ストの先頭ポインタ」32がこのエントリ55を指すよ
うにセットする。また、このエントリ55のone-level
LRU prevポインタ51には“NULL”をセットす
る。(S2008)では、エントリ55のone-level L
RU所属フラグ49の値を“1”にセットする。そし
て、処理を終了する。
がwholeSubtree64であれば(S2010)へ進み、そ
うでなければ処理を終了する。(S2010)では、キ
ャッシュ管理テーブル20の「subtree LRUリストの
現エントリ数」35を“1”増やす。(S2011)で
は、エントリ55をsubtree LRUリスト25の先頭に
追加する。すなわち、キャッシュ管理テーブル20の
「subtree LRUリストの先頭ポインタ」36の内容
を、このエントリ55のsubtree LRU nextポインタ
53にコピーし、次に「subtree LRUリストの先頭ポ
インタ」36がこのエントリ55を指すようにセットす
る。また、このエントリ55のsubtree LRU prevポ
インタ54には“NULL”をセットする。(S201
2)では、エントリ55のsubtree LRU所属フラグ5
2の値を“1”にセットする(S2012)。そして、
処理を終了する。
リスト削除処理(S1707)を表すフローチャートで
ある。(S2101)では、アクセス別分割LRU管理
部5は、検索要求のスコープがbaseObject62であれば
(S2102)へ進み、そうでなければ(S2105)
へ進む。(S2102)では、キャッシュ管理テーブル
20の「base LRUリストの現エントリ数」27を
“1”減らす。(S2103)では、エントリをbase
LRUリスト23から削除する。すなわち、削除対象の
エントリ55のbase LRU nextポインタ47の内容
を、削除対象のエントリ55のbase LRU prevポイン
タ48が指すエントリのbase LRU nextポインタ47
にコピーし、次に削除対象のエントリ55のbase LR
Uprevポインタ48の内容を、削除対象のエントリ55
のbase LRU nextポインタ47が指すエントリのbase
LRU prevポインタ48にコピーする。(S210
4)では、エントリ55のbase LRU所属フラグ46
の値を“0”にセットする。そして、処理を終了する。
がsingleLevel63であれば(S2106)へ進み、そ
うでなければ(S2109)へ進む。(S2106)で
は、キャッシュ管理テーブル20の「one-level LRU
リストの現エントリ数」31を“1”減らす。(S21
07)では、エントリをone-level LRUリスト24か
ら削除する。すなわち、削除対象のエントリ55のone-
level LRU nextポインタ50の内容を、削除対象の
エントリ55のone-level LRU prevポインタ51が
指すエントリのone-level LRU nextポインタ50に
コピーし、次に削除対象のエントリ55のone-level L
RU prevポインタ51の内容を、削除対象のエントリ
55のone-level LRU nextポインタ50が指すエン
トリのone-level LRUprevポインタ51にコピーす
る。(S2108)では、エントリ55のone-level L
RU所属フラグ49の値を“0”にセットする。
がwholeSubtree64であれば(S2110)へ進み、そ
うでなければ処理を終了する。(S2110)では、キ
ャッシュ管理テーブル20の「subtree LRUリストの
現エントリ数」35を“1”減らす。(S2111)で
は、エントリ55をsubtree LRUリスト25から削除
する。すなわち、削除対象のエントリ55のsubtree L
RU nextポインタ53の内容を、削除対象のエントリ
55のsubtree LRU prevポインタ54が指すエント
リのsubtree LRU nextポインタ53にコピーし、次
に削除対象のエントリ55のsubtree LRU prevポイ
ンタ54の内容を、削除対象のエントリ55のsubtree
LRU nextポインタ53が指すエントリのsubtree L
RU prevポインタ54にコピーする。(S2112)
では、エントリ55のsubtree LRU所属フラグ52の
値を“0”にセットする。そして、処理を終了する。
・サーバ1によれば、検索要求Search61によってDB
9から抽出したエントリを、その検索スコープ(baseOb
ject62、singleLevel63およびwholeSubtree64)
別に分割した3本のLRUリスト23、24、25に加
えて、スコープ別にURL管理するので、ある検索スコ
ープでDB9から大量のエントリが抽出された場合で
も、別の検索スコープのヒット率の高かったエントリを
一掃せず、高ヒット率を確保可能となる。また、必要な
属性のみをキャッシュに格納するので、アクセス頻度の
低い属性がキャッシュを消費することを防止でき、高い
キャッシュ効率を確保可能となる。
で指定された属性のみをキャッシュに格納しているが、
指定されていない属性(例えばディレクトリ・サーバ1
がエントリへのアクセス制御を実施するために必要な属
性)をもキャッシュに格納するようにしても良い。ま
た、上記第一の実施形態では、更新系要求によってDB
9から読み出されたエントリについてはキャッシュへの
格納を行っていないが、これをキャッシュに格納し、任
意のLRUリスト(例えばbase LRUリスト23)を
用いて管理するようにしてもよい。
立にカウントしているため、1つのエントリが複数のL
RUリストに所属している場合(図8)、1つのエント
リが各LRUリストで重複してカウントされる。このた
め、各LRUリストの現エントリ数が全て最大数に達し
ていても、キャッシュに格納している実際のエントリ数
は最大数の総和に達しておらず、利用されない領域がキ
ャッシュに生じてしまうことがある。これを回避するた
め、第二の実施形態では、1つのエントリが複数のLR
Uリストに所属している場合、最初に所属したLRUリ
ストにおいてのみエントリ数としてカウントする。次
に、第二の実施形態を、第一の実施形態との相違点に関
して説明する。
リ55aの構造図である。このエントリ55aと第一の
実施形態におけるエントリ55(図6)との相違点は、
第一の実施形態におけるエントリ55のbase LRU所
属フラグ46、one-level LRU所属フラグ49、subt
ree LRU所属フラグ52に代えて、このエントリ55
aでは、第1所属コード71、第2所属コード72、第
3所属コード73を持つことである。これら所属コード
71〜73には、図22のSearch61の検索スコープで
あるbaseObject62、singleLevel63、wholeSubtree
64の値(1、2、3のいずれか)をセットし、該エン
トリ55aがどのような順序でどのLRUリストに所属
したかを表す。
55aを格納する場合、アクセス要求のスコープに該当
するLRUリストの先頭にエントリ55aを加え、第1
所属コード71にスコープの値(“1”“2”“3”の
いずれか)をセットし、第2所属コード72と第3所属
コード73には、LRUリストに所属していないことを
示す値“0”をセットする。また、キャッシュ管理テー
ブル20の該当するLRUリストの現エントリ数を
“1”増やす。エントリ・キャッシュ6にエントリ55
aがすでに存在した場合、そのエントリ55aの第1所
属コード71、第2所属コード72、第3所属コード7
3を順に検査し、現在のアクセス要求のスコープの値が
いずれかにセットされていれば、そのスコープのLRU
リストの先頭にエントリ55aを移動させる。一方、現
在のアクセス要求のスコープの値がいずれにもセットさ
れていなければ、現在のアクセス要求のスコープに該当
するLRUリストにそのエントリを加え、第2所属コー
ド72が“0”であればそれを現在のアクセス要求のス
コープの値に変更し、第2所属コード72が“0”でな
ければ第3所属コード73に現在のアクセス要求のスコ
ープの値をセットする。
場合は、現在のアクセス要求のスコープに該当するLR
Uリストを末尾エントリから先頭エントリへ向かって走
査していき、第1所属コード71の値が現在のアクセス
要求のスコープの値と同じであるエントリが見つかれ
ば、そのエントリの第2所属コード72を確認し、その
第2所属コード72の値が“0”でなければ、その第2
所属コード72の値に対応するスコープのLRUリスト
の現エントリ数を確認し、最大数に達していなければ
“1”増やし、現在のアクセス要求のスコープに該当す
るLRUリストの現エントリ数を“1”減らす。第2所
属コード72の値が“0”であるか又は第2所属コード
72の値に対応するスコープのLRUリストの現エント
リ数が最大数に達していれば、第3所属コード73を確
認し、その第3所属コード73の値が“0”でなけれ
ば、第3所属コード73の値に対応するスコープのLR
Uリストの現エントリ数を確認し、最大数に達していな
ければ“1”増やし、現在のアクセス要求のスコープに
該当するLRUリストの現エントリ数を“1”減らす。
第3所属コード73の値が“0”であるか又は第3所属
コード73の値に対応するスコープのLRUリストの現
エントリ数が最大数に達していれば、第1所属コード7
1のスコープの値に該当するLRUリストからエントリ
を削除し、そのLRUリストの現エントリ数を“1”減
らす。
に格納されるエントリ55aは、複数のLRUリストに
所属していても、最初に所属したLRUリストにおいて
のみエントリ数としてカウントされ、重複してカウント
されることはない。これにより、キャッシュ管理テーブ
ル20の各LRUの現エントリ数の総和は、キャッシュ
に格納されている実際のエントリ数と常に等しくなり、
利用されない領域がキャッシュに生じてしまうことを回
避できる。また、運用管理者は、ディレクトリ・サーバ
1に搭載すべきメモリ容量を正確に見積ることが出来
る。
によれば、各LRUリストの現エントリ数が全て最大数
に達していても、キャッシュに格納している実際のエン
トリ数が最大数の総和に達しておらず、利用されない領
域がキャッシュに生じてしまうことがある。これを回避
するため、第三の実施形態では、カウントの重複を見込
んで各LRUリストのエントリ数の最大数を大きめに設
定可能とし且つキャッシュに格納している全体のエント
リ数を管理する。次に、第三の実施形態を、第一の実施
形態との相違点に関して説明する。
リ・キャッシュ6bの構造図である。このエントリ・キ
ャッシュ6bと第一の実施形態におけるエントリ・キャ
ッシュ6(図3)との相違点は、このエントリ・キャッ
シュ6bでは、キャッシュ管理テーブル20bを持つこ
とである。また、全体LRUリスト80を持つことであ
る。
シュ管理テーブル20bの構造図である。このキャッシ
ュ管理テーブル20bと第一の実施形態におけるキャッ
シュ管理テーブル20(図4)との相違点は、このキャ
ッシュ管理テーブル20bが、サーバ起動時に設定され
るキャッシュ全体で格納できるエントリ数を記憶してお
く「全体LRUリストの最大エントリ数」74と、現在
キャッシュに格納しているエントリ数を記憶している
「全体LRUリストの現エントリ数」75と、全体LR
Uリスト80の先頭エントリを指す「全体LRUリスト
の先頭ポインタ」76および全体LRUリスト80の末
尾エントリを指す「全体LRUリストの末尾ポインタ」
77とを持つことである。
リ55bの構造図である。このエントリ55bと第一の
実施形態におけるエントリ55(図6)との相違点は、
このエントリ55bでは、全体LRU nextポインタ7
8と、全体LRUprevポインタ79とが追加されている
ことである。
である。この全体LRUリスト80は、キャッシュに格
納されているすべてのエントリ55bが所属する一本の
LRUリストとなっている。
する場合、アクセス別分割LRUリスト7に格納するの
と同時に全体LRUリスト80にも格納する。その際、
「全体LRUリストの現エントリ数」75の確認を行
い、それが「全体LRUリストの最大エントリ数」74
に達していれば、全体LRUリスト80の末尾エントリ
を削除する。削除する際、そのエントリが所属していた
他のLRUリストからの削除も行い、そのLRUリスト
の現エントリ数を“1”減らす。
に格納している全体のエントリ数を管理するため、カウ
ントの重複を見込んで各LRUリストのエントリ数の最
大数を大きめに設定することが可能であり、これによ
り、利用されない領域がキャッシュに生じてしまうこと
を回避できる。
56に属性名57と属性値58のセットを格納している
が、ここで属性名57は文字列としてキャッシュ領域を
消費しているため、属性名57の文字列が長くなればキ
ャッシュ領域の消費量が大きくなってしまう。これを回
避するため、第四の実施形態では、属性名を番号で管理
する。次に、第四の実施形態を、第一の実施形態との相
違点に関して説明する。
リ・キャッシュ6cの構造図である。このエントリ・キ
ャッシュ6cと第一の実施形態におけるエントリ・キャ
ッシュ6(図3)との相違点は、このエントリ・キャッ
シュ6cが、属性番号テーブル81を持つことである。
である。この属性番号テーブル81は、エントリが持ち
得るすべての属性名82とその通し番号である属性番号
83を対応付けたテーブルとなっている。
リスト56cの構造図である。この属性値リスト56c
と第一の実施形態における属性値リスト56(図6)の
相違点は、第一の実施形態における属性値リスト56で
は文字列の属性名57を格納していたが、この属性値リ
スト56cでは、数値の属性番号84を格納している点
である。
が持ち得るすべての属性を定義したオブジェクトクラス
定義ファイルを起動時に読み込み、それを基に属性番号
テーブル81を作成する。アクセス要求処理を行う際に
は、属性番号テーブル81を参照して必要な属性名82
の属性番号83を得て、図32に示す必要属性番号リス
ト85を作成する。エントリの属性をキャッシュに格納
する際は、属性名でなく、属性番号を格納する。
性名の代りに数値の属性番号を用いるため、属性名の長
さに関わらず、キャッシュのメモリ所要量を小さく抑え
ることが出来る。
ば、次の効果が得られる。 (1)アクセス要求の種類別に分割してLRU管理する
ため、ある1つの種類の検索要求によって大量のエント
リがDBから抽出されても、他の種類のエントリがキャ
ッシュから削除されず、高ヒット率を確保できる。 (2)すべての属性をキャッシュに格納せず、必要な属
性のみをキャッシュに格納するため、アクセス頻度の低
い属性がキャッシュを消費することを防止でき、高いキ
ャッシュ効率を確保できる。
・サーバの機能構成図である。
・サーバのシステム構成図である。
キャッシュの構成図である。
管理テーブルのデータ構造図である。
ブルのデータ構造図である。
図である。
属性リストのデータ構造図である。
るアクセス別LRUリストの構造図である。
るディレクトリアクセス処理を説明するフロー図であ
る。
ける更新系要求処理を説明するフロー図である。
ける検索系要求処理を説明するフロー図である。
けるAdd要求処理を説明するフロー図である。
けるDelete要求処理を説明するフロー図である。
けるModify要求処理を説明するフロー図である。
けるModifyRDN要求処理を説明するフロー図である。
性格納処理を説明するフロー図である。
ュエントリ追加処理を説明するフロー図である。
ュエントリ削除処理を説明するフロー図である。
スト更新処理を説明するフロー図である。
スト追加処理を説明するフロー図である。
スト削除処理を説明するフロー図である。
ある。
ある。
造図である。
ュの構成図である。
ブルのデータ構造図である。
造図である。
説明図である。
ュの構成図である。
データ構造図である。
造図である。
のデータ構造図である。
けるエントリ・キャッシュのサイズ定義時の画面表示の
例示図である
ける属性格納処理に用いるワーク領域の説明図である。
アント、3…通信制御部、4…プロトコル解析部、5…
アクセス別分割LRU管理部、6…エントリキャッシ
ュ、7…アクセス別LRUリスト、8…属性管理部、9
…DB、10…ネットワーク、11…主メモリ、12…
バス、13…ディスプレイ、14…キーボード、15…
マウス、16…CPU、17…磁気ディスク。
Claims (12)
- 【請求項1】 ディレクトリ情報を記憶するデータベー
スを備えたディレクトリ・サーバにおいて、エントリの
キャッシュ格納をアクセス要求の種類別に分割してLR
U管理するアクセス別分割LRU管理手段と、アクセス
要求毎に必要属性のみをキャッシュ格納する属性管理手
段とを有することを特徴とするディレクトリ・サーバ。 - 【請求項2】 ディレクトリ情報を記憶するデータベー
スを備えたディレクトリ・サーバにおいて、エントリの
キャッシュ格納をアクセス要求の種類別に分割してLR
U管理するアクセス別分割LRU管理手段を有すること
を特徴とするディレクトリ・サーバ。 - 【請求項3】 ディレクトリ情報を記憶するデータベー
スを備えたディレクトリ・サーバにおいて、アクセス要
求毎に必要属性のみをキャッシュ格納する属性管理手段
を有することを特徴とするディレクトリ・サーバ。 - 【請求項4】 請求項1または請求項2に記載のディレ
クトリ・サーバにおいて、前記アクセス別分割LRU管
理手段は、データベースから新たに抽出したエントリを
アクセス要求の種類別LRUリストに加えることによっ
てキャッシュ格納を行い、アクセス要求の種類別LRU
リスト毎にカウントしたエントリ数に基づいてアクセス
要求の種類別のLRU管理を行うことを特徴とするディ
レクトリ・サーバ。 - 【請求項5】 請求項4に記載のディレクトリ・サーバ
において、前記アクセス別分割LRU管理手段は、エン
トリを加えようとしたアクセス要求の種類別LRUリス
トのエントリ数が当該アクセス要求の種類別LRUリス
トに設定されている最大数に達していた場合、そのアク
セス要求の種類別LRUリストから最も過去に加えたエ
ントリを削除し、エントリを加えることを特徴とするデ
ィレクトリ・サーバ。 - 【請求項6】 請求項1、請求項2、請求項4または請
求項5に記載のディレクトリ・サーバにおいて、前記ア
クセス別分割LRU管理手段は、アクセス要求が更新系
である場合、アクセス要求の処理に必要なエントリを新
たにデータベースから抽出しても、そのエントリをキャ
ッシュに格納しないことを特徴とするディレクトリ・サ
ーバ。 - 【請求項7】 請求項5に記載のディレクトリ・サーバ
において、現在のアクセス要求の処理に必要なエントリ
がキャッシュに既に格納されており且つ現在のアクセス
要求の種類とは異なるアクセス要求の種類別LRUリス
トに所属している場合、現在のアクセス要求の種類別L
RUリストに当該エントリを加えると共に現在のアクセ
ス要求の種類別LRUリストのエントリ数を“1”増や
さないことを特徴とするディレクトリ・サーバ。 - 【請求項8】 請求項1、請求項2または請求項4から
請求項7のいずれかに記載のディレクトリ・サーバにお
いて、エントリを加えようとしたアクセス要求の種類別
LRUリストのエントリ数が当該アクセス要求の種類別
LRUリストに設定されている最大数に達していなくて
も、キャッシュに格納しているエントリの総数が設定さ
れている最大数に達していた場合、そのアクセス要求の
種類別LRUリストから最も過去に加えたエントリを削
除し、エントリを加えることを特徴とするディレクトリ
・サーバ。 - 【請求項9】 請求項1、請求項2または請求項4から
請求項8のいずれかに記載のディレクトリ・サーバにお
いて、前記アクセス要求の種類別が、検索系アクセス要
求のスコープ別であることを特徴とするディレクトリ・
サーバ。 - 【請求項10】 請求項1または請求項3に記載のディ
レクトリ・サーバにおいて、前記属性管理手段は、必要
な属性の属性名の代りにそれに対応する属性番号をキャ
ッシュに格納することを特徴とするディレクトリ・サー
バ。 - 【請求項11】 請求項1、請求項3または請求項10
に記載のディレクトリ・サーバにおいて、前記属性管理
手段は、キャッシュに全属性が格納されているか否かを
調べ、キャッシュに全属性が格納されていない場合のみ
必要な属性をリストアップし、その必要な属性がキャッ
シュに格納されているか否かを調べ、必要な属性がキャ
ッシュに格納されていない場合のみデータベースにアク
セスすることを特徴とするディレクトリ・サーバ。 - 【請求項12】 請求項1、請求項3、請求項10また
は請求項11に記載のディレクトリ・サーバにおいて、
前記必要な属性は、アクセス要求により抽出を指示され
た属性の外に、ディレクトリ情報のアクセス制御に必要
な属性を含むことを特徴とするディレクトリ・サーバ。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10287396A JP2000035912A (ja) | 1998-05-13 | 1998-10-09 | ディレクトリ・サーバ |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10-130341 | 1998-05-13 | ||
JP13034198 | 1998-05-13 | ||
JP10287396A JP2000035912A (ja) | 1998-05-13 | 1998-10-09 | ディレクトリ・サーバ |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2000035912A true JP2000035912A (ja) | 2000-02-02 |
Family
ID=26465488
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP10287396A Pending JP2000035912A (ja) | 1998-05-13 | 1998-10-09 | ディレクトリ・サーバ |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2000035912A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004524754A (ja) * | 2001-03-19 | 2004-08-12 | インターナショナル・ビジネス・マシーンズ・コーポレーション | キャッシュ入力の選択方法および装置 |
KR100901622B1 (ko) * | 2002-12-13 | 2009-06-08 | 주식회사 케이티 | 디렉토리 트래픽 부하 감소를 위해 로컬 캐슁 기법을이용한 사용자 정보 검색 방법 |
JP2012226442A (ja) * | 2011-04-15 | 2012-11-15 | Nec Corp | 情報処理装置、検索情報作成方法、および検索情報作成プログラム |
KR101295210B1 (ko) | 2012-04-27 | 2013-08-12 | 엔에이치엔비즈니스플랫폼 주식회사 | 데이터베이스 관리 방법 및 장치 |
JP7452366B2 (ja) | 2020-10-06 | 2024-03-19 | 富士通株式会社 | アクセス制御装置、アクセス制御方法及びアクセス制御プログラム |
-
1998
- 1998-10-09 JP JP10287396A patent/JP2000035912A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004524754A (ja) * | 2001-03-19 | 2004-08-12 | インターナショナル・ビジネス・マシーンズ・コーポレーション | キャッシュ入力の選択方法および装置 |
US7146478B2 (en) | 2001-03-19 | 2006-12-05 | International Business Machines Corporation | Cache entry selection method and apparatus |
KR100901622B1 (ko) * | 2002-12-13 | 2009-06-08 | 주식회사 케이티 | 디렉토리 트래픽 부하 감소를 위해 로컬 캐슁 기법을이용한 사용자 정보 검색 방법 |
JP2012226442A (ja) * | 2011-04-15 | 2012-11-15 | Nec Corp | 情報処理装置、検索情報作成方法、および検索情報作成プログラム |
KR101295210B1 (ko) | 2012-04-27 | 2013-08-12 | 엔에이치엔비즈니스플랫폼 주식회사 | 데이터베이스 관리 방법 및 장치 |
JP7452366B2 (ja) | 2020-10-06 | 2024-03-19 | 富士通株式会社 | アクセス制御装置、アクセス制御方法及びアクセス制御プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11388251B2 (en) | Providing access to managed content | |
US8700573B2 (en) | File storage service system, file management device, file management method, ID denotative NAS server and file reading method | |
US7606793B2 (en) | System and method for scoping searches using index keys | |
US20080040192A1 (en) | System and Method for Scheduled Events to Subscribe to Live Information Topics | |
US6363375B1 (en) | Classification tree based information retrieval scheme | |
US9703885B2 (en) | Systems and methods for managing content variations in content delivery cache | |
JP4559158B2 (ja) | データにアクセスするための方法及びシステム | |
US7103589B1 (en) | Method and system for searching, accessing and updating databases | |
JP4040849B2 (ja) | 知識蓄積支援システムおよび同システムにおけるメッセージ移動方法 | |
JP5106045B2 (ja) | 検索エンジン連携ファイル共有システム | |
US6952730B1 (en) | System and method for efficient filtering of data set addresses in a web crawler | |
US6473756B1 (en) | Method for selecting among equivalent files on a global computer network | |
US7036149B2 (en) | Computer system | |
CN103685590B (zh) | 获取ip地址的方法及*** | |
JP5628799B2 (ja) | 個人情報ファイル管理ツール | |
US7533157B2 (en) | Method for delegation of administrative operations in user enrollment tasks | |
US11151081B1 (en) | Data tiering service with cold tier indexing | |
US20120117105A1 (en) | Collaborative Database Operations | |
JP2000035912A (ja) | ディレクトリ・サーバ | |
JPH06266600A (ja) | 分散ファイルシステム | |
JP2002157158A (ja) | データベースシステムにおけるデータ管理方法 | |
JPH08185348A (ja) | 情報処理装置および情報処理方法 | |
US8352520B2 (en) | Configurable offline data store | |
JP2006003996A (ja) | 利用履歴管理装置、利用履歴管理方法および利用履歴管理プログラム | |
JPH0744447A (ja) | ハイパーテキストシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Effective date: 20040712 Free format text: JAPANESE INTERMEDIATE CODE: A971007 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050222 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050422 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050913 |
|
A521 | Written amendment |
Effective date: 20051025 Free format text: JAPANESE INTERMEDIATE CODE: A523 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060207 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060301 |
|
R150 | Certificate of patent (=grant) or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090310 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100310 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 4 Free format text: PAYMENT UNTIL: 20100310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 4 Free format text: PAYMENT UNTIL: 20100310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 5 Free format text: PAYMENT UNTIL: 20110310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110310 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 6 Free format text: PAYMENT UNTIL: 20120310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 6 Free format text: PAYMENT UNTIL: 20120310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 6 Free format text: PAYMENT UNTIL: 20120310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 7 Free format text: PAYMENT UNTIL: 20130310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130310 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Year of fee payment: 7 Free format text: PAYMENT UNTIL: 20130310 |
|
FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140310 Year of fee payment: 8 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |