Browse Prior Art Database

Automatic Cache Invalidation and Refresh in a Client Server Environment

IP.com Disclosure Number: IPCOM000105372D
Original Publication Date: 1993-Jul-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 6 page(s) / 268K

Publishing Venue

IBM

Related People

Barnes, CC: AUTHOR [+3]

Abstract

Described is a method for automatic cache invalidation and refresh in a client server environment. Refer to [*] for additional information concerning the base caching system. The environment assumes performance optimizing caches consisting of a set of files (or other objects), cached together according to some grouping, such as directories, in a client environment. It further assumes a server that manages a data repository. This server accumulates and manages Cache Notification Records (CNRs) which can be copied and sent to each interested client. When CNRs are pending in the server for a particular client, the client is "shoulder tapped" (signalled by the server as a means of notification).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 22% of the total text.

Automatic Cache Invalidation and Refresh in a Client Server Environment

      Described is a method for automatic cache invalidation and
refresh in a client server environment.  Refer to [*] for additional
information concerning the base caching system.  The environment
assumes performance optimizing caches consisting of a set of files
(or other objects), cached together according to some grouping, such
as directories, in a client environment.  It further assumes a server
that manages a data repository.  This server accumulates and manages
Cache Notification Records (CNRs) which can be copied and sent to
each interested client.  When CNRs are pending in the server for a
particular client, the client is "shoulder tapped" (signalled by the
server as a means of notification).  The actual sending of CNRs to a
client occurs when a client asks for the CNRs or otherwise comes to
the server with data repository requests.

      The method avoids server failures and the accompanied loss of
the data repository by clients through inability to maintain or
retain required CNRs in the server and therefore avoids compromising
the integrity of client caches.  Examples of such failures are:  1)
server out of primary storage (memory), e.g., due to excessive
accumulation of CNRs, and 2) failure to get primary storage required
to build a CNR  with this broad scope of caching, it is not practical
to refresh the entire cache whenever a small portion of the cache is
affected by a change.  Instead incremental CNRs are sent to update
the client caches.  The function in the server that has
responsibility of managing the CNRs for client caches is called the
Server Cache Manager.  There is also a system function, the Client
Cache Manager, in each client environment that accepts these CNRs and
applies them to the local cache.

           The environment is summarized at a high level in Fig. 1.
In Fig. 1 the numbers correspond to the following descriptive items:

1.  Client request that caching begin in a particular scope, e.g.,
    for a particular directory.

2.  Server calls upon its Cache Manager to record that the client is
    currently one of the clients that have the object cached (needed
    in order to know where to send future CNRs).

3.  Server responds with a complete refresh of data for the scope.
    This is done by reading direct access storage device records and,
    from these records, building a complete set of CNRs for the
    directory.  These CNRs are stored in buffers and sent to the
    client.

4.  Client Cache Manager receives the cache refresh CNRs and builds
    the client cache records from them.

5.  Another client makes a request to change a data object in the
    server's repository.  The server updates the direct access
    storage device accordingly.

6.  Server also calls upon its Cache Manager to record the current
    change by creating a CNR in memory.  This CNR is reta...