(57)【特許請求の範囲】
【請求項１】
要求に応答するための装置であって、前記要求は、分散型データベース・システムにある多数のオブジェクトに属するオブジェクトを参照する1つまたは複数の指定を含み、当該オブジェクトは、当該指定を用いて問合せ可能であり、当該分散型データベース・システムは、多数のデータベース・システムを含み、当該多数のデータベース・システムは、第1のデータベース・システムおよび第2のデータベース・システムを含み、前記装置は、
前記第1のデータベース・システムと、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する問合せアナライザと、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むと前記問合せアナライザが判断した場合、前記第2のデータベース・システムの少なくとも一部で要求が実行されることにより要求に応答する転送装置とを含み、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含んでいないと前記問合せアナライザが判断した場合、前記要求は、前記第1のデータベース・システムで実行され、
前記要求に対する応答として、前記第1のデータベース・システムにおける実行の結果、および／または、前記第2のデータベース・システムにおける実行の結果を提供するための手段をさらに含む、装置。
【請求項２】
前記第1のデータベース・システムにおけるオブジェクトが、前記分散型データベース・システムに属する少なくとも1つの他のデータベース・システムに含まれるオブジェクトのコピーを含む、請求項1記載の装置。
【請求項３】
そのコピーが前記第1のデータベース・システムに含まれるオブジェクトに関して、前記第1のデータベース・システムがキャッシュとして機能する、請求項2記載の装置。
【請求項４】
他のデータベース・システムが、前記第2のデータベース・システムである、請求項2記載の装置。
【請求項５】
第1のデータベース・システムが、前記第2のデータベース・システムに関してキャッシュとして機能する、請求項4記載の装置。
【請求項６】
データベースの問合せを行う標準インタフェースを用いてサーバ上で実行するプログラムを提供する種類のサーバに対してローカルである装置であって；
前記要求が、前記標準インタフェースを介して受信した問合せを含む、
請求項1〜5のいずれか一項記載の装置。
【請求項７】
サーバがハイパーテキストトランスファープロトコル（http）に従い、プログラムがウェブアプリケーションプログラムである、請求項6記載の装置。
【請求項８】
要求に応答する方法であって、前記要求は、分散型データベース・システムにある多数のオブジェクトに属するオブジェクトを参照する1つまたは複数の指定を含み、当該オブジェクトは、当該指定を用いて問合せ可能であり、当該分散型データベース・システムは、多数のデータベース・システムを含み、当該多数のデータベース・システムは、第1のデータベース・システムおよび第2のデータベース・システムを含み、前記方法は、
前記第1のデータベース・システムにおいて要求を受信する段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含む場合、前記第2のデータベース・システムの少なくとも一部で前記要求が実行される段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含んでいない場合、前記第1のデータベース・システムで前記要求が実行される段階と、
前記第1のデータベース・システムにおいて、前記第1のデータベース・システムにおける実行の結果、および／または、前記第2のデータベース・システムにおける実行の結果を応答する段階とを含む、方法。
【請求項９】
前記第1のデータベース・システムにおけるオブジェクトが、前記分散型データベース・システムに属する少なくとも1つの他のデータベース・システムに含まれるオブジェクトのコピーを含み、それにより、第1のデータベース・システムが、そのコピーが第1のデータベース・システムに含まれるオブジェクトに関してキャッシュとして機能する、請求項8記載の方法。
【請求項１０】
前記他のデータベース・システムが前記第2のデータベース・システムであり、それにより、前記第1のデータベース・システムが、前記第2のデータベース・システムに関してキャッシュとして機能する、請求項9記載の方法。
【請求項１１】
前記第1のデータベース・システムが、データベースの問合せを行うための標準インタフェースを用いてサーバ上で実行するプログラムを提供する種類のサーバに対してローカルであり；
要求を受信する前記段階において、前記要求が、前記標準インタフェースを介して受信される、請求項8〜10のいずれか一項記載の方法。
【請求項１２】
サーバがハイパーテキストトランスファープロトコル（http）に従い、プログラムがウェブアプリケーションプログラムである、請求項11記載の方法。
【請求項１３】
プロセッサにおいて実行される場合に、要求に応答する方法を実行するコードを含むことを特徴とするメモリ装置であって、前記要求は、分散型データベース・システムにある多数のオブジェクトに属するオブジェクトを参照する1つまたは複数の指定を含み、当該オブジェクトは、当該指定を用いて問合せ可能であり、当該分散型データベース・システムは、多数のデータベース・システムを含み、当該多数のデータベース・システムが第1のデータベース・システムおよび第2のデータベース・システムを含み、前記方法は、
前記第1のデータベース・システムにおいて前記要求を受信する段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含む場合、前記第2のデータベース・システムの少なくとも一部で要求が実行される段階と、
前記要求が、前記第1のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含んでいない場合、前記第1のデータベース・システムで前記要求が実行される段階と、
前記第1のデータベース・システムにおいて、前記第1のデータベース・システムにおける実行の結果、および／または、前記第2のデータベース・システムにおける実行の結果を応答する段階とを含む、メモリ装置。
【請求項１４】
要求に応答してオブジェクトを返す第1のデータベース・システムに属するオブジェクトのサブセットに属するオブジェクトのコピーをキャッシュ化するための装置であって、その結果前記要求が、オブジェクトを参照する1つまたは複数の指定を含み、当該オブジェクトは、当該指定を用いて問合せ可能であり、前記装置は、
前記コピーを含む第2のデータベース・システムと、
前記要求が第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する問合せアナライザと、
前記要求が、前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むと問合せアナライザが判断した場合、前記第1のデータベース・システムの少なくとも一部で要求が実行されることにより要求に応答する転送装置とを含み、
前記要求が前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含んでいないと前記問合せアナライザが判断した場合、前記要求は前記第2のデータベース・システムで実行される、装置。
【請求項１５】
データベースの問合せを行う標準インタフェースを用いてサーバ上で実行するプログラムを提供する種類のサーバに対してローカルである装置であって；
前記要求が、前記標準インタフェースを介して受信した問合せを含む、請求項14記載の装置。
【請求項１６】
サーバがハイパーテキストトランスファープロトコル（http）に従い、プログラムがウェブアプリケーションプログラムである、請求項15記載の装置。
【請求項１７】
オブジェクトのセットに属する1つまたは複数のオブジェクトを参照する1つまたは複数の指定を含む要求に応答する方法であって、前記オブジェクトが第1のデータベース・システムに記憶され、前記オブジェクトのセットのサブセットのコピーが第2のデータベース・システムに記憶され、当該オブジェクトは、当該指定を用いて問合せ可能であり、前記方法は、
前記第2のデータベース・システムにおいて前記要求を受信する段階と、
前記要求が前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する段階と、
前記要求が、前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含む場合、前記第2のデータベース・システムの代わりに、前記第1のデータベース・システムにおける少なくとも一部で要求を実行させる段階とを含む、方法。
【請求項１８】
第2のデータベース・システムが、データベースの問合せを行うための標準インタフェースを用いてサーバ上で実行するプログラムを提供する種類のサーバに対してローカルであり；
要求を受信する段階において、前記要求が、前記標準インタフェースを介して受信される、
請求項17記載の方法。
【請求項１９】
サーバがハイパーテキストトランスファープロトコル（http）に従い、プログラムがウェブアプリケーションプログラムである、請求項18記載の方法。
【請求項２０】
プロセッサにおいて実行される場合に、要求に応答する方法を実行するコードを含むことを特徴とするメモリ装置であって、前記要求がオブジェクトのセットに属するオブジェクトを参照する1つまたは複数の指定を含み、前記オブジェクトが第1のデータベース・システムに記憶され、前記オブジェクトのセットのサブセットのコピーが第2のデータベース・システムに記憶され、当該オブジェクトは、当該指定を用いて問合せ可能であり、前記方法は、
前記第2のデータベース・システムにおいて前記要求を受信する段階と、
前記要求が前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含むかどうかを判断する段階と、
前記要求が、前記第2のデータベース・システムにおいて、その指定を用いることでは問合せ可能ではないオブジェクトに対する指定を含む場合、前記第2のデータベース・システムの代わりに、前記第1のデータベース・システムにおける少なくとも一部で要求が実行される段階とを含む、メモリ装置。
【発明の詳細な説明】
【０００１】
発明の背景
１．発明の分野
本発明は、全般的にはネットワークにおけるデータのキャッシングに関し、具体的には、ネットワーク・サーバにおける問合せ可能なデータのキャッシングに関する。
【０００２】
2．先行技術の説明
コンピュータが通信網に結合された後、データに対するリモート・アクセスはそれ以前よりもずっと安価にかつ容易になった。しかし、リモート・アクセス用の利用可能なユーザ・インタフェースがわかりづらく、かつ使いにくいものであったので、リモート・アクセスは依然として専門家を対象としたものであった。インターネット上でWWWプロトコルが使用されるようになって、やっとデータに対するリモート・アクセスをあらゆる人が利用できるようになった。現在では、高校生が自宅で、ドイツのKarlsruheに関する情報をその都市のウェブサイトから得ることができ、法律家が自分の事務所で、コンピュータ製造業者のウェブサイトを使用して、新たに導入するPCに必要な機能を決定し、次いでそのPCを環境設定し、注文し、代金を支払うことができる。
【０００３】
新たにリモート・アクセスが容易になり、情報サービスおよび商取引に対して新たな可能性が与えられたため、リモート・アクセスの量は大幅に増加している。このため、リモート・アクセスを提供するサービスに多大な新しい負担がかかり、その結果起こる性能面の問題を１つの理由として、WWWはワールド・ワイド・ウェイト（世界的な待ち状態）になってしまった。
【０００４】
図1は、この性能問題の１つの原因を示している。PCを使用しているユーザがWWWを介して情報源にアクセスできるようにするシステムの構成要素が101に示されている。ウェブブラウザ103は、ウェブブラウザ・ソフトウェアを実行しているPCである。ウェブブラウザ・ソフトウェアは、WWWにおけるHTMLフォーマットの情報のページの位置を指定するURL 104を出力し、HTMLページをユーザに表示する。URLには、HTMLページを得るプロセスの一部としてURLのサイトで処理すべきデータを含むメッセージを関連付けることができる。たとえば、この情報がデータベースに含まれている場合、メッセージはデータベースに対する問合せを指定することができる。次いで、問合せの結果がHTMLページの一部として返される。インターネット105は、URL 104およびそれに関連するメッセージを、URL、すなわちウェブサーバ107によって指定された位置にルーティングする。次いで、ウェブサーバ107内のHTMLプログラム109が、URLによって指定されたHTMLページ106を作成し、ウェブブラウザ103に返す。メッセージにおいてデータベース・サーバ115内のデータベースに対する問合せが指定されている場合、HTMLプログラム109はこのメッセージをウェブアプリケーション・プログラム111に渡し、ウェブアプリケーション・プログラム111がメッセージをデータ・アクセス層112によって必要とされる形式の問合せに変換する。
【０００５】
データ・アクセス層112は一般に、データベース・サーバ115の製造業者によって設けられる。データ・アクセス層112は、OLE-DB、ODBC、またはJOBCなどの標準形式で書かれた問合せを取り出し、データベースによって必要とされる形式に変換し、ネットワーク113によって必要とされる形式でメッセージ内に配置する。次いで、データベース115が問合せを実行し、結果をネットワーク113を介してデータ・アクセス層112に返す。データ・アクセス層112は、結果を必要な標準形式に変換してウェブアプリケーション111に返し、ウェブアプリケーション111はこの結果をHTMLプログラム109用の適切なフォーマットに変換する。次いで、HTMLプログラム109は、ブラウザ103に返すべきHTMLページ106を作成する際にこの結果を使用する。
【０００６】
上記の説明からわかるように、データベース・サーバ115が作成に関与するページを指定するURLへの応答には、インターネット105でのブラウザ103からウェブブラウザ107へのホップ、ネットワーク113上でのサーバ107からサーバ115へのホップ、ネットワーク113でのサーバ115からサーバ107へのホップ、インターネット105上でのサーバ107からブラウザ103へのホップの4回のネットワーク・ホップは必要である。HTMLページに複数の問合せが必要である場合、各問合せごとにネットワーク113上で往復が行われる。
【０００７】
さらに、117に示すように、典型的なウェブトランザクションは一連のこのような応答であり、第1のHTMLページは次のHTMLページのURLを含み、以下同様である。117に示すトランザクションは、ユーザが問合せを行う際に記入する形式であるHTMLページを求める要求から開始し、データベース・サーバ115がHTMLページに関する情報を与える。このページが返されると、ユーザは、この形式で記入し、それが終了すると、ブラウザがURLをこの形式からの問合せと共にサーバ107に返す。次いで、サーバ107は、上述のように問合せに対処し、他のHTMLページにおいて結果を返す。このページによって、ユーザは命令を下すことができ、ユーザが命令を下すと、その結果として、データベース・サーバ115に対する別の問合せ、すなわち、トランザクションに関与するレコードを更新する問合せが行われる。
【０００８】
図1に示すように行われるウェブトランザクションは、多数のネットワーク・ホップを伴うだけでなく、データベース・サーバ115に多大な負担をかける。たとえば、データベース・サーバ115がウェブ上で商品を販売する人によって所有されており、この人が特価品を販売している場合、多数のトランザクションがHTMLページのまったく同じシーケンスを必要とし、まったく同じ問合せを実行するが、システム101はウェブブラウザからの要求に個別に対処するので、各問合せをデータベース・サーバ115によって個別に実行しなければならない。
【０００９】
システム101の問題は、コンピュータ・システムの設計者にとっては新しい問題ではない。コンピュータ・システムには、システムのある構成要素が所与のソースからデータへのより高速なアクセスを必要とする多数の状況があり、これらの状況が起こる際は、構成要素によって頻繁に使用されるデータのコピーが、構成要素がデータ供給源にアクセスする場合よりも高速にアクセスできるシステム内の位置に維持される場合に、システムの性能を向上させることができる。このようなコピーが存在する場合、コピーが維持される位置をキャッシュと呼び、データはシステムにキャッシュされると言われる。
【００１０】
キャッシングはシステム101内で多数のレベルで使用される。たとえば、ブラウザ103は、すでに表示されているHTMLページのキャッシュを維持し、したがって、インターネット105を介してページを要求することなしに、すでに表示されているHTMLページをユーザに与えることができる。ウェブサーバ107も同様に、頻繁に要求されるHTMLページのキャッシュを維持し、したがって、ページを作成するのではなく単にユーザに返すことができる。最後に、データベース・サーバ115は、頻繁に行われる問合せに回答する必要のある情報のキャッシュを維持し、したがって、最初からやり直す場合よりも高速に結果を返すことができる。システム101では、キャッシングが最も有効に使用されるのはウェブサーバ107である。これは、依然としてインターネット105のすべてのユーザが、ウェブサーバ107にキャッシュされるデータにアクセスすることができ、それに対して、データ・アクセス113に対するホップのオーバヘッドが回避されるからである。
【００１１】
キャッシュを含むあらゆるシステムは、キャッシュ内のデータ間の整合性を維持すること、およびキャッシュすべきデータを選択することの2つの問題に対処しなければならない。システム101において、第1の問題は、最も簡単な方法で解決され、すなわち、いつデータ供給源からのデータの新しいコピーが必要になるかを判定することは、データを使用する構成要素の責任である。したがって、ブラウザ103では、ユーザがブラウザの「リロード」ボタンを特にクリックしないかぎり、すでに表示されているHTMLページのキャッシュ済みコピーが表示される。同様に、キャッシュ済みのHTMLページに維持されている結果をもたらした問合せをいつ再実行する必要があるかを判定することはHTMLプログラム109の責任である。第2の問題も簡単に解決される。すなわち、新しいページが表示される場合、このページが、最初に使用されたキャッシュ済みのページに置き換わる。
【００１２】
Oracle Corporationによって製造されており、レバーレンズ（Leverenz）ら著「Oracle8 Server Concepts」リリース8.0（Oracle Corporation、カリフォルニア州レッドウッドシチー、1998年）に記載されているOracle8（登録商標）サーバなどのデータベース・システムは、最初のデータベースをユーザに最も近い位置に複製することによって、データベースのコピーをユーザのより近くに移動させる。複製されたデータベースは、オリジナル全体またはその一部のみをコピーすることができる。データベースの部分的な複製をテーブル・スナップショットと呼ぶ。このようなテーブル・スナップショットは読取り専用である。部分的なコピーのユーザは、テーブル・スナップショット内に最初のデータベースのどの部分が含まれているかを判定する。最初のデータベースとの整合性は、テーブル・スナップショットのユーザによって決定された時間に行われるスナップショット・リフレッシュによって維持される。スナップショット・リフレッシュでは、テーブル・スナップショットが、最初のデータベースの、スナップショットに含まれる部分の最新の状態を反映するように更新される。詳細は、レバーーレンズの文献の30-5ページから30-11ページを参照されたい。
【００１３】
キャッシングを行っている構成要素に、いつ新しいページが必要になるかを判定させる解決策によって問題を起こる多数の応用例がある。たとえば、データ供給源内の情報が重要であるか、または高速に変化している（たとえば、株価）場合、ユーザへの良好なサービスでは、キャッシュ内の情報がデータ供給源内の情報を厳密に追跡する必要がある。同様に、要求されたすべてのデータが問題を生じさせる多数の状況がある。たとえば、LRU原則に従って動作するキャッシュでは、HTMLプログラム109によって作成されるか、またはブラウザ103で受信されたあらゆるHTMLページがキャッシュされ、キャッシュ後にキャッシュ内に留まり、LRUステータスを実現するまで他のHTMLページに使用することのできる空き容量を占有する。
【００１４】
ウェブサーバ107が、データベース・サーバ115に関与するウェブアプリケーション111を含む場合、ウェブサーバ107内のキャッシングに関する別の問題がさらに起こる。すなわち、データは、HTMLページの形式でキャッシュされるので、問合せ可能な形式ではなく、すなわち、キャッシングされたHTMLページは、ウェブブラウザ103から受信された他の問合せに回答することのできるデータを含むことができるが、このデータはデータベース・テーブルではなくHTMLページに含まれるので、問合せを適用できる形式ではない。したがって、データがサーバ107内にあるにもかかわらず、サーバ107は問合せを行わなければならず、データベース・サーバ115に負担がかかり、ネットワーク113で遅延が起こり、問合せの結果を含むHTMLページをサーバ107に独立にキャッシュしなければならない。
【００１５】
これらの問題を解決するためには、キャッシングされたデータができるかぎり問合せ可能な形式であり、キャッシングされたデータが、データ供給源のデータが変更された場合にそれに応じて更新され、キャッシングすべきデータのデータ供給源からの選択が、ウェブブラウザから受信されたURLがこのデータを参照したこと以外のことに基づいて行われるキャッシュを有するウェブサーバ107が必要である。本明細書で開示される本発明の目的は、上記の問題を解決するサーバおよびデータ供給源を提供することである。
【００１６】
発明の概要
サーバのキャッシュを更新する問題は、キャッシングされた情報の供給源に、キャッシングされた情報が情報供給源内で変更されるたびにサーバに更新メッセージを送信させることによって解決される。何をキャッシングすべきかを判定する問題は、情報に対する確率の高い将来の要求に基づいて何をキャッシングすべきかを判定することによって解決される。どの情報がおそらく将来の要求の主題になるかの判定は、サーバでも、データ供給源でも、またはその他の場所でも下すことができる。
【００１７】
問合せ可能なデータの問題は、サーバ内のデータベース・システムをキャッシュとして使用することによって解決される。問合せを実行するのに必要な情報がキャッシュ・データベース・システムに存在する場合、問合せはキャッシュ・データベース・システム上で実行され、そうでない場合はデータ供給源のデータベース・システム上で実行される。キャッシュ・データベース・システムは、問合せをソース・データベース・システム上でも、またはキャッシュ・データベース・システム上でも実行できるようにデータ・アクセス層をセットアップすることによって、サーバ上で実行されるアプリケーション・プログラムに対して透過的にされる。データ・アクセス層は、アプリケーション・プログラムから標準形式の問合せを受信し、次いで、問合せに必要な情報がキャッシュ・データベース内に存在するかどうかを判定する。存在する場合、データ・アクセス層はキャッシュ・データベース上で問合せを実行し、存在しない場合は、ソース・データベース・システム上で実行する。
【００１８】
本発明の他の局面では、問合せの標準形式はグローバル・データセット識別子を使用し、それに対して、キャッシュ・データベース内のデータベースのコピーはローカル・データセット識別子を使用する。キャッシュ・データベース内の問合せアナライザは、問合せで使用されるグローバル・データベース識別子をデータ・アクセス層から受信し、キャッシュ内にコピーが存在する場合、そのことをデータ・アクセス層に示し、そのコピーのローカル・データセット識別子をデータ・アクセス層に返す。次いで、データ・アクセス層は、ローカル・データセット識別子を使用してキャッシュ・データベースに問い合わせる。
【００１９】
当業者には、以下の詳細な説明および図面を検討した場合に他の目的および利点が明らかになると思われる。
【００２０】
詳細な説明
以下の詳細な説明では、まず本発明の概念を概略的に述べ、次いで本発明の現在好ましい形態について説明する。
【００２１】
発明の概要：図2
図2は、１つまたは複数のネットワーク・サーバ203(0..n）を含むネットワークを介して情報を検索するシステム201を示している。各サーバ203(i)は、キャッシュ223にキャッシングされている情報がソース・データベース241内で変更された場合に自動的に更新され、キャッシュ223の内容が、サーバ203(i)のユーザによって近い将来に行われる確率が最も高い問合せは何かを分析することによって決定される問合せ可能なキャッシュ219を含む。サーバ203は、ウェブサーバ107であり、したがって、HTML構成要素109、ウェブアプリケーション構成要素111、データ・アクセス構成要素112の、問合せ可能なキャッシュ219と協働するように修正されたバージョンであるデータ・アクセス構成要素253を有する。しかし、サーバ203は、あらゆる他の種類のネットワーク・プロトコルによってサーバのユーザと通信することができる。サーバ203は、この目的を満たす任意のプロトコルを使用できるネットワーク213によってソース・データベース・サーバ237とさらに通信する。
【００２２】
図2は、１つのサーバ203、すなわちサーバ203(i)を詳しく示している。前述のように、ウェブアプリケーション111は、データ・アクセス層253に対する標準形式の問合せを提供する。しかし、この場合、データ・アクセス層253は、ネットワーク113を介してソース・データベース・サーバ237にアクセスできるだけでなく、問合せ可能なキャッシュ219にもアクセスすることができる。問合せ可能なキャッシュ219は、ソース・データベース241内のデータの一部のコピー223を有するキャッシュ・データベース236を含む。データ・アクセス層253は、ウェブアプリケーション111から問合せを受信すると、Q215に示すように、問合せ可能なキャッシュ219にその問合せを提示する。キャッシングされているデータ223が、問合せに指定されているデータを含む場合、問合せ可能なキャッシュ219は結果（R）217を返し、データ・アクセス層253がこの結果をウェブアプリケーション111に返す。キャッシングされているデータ223が、問合せに指定されているデータを含まない場合、問合せ可能なキャッシュ219はデータ・アクセス層253にミス信号（M）216を返す。次いで、データ・アクセス層253は、ネットワーク113を介してソース・データベース・サーバ237に問合せを行い、結果を受信すると、その結果をウェブアプリケーション111に返す。ミス信号に応答して行われた問合せは、ミス問合せ（MQ）224として現われ、応答はミス応答（MR）226として現われる。
【００２３】
本明細書で、問合せ可能なキャッシュ219との相互作用とソース・データベース・サーバ237との相互作用とは共にデータ・アクセス層253によって実行されるので、問合せ可能なキャッシュ219の存在がウェブアプリケーション111に対して完全に透過的であることに留意されたい。すなわち、ウェブサーバ107上で実行されるウェブアプリケーションプログラム111は、ウェブサーバ203(i)を変更せずに実行される。
【００２４】
問合せ可能なキャッシュ219についてさらに詳しく説明すると、問合せ可能なキャッシュ219にキャッシングされているデータは、あらゆるデータベースと同様に、データ、この場合は、問合せ可能なキャッシュ219にキャッシングされているソース・データベース241から得たデータセット（データベース・テーブル）のコピーを含むキャッシュ・データベース236と、キャッシングされているデータ223内のデータセットに対し問合せを実行する問合せエンジン（QE221）に含まれている。問合せ可能なキャッシュ219の、データ・アクセス層253から問合せを受信する部分は、データ・アクセス・インタフェース212である。データ・アクセス・インタフェース212は以下の2つの機能を有する：
・問合せ215を実行するのに必要なキャッシングされているデータ223に対して問合せを実行できるかどうかを判定し、実行できないと判定した場合はミス信号216を生成する。
・キャッシングされているデータ223がこのデータを含む場合、問合せ215をキャッシュ・データベース236に対して適切な形式に変換する。
【００２５】
データ・アクセス・インタフェース212は、問合せを分析して問合せのコンテキストを判定し、すなわち、問合せを実行するにはどのデータセットが必要であるかを判定し、次いでキャッシングされているデータ223の記述を調べ、キャッシングされているデータ223にこれらのデータセットが存在するかどうかを判定することによって問合せを実行できるかどうかを判定する。データセットは、データセット識別子によって問合せ内に指定され、したがって、コンテキストは、実際には必要なデータセット用の識別子のリストである。記述223は当然、キャッシングされているデータセット用のデータセット識別子を含む。必要なデータセットが存在する場合、データ・アクセス・インタフェース212は、キャッシュ・データベース236内のデータにアクセスするのに必要な形式を有するキャッシュ問合せ245を行う。キャッシュ・データベース236はキャッシュ結果247を返し、データ・アクセス・インタフェース212がキャッシュ結果247を結果217に必要な形式に変換する。
【００２６】
キャッシングされているデータ223がキャッシュ・データベース236に含まれているので、キャッシングされているデータ223は問合せ可能であり、すなわち、キャッシングされているデータ223内にデータセットが含まれている場合、問合せ可能なキャッシュ219は結果としてこのデータセット全体だけでなく、問合せによって記述できるこのデータセットの任意のサブセットを返すことができる。たとえば、キャッシングされているデータ223が、ウェブ商取引に関与している会社によって販売されているすべての種類のシャツをリストしたデータセットを含み、シャツの種類のリストが、各種類のシャツにおいて存在する色を含む場合、問合せ可能なキャッシュ219は、赤色が存在する種類のシャツのリストを結果とする問合せを処理することができる。
【００２７】
キャッシングされているデータ223は、ソース・データベース・サーバ237内の更新トランスミッタ243および問合せ可能なキャッシュ219内の更新レシーバ210によってソース・データベース241との整合性を維持される。ソース・データベース241内の、キャッシングされているデータ223内にコピーが存在する可能性があるデータセットが変更された場合には必ず、更新トランスミッタ243が、その変更を指定するキャッシュ更新問合せ（CUDQ）234を生成し、ネットワーク113を介して各サーバ203(0..n）にCUDQ234を送信する。更新レシーバ210は、ネットワーク113からCUDQ234を受信し、DA 212によって維持されているデータセット記述から、データセットが実際に、キャッシングされているデータ223内にあるかどうかを判定する。キャッシングされているデータ223内にある場合、更新レシーバ210は、キャッシュ更新問合せをキャッシュ・データベース236用の適切な形式251に変換してキャッシュ・リフレッシャ249に与え、次いで、キャッシュ・リフレッシャ249は、キャッシュ・データベース236に対して更新問合せ251を実行する。
【００２８】
データセット・マネージャ（DSM）213は一般に、ソース・データベース・サーバ237のデータセットのどのコピーをキャッシュ・データベース236に含めるべきかを判定する。DSM 213がこの判定を下すために使用する情報は問合せ情報208内に含まれる。問合せ情報208は、サーバ203(i)が使用することができ、ソース・データベース241のどのデータセットが近い将来最も問い合わされる確率が高いかを予想するために使用できる任意の情報でよい。たとえば、ウェブ商取引に関与している会社が、ソース・データベース241内にデータセットがあるある品目の１日セールを行っている場合、問合せ情報208は、この品目用のデータセットおよび１日セールの時間を示すことができる。DSM 213は、この情報を使用して、データセットをソース・データベース241から得て、販売を開始する前にキャッシュ・データベース236にキャッシングし、販売が終了した後でキャッシュ・データベース236から取り出すことができる。
【００２９】
他の種類の問合せ情報208は問合せログ、すなわち、データ・アクセス層253から受信された問合せのタイム・スタンプ付きログである。ログが、所与のデータセットに対する問合せの発生が激増していることを示している場合、DSM 213は、この問合せに関するデータセットがまだキャッシュ内にない場合にはこのデータセットをキャッシングすべきである。逆に、ログがこれらの問合せの発生が激減していることを示している場合、DSM 213は、問合せ可能なキャッシュ219からこれらのデータセットを削除することを検討すべきである。DSM 213は、問合せ可能なキャッシュ219にデータセットを追加すべきであると判定した場合には、新規データ問合せ（NDQ）をネットワーク113を介してソース・データベース241に送信し新しいデータを得て、DSM 213が応答（NDR 220）しない場合には、新しいデータ用の空間を設けるためにキャッシングされているデータ223において削除すべきデータを示す削除問合せを問合せエンジン221に送信し、キャッシュ更新問合せ251をキャッシュ・リフレッシャ249に送信してキャッシュを更新する。
【００３０】
データセット・マネージャ213および問合せ情報208は、ソース・データベース・サーバ237、または将来の問合せの確率に関する情報を得ることのできる任意の場所で部分的に実現することもできる。ソース・データベース・サーバ237で実現する場合には、問合せログが、ソース・データベース241への各問合せ231をログし、およびデータセット・マネージャ213の少なくとも、問合せログを読み取りどの新しいデータをキャッシングする必要があるかを判定する部分が、ソース・データベース237内に存在する。この部分は、新しいデータをキャッシングする必要があると判定すると、更新問合せをこの新しいデータと共に各サーバ203に送信する。何を削除すべきかを判定するDSM 213の構成要素をソース・データベース237に含めることもでき、その場合、すべての問合せ可能なキャッシュ219は、キャッシングされているデータ223内に同じデータを有する。または、この構成要素が各サーバ203(i)に存在し、どのデータを削除すべきかに関する判定を下し、サーバ203(i)内の現在の状況に基づいて新しいデータに対応することができる。このような構成では、ソース・データベース241内のグローバル問合せログだけでなく各サーバ203内にローカル問合せログが存在することができる。このような構成によって、それぞれのサーバ203はそれぞれの異なるサイズのキャッシュ223を有することができる。また、それぞれのサーバ203は、キャッシュ219からどのデータを削除すべきかを判定する際に、これらのサーバが受信している問合せのローカル変動を考慮に入れることもできる。このような変動が起こるのは、たとえば、様々なサーバ203がそれぞれの異なる地理的位置のユーザからの問合せを優先順位に従って受信するようにシステム201がセットアップされている場合である。
【００３１】
図2は、単一のソース・データベース・サーバ237のみを示している。当然、複数のソース・データベース・サーバ237があってよい。さらに、ソース・データベース・サーバ237は従来型のデータベース・システムである必要はない。サーバ203(i)は、任意の種類の問合せ可能なデータを含むデータ供給源と共に使用されるようにセットアップすることができる。この場合、「問合せ可能な」は、1組の番号付きデータ行として表すことのできる形式を有することして定義される。このような1組の番号付き行を行セットと呼ぶ。データベース・テーブルは当然、行セットの一例であり、他の行セットとしてデータ・レコードのファイル、テキスト・ファイル、静止画像データおよび動画データがある。1種類の問合せ可能なデータのみを有するデータ供給源と共にサーバ203(i)を使用する場合、問合せ可能なキャッシュ219は、この種類の問合せ可能なデータに対処するようにセットアップするだけでよい。
【００３２】
複数種類の問合せ可能なデータを有するデータ供給源と共にサーバ203(i)を使用する場合、キャッシュ・データベース236は、すべての異なる種類の問合せ可能なデータに対応する行セット表現を使用してセットアップすることができる。この場合、DA 212、DSM 213、および更新レシーバ210は、様々なデータ供給源から受信された結果および更新問合せと、キャッシングされているデータ236で使用される表現との間の変換を行う。他の態様では、問合せ可能なキャッシュ219内に複数のキャッシュ・データベース236があってよく、それぞれのキャッシュ・データベースをそれぞれの異なる種類の問合せ可能なデータに使用することができる。この場合も、DA 212、DSM 213、および更新レシーバ210は必要な変換を実行する。
【００３３】
データ・アクセス層および問合せ可能なキャッシュの好ましい態様の詳細：図3、図5、および図6
図3は、データ・アクセス層349および問合せ可能なキャッシュ302の好ましい態様301を示している。図2および３の対応する構成要素は同じ名称を有する。態様301のキャッシュ・データベース347は、レバーレンズ（Leverenz）ら著「Oracle8 Server Concepts」リリース8.0（Oracle Corporation、カリフォルニア州レッドウッドシチー、1998年）に詳しく記載されているOracle8サーバである。すべてのサーバ203においてウェブアプリケーション111は、同じグローバル・データセット識別子を使用する。所与のサーバ203内のキャッシュ・データベース347は、キャッシュ・データベース347にキャッシングされているデータセット用の、キャッシュ・データベース自体の1組のローカル・データセット識別子を有する。好ましい態様301では、グローバル・データセット識別子を使用するグローバル問合せおよび問合せコンテキストと、ローカル・データセット識別子を使用するローカル問合せおよび問合せコンテキストが使用される。好ましい態様では、問合せアナライザ313が、キャッシングされているデータベース記述305を使用してグローバル問合せコンテキストをローカル問合せコンテキストに変換する。
【００３４】
データ・アクセス層349は、新しい構成要素の問合せディスパッチャ351、すなわち、データ・アクセス層349と問合せ可能なキャッシュ302との間のインタフェースを含む。図6は、好ましい態様の問合せディスパッチャ351の動作のフローチャート601である。括弧内の参照番号はフローチャートの要素を指している。データ・アクセス層349は、ソース・データベース241に問合せを行う準備をする際に、問合せのグローバルコンテキストを問合せディスパッチャ351（605）に与え、問合せディスパッチャは、問合せアナライザ313(607)にグローバルコンテキスト318（図3）を与える。問合せアナライザ313は、グローバルコンテキストによって識別されたデータセットがキャッシュ・データベース347にキャッシングされているかどうかを判定する。キャッシングされていない場合、問合せアナライザ313は、ネットワーク113上にグローバル問合せを配置することをデータ・アクセス層349に示すミス信号319を問合せディスパッチャ351(609)に報告する。
【００３５】
グローバルコンテキストによって決定されたデータセットがキャッシュ・データベース347にキャッシングされている場合、問合せアナライザ313は、このことを問合せディスパッチャ351に示すと共に、キャッシュ・データベース347(615)内のデータセット用のローカルコンテキスト316を問合せディスパッチャ351に与える。次いで、問合せディスパッチャ351は、データ・アクセス層349にローカルコンテキストを与え、データ・アクセス層349はこのローカルコンテキストを使用してグローバル問合せに対応するローカル問合せ317を作成し、ローカル問合せを使用してキャッシュ・データベース347からローカル結果320を得る。本明細書で、グローバル問合せをローカル問合せに変換し、ローカル問合せをキャッシュ・データベース347に適用する際に実行される動作を、多数の異なる方法でデータ・アクセス層349と問合せディスパッチャ351と問合せアナライザ313との間で分割できることに留意されたい。フローチャート601の技法の利点は、データ・アクセス層349が同じ機構を使用してグローバル問合せの場合と同様にローカル問合せを行うことができることである。問合せアナライザ313および問合せディスパッチャ351が必要とするのは、ローカル問合せを作成するのに必要なローカルコンテキストをデータ・アクセス層349に供給することだけである。
【００３６】
問合せキャッシュ302について詳しく説明したが、次に、まずDAインタフェース304について説明する。インタフェース304は、問合せディスパッチャ351からグローバルコンテキスト318を受信し、問合せに関するデータセットがキャッシュ・データベース347内にあるかどうかに応じて、ローカルコンテキスト316またはミス信号319を与える。DAインタフェース304は2つの主要構成要素、すなわち問合せアナライザ313およびキャッシュ・データベース記述マネージャ303を有する。
【００３７】
問合せアナライザ313は、データ・アクセス層253および態様301の他の構成要素から受信されたグローバルコンテキストを分析し、このグローバルコンテキストのグローバル・データセット識別子を得る。問合せアナライザ313は、グローバル・データセット識別子を得た後、それをCDB記述マネージャ303に与え、CDB記述マネージャ303は、キャッシュ・データベース305でこれらのグローバル・データセット識別子を調べる。キャッシュ・データベース記述305は、データセットのテーブルである。各データセットのテーブルには少なくとも、キャッシュ・データ347内にコピーを有するエントリがある。このような各エントリは、データセットのグローバル識別子およびローカル識別子を含む。テーブルは問合せ情報307も含む。次いで、CDB記述マネージャ303は、このデータセットがキャッシュ・データベース347内にあるかどうかの表示を返す（H/M 311）。キャッシュ・データベース347内にない場合、この問合せをキャッシュ・データベース347上で実行することはできないが、ソース・データベース241上で実行しなければいけない。その結果、問合せアナライザ313がミス信号319を問合せディスパッチャ351へ返す。問合せがキャッシュ・データベース347上で実行可能な場合、問合せアナライザ313は、ヒット信号319を返すと共に問合せのローカルコンテキスト316を返す。上記で指摘したように、次いで、問合せディスパッチャ351は、データ・アクセス層349にローカルコンテキスト316を与え、データ・アクセス層349は、このローカルコンテキスト316を使用してキャッシュ・データベース347に対してローカル問合せ317を行う。次いで、キャッシュ・データベース347は、データ・アクセス層349にローカル結果320を返す。
【００３８】
図5は、CDB記述305の詳細を示している。好ましい態様では、CDB記述305は、キャッシュ・データベース347にコピーがあるソース・データベース241の各データセットごとに、少なくともエントリ501を有するテーブルである。各エントリ501は、データセットのコピーを含む問合せ可能なキャッシュ219を有するすべてのサーバ107においてデータセットを認識するためのデータセットのグローバル・データセット識別子と、キャッシュ・データベース347においてデータセットを認識するためのローカル・データセット識別子505と、ある時間間隔にわたってデータセットが問い合わされた回数を示す問合せ数507とを含む。好ましい態様では、問合せ数507は問合せ情報307を具体化したものである。
【００３９】
所与のデータセットのエントリ501(i)は、好ましい態様では、データセットのグローバル・データセットID 507を取り出しハッシュしてテーブル305におけるエントリ・インデックス509を得るハッシュ関数503によってアクセスされる。次いで、CDB記述マネージャ303が、テーブル305において、フィールド503がエントリ・インデックス509から始まるグローバルDSID 511を指定するエントリ501を探索する。このようなエントリが見つからない場合、このデータセットはキャッシュ・データベース347に存在せず、CDB記述マネージャ303は、問合せアナライザ313にミス信号311を送信する。テーブル305は、現在キャッシュ・データベース347にキャッシングされていないグローバル・データセットのエントリを含むこともできる。このようなエントリにおいて、ローカル・データセットID 505はヌル値を有し、このヌル値に応答してミス信号が返される。このようなエントリの目的は、このようなデータセットの問合せ数情報507を維持し、それによって、データセット・マネージャ323がこのエントリのデータセットをキャッシュ・データベース347に追加すべきかどうかを判定できるようにすることである。
【００４０】
更新レシーバ321は、ソース・データベース・サーバ237によってデータ・アクセス層253から与えられた更新問合せを受信し、更新の影響を受けるデータセットがキャッシュ・データベース347内にあるかどうかを、問合せアナライザ313を使用して判定する。キャッシュ・データベース347内にない場合、更新レシーバ321はこの更新を無視する。キャッシュ・データベース347内にある場合、更新レシーバ321は更新問合せ329を変更待ち行列333内に配置する。リフレッシャ331が待ち行列333を読み取り、その問合せを実行する。
【００４１】
データセット・マネージャ323は、CDB記述305内の問合せ情報307を使用して、キャッシュ・データベース347にどのデータセットを追加すべきか、またはキャッシュ・データベース347からどのデータセットを削除すべきかを判定する。データセットを追加する場合、DSM 323は、ソース・データベース241に対して必要な問合せを行い、結果が到着すると、それを更新問合せ239に変換して変更待ち行列333に与える。更新問合せ329は、上述のように、変更待ち行列333からリフレッシャ331によって実行される。DSM 323はさらに、327で示すように、DSM 323がキャッシュ・データベース347で行う変更の必要に応じてCDB記述305を更新する。
【００４２】
好ましい態様では、DSM 323およびリフレッシャ331は独自のスレッドまたはプロセスを有する。本明細書で、CDB記述305および変更待ち行列333をキャッシュ・データベース347内のデータベース・テーブルとして実現できることに留意されたい。これらの構成要素がキャッシュ・データベース347とは独立に実現され、キャッシュ・データベース347のインタフェースとして抽象問合せトランスレータ339が使用されるので、態様301は主として、キャッシュ・データベース347を実現するために使用される特定の種類のデータベース・システムから独立したものである。態様301では、データ・アクセス層203はデータ・アクセス・インタフェース304への読取り問合せを行うに過ぎない。すべての更新問合せは直接サーバ237に対して行われ、更新がキャッシュ・データベース347に入力されることはない。他の態様では、問合せ可能なキャッシュ219をライトスルー・キャッシュとして実現することができ、すなわち、更新をキャッシュ・データベース347に入力することができると共に、サーバ237に送信することもできる。本明細書で、大部分のウェブアプリケーションが主として読取りアプリケーションであり、すなわち、ウェブユーザが通常、情報の変更よりも読取りにずっと多くの時間を費やすことに留意されたい。たとえば、ウェブ商取引では、「ショッピング」は主としてHTMLページを読み取ることでありう、更新が行われるのは、ユーザが自分の「ショッピング・カート」に何かを追加するか、または何かを購入する場合だけである。システム201などのシステムでは、通常、ソース・データベース241が更新されるのは購入時だけである。
【００４３】
ソース・データベース・サーバ237の詳細：図4
図4は、ソース・データベース・サーバ237の好ましい態様を示している。好ましい態様のソース・データベース・サーバ237は、ソース・データベース241と、データベース241のデータ値421のコピー用のバッファ・キャッシュ407およびデータベース241のメタデータのコピー用のディクショナリ・キャッシュ409を含むメモリ415とが記憶されているディスク・ドライバ421を含むコンピュータ・システム上で実行されるOracle8サーバによって実現される。メタデータとは、データベース内のデータを記述した内容を有するデータベース・テーブルである。サーバ・メモリ415内のキャッシングされているデータのソース・データベース241への書直しはデータベース書込みプロセス325によって処理される。各プロセス401(0..n)は、サーバ203を表し、かつサーバ203に対応しており、キャッシュ・ミスの結果として行われる問合せ、更新問合せ、および対応するサーバ203内のDSM 323からの問合せを処理する。ディスパッチャ311は、これらのプロセスのそれぞれが次に共用サーバ・プロセス317にアクセスできるようにし、共用サーバ・プロセス317は、実際の問合せを実行し結果を問合せプロセスに返す。問合せプロセスは、結果をネットワーク235を介して対応するサーバ203に返す。
【００４４】
ソース・データベース・サーバ237のOracle8の実現は、キャッシングされているデータ223にコピーされているソース・データベース241内のデータが変更された場合に各サーバ203(0..n)内の問合せ可能なキャッシュ219に自動的に更新を送信する更新トランスミッタ243の実現が追加された標準Oracle8データベース・システムである。図4中の更新トランスミッタ243の構成要素は、参照番号243とその構成要素自体の参照番号とで示されている。好ましい態様の更新トランスミッタ243の実現態様はデータベース・トリガを使用する。データベース・トリガとは、データベース内のデータ値またはメタデータの項目において定義済みの変更が行われた場合に取られる処置を指定したものである。多くのデータベース・システムではトリガを定義することができる。Oracle8データベース・システムのトリガは、レバーレンズ（Leverenz）文献の17-1ページから17-17ページに詳しく記載されている。
【００４５】
好ましい態様では、サーバ203(i)に対応するプロセス401(i)が、サーバ203(i)のキャッシングされているデータ223にデータを追加するための、サーバ203(i)内のDSM 323からの問合せを受信すると、プロセス203(i)がトリガ設定コード403を実行する。このコードは、各データ行ごとのメタデータ417および/または問合せに指定されたメタデータにおいてOracle8 AFTER行トリガを設定する。トリガのデータ行が修正された場合は常に、共用サーバ・プロセス317が、トリガに指定された処置を取る。トリガに関して指定される処置は、キャッシングされているデータ223内のデータをソース・データベース241の場合と同様に修正する更新問合せと共にメッセージを各サーバ203(0..n)に送信する処置である。好ましい態様では、トリガによって実行される処置は、Oracle8高度待ち行列として実現されるメッセージ待ち行列414内の更新問合せとメッセージを組み合わせる処置である。メッセージ待ち行列414は更新プロセス402によって読み取られ、更新プロセス402は待ち行列414内のメッセージを各サーバ203(0..n)に送信する。
【００４６】
図3および図4に示す好ましい態様において、インターネット105のユーザの行動の変化に応答するかまたはそれを予期して、キャッシングされているデータ223に新しいデータを追加し、ソース・データベース241の変更に応答して、キャッシングされているデータ223を更新することは当然、他の多数の方法で実現することができる。たとえば、キャッシングされているデータ223にどのデータが存在すべきかの判定は、各サーバ203ではなくソースDBSサーバ237で行うことができる。ソース・データベース241は、サーバ203(0..n)内のキャッシュ・データベース347と同様に、統計情報を維持することができ、ソース・サーバ237内の送信プロセス404は、DSM 323に関して説明した方法と実質的に同じ方法でこの統計を分析し、キャッシングされているデータ223にキャッシングすべきデータとしてどのデータをサーバ203(0..n)に送信すべきかを判定し、そのデータ用の更新問合せを作成し、更新問合せを含むメッセージをメッセージ待ち行列414内に配置する。更新プロセス402は、更新問合せをメッセージ待ち行列414からサーバ203に送信することができる。
【００４７】
ソース・データベース241の変更に応答して、キャッシングされているデータ223を更新することは、トリガなしで実現することもできる。Oracle8データベース・システムは、ソース・サーバ・メモリ415内に再実行ログ413、すなわち、ソース・データベース241上で実行された更新の循環バッファを含む。このデータベース・システムは、システム障害が起こった場合に更新を再実行できるようにこのログを維持するが、このログを使用して、キャッシングされているデータ223を更新することもできる。キャッシングされているデータ223を記述するテーブルがソース・データベース241に存在する場合、更新プロセス402は、このテーブルを再実行ログ413と共に使用して、再実行ログの更新が、キャッシングされているデータ223に影響を与えるかどうかを判定することができる。影響を与える場合、更新プロセス402は、上述のように更新問合せのコピーをサーバ203に送信することができる。
【００４８】
データベース・システムを含まないキャッシング・サーバおよびソース・サーバ  サーバ203にどのデータをキャッシングすべきかを判定し、キャッシングされているデータ223を更新するために使用される技法を、データが問合せ可能ではないシステムで使用することもできる。たとえば、ソース・データは、おそらく文書番号（文書がHTMLページである場合のURLなど）によって識別される単なる文書の集合でよく、キャッシングされているデータはこの集合の単なるサブセットでよい。キャッシュウェブアプリケーション211がこのようなシステムでHTML構成要素109から受信するものは、文書の文書番号に過ぎない。文書番号が、キャッシングされているデータ内に存在する場合、キャッシング・サーバはそのデータから文書番号を返し、該データ内に存在しない場合は、ソース・サーバから取り込む。このような場合の問合せログ205は、要求されている文書のタイム・スタンプ付きリストと、キャッシングされているデータに文書が存在しているかどうかの表示である。このような態様のDSM 213は、上記でデータベースに関して説明したように、キャッシングされているデータに文書を含めるべきかどうかを判定し、判定を下した後、ソース・サーバから文書を得る。やはり上述のように、ソース・サーバ上の送信構成要素も同じ判定を下し、文書をキャッシング・サーバに送信することができる。
【００４９】
更新のために、ソース・サーバは、キャッシング・サーバに現在存在している文書のリストを維持するに過ぎない。リスト上の１つの文書が更新された場合、更新トランスミッタ243が文書の新しいバージョンをキャッシング・サーバに送信し、キャッシング・サーバ内のDSM 213がキャッシュ内の文書の任意のコピーをこの新しいコピーで置き換える。上記で文書に関して説明した技法は当然、ファイルに対して使用することも、音声データ、画像データ、および動画データに対して使用することもできる。
【００５０】
結論
上記の詳細な説明は、本明細書で説明した本発明の原則を実現するウェブサーバについて説明したものである。言うまでもなく、本発明はウェブサーバに限らず、キャッシュを、キャッシングされているデータの供給源に整合させておく必要がある状況、何がキャッシングされるのかを判定する必要がある状況、キャッシングされているデータに対して問合せを行うことが望ましい状況、より高いレベルで実行されているプログラムに対してキャッシュを透過的にすることが望ましい状況など、あらゆる状況で使用することができる。本発明者らは、本発明を実現する人に現在知られている最良の態様を開示したが、本発明に関与する当業者には、本発明の原則を実現する他の多数の方法があることが直ちに明らかになろう。
【００５１】
すべての前述の理由で、詳細な説明はすべての点で制限的なものではなく例示的なものとみなすべきあり、本明細書で開示された本発明の範囲は、詳細な説明から決定されるのではなく、特許法によって許容される全範囲によって解釈される特許請求の範囲から決定されるべきである。
【図面の簡単な説明】
【図１】  WWWを介して問合せを実行する先行技術のシステムの例を示す図である。
【図２】  本発明のシステムの高次ブロック図である。
【図３】  サーバ203の実現態様の詳細の詳細ブロック図である。
【図４】  ソース・データベース・サーバ237の実現態様の詳細の詳細ブロック図である。
【図５】  キャッシュ・データベース記述305の詳細を示す図である。
【図６】  問合せデスパッチャ351の動作のフローチャートである。
図面中の参照番号は3桁以上の数字を有する。右側の2桁の数字は、残りの数字によって示される図面中の参照番号である。したがって、参照番号203を有する項目は最初、図2中の項目203として表される。
【図１】
0004593793.tif 000002
【図２】
0004593793.tif 000003
【図３】
0004593793.tif 000004
【図４】
0004593793.tif 000005
【図５】
0004593793.tif 000006
【図６】
0004593793.tif 000007