Persistent key-value repository with a pluggable architecture to abstract physical storage

• US 7,617,218 B2
• Filed: 04/13/2006
• Issued: 11/10/2009
• Est. Priority Date: 04/08/2002
• Status: Expired due to Term

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Srivastava, Alok K., Kumar, Raj, Joshi, Sameer, Chatterjee, Surojit, Creighton, Jonathan
• Primary Examiner(s): Ali; Mohammad
• Assistant Examiner(s): ROLAND, GRISELLE CORBO
• Application Number:
  US11/404,159
• Publication Number:
  US 20060195450A1
• Time in Patent Office: 1,307 Days
• Field of Search: 707/9, 707/10
• US Class Current: 1/1
• CPC Class Codes: G06F 16/252 between a Database Management System and a front-end application
• CPC Class Codes: Y10S 707/99931 Database or file accessing
• CPC Class Codes: Y10S 707/99932 Access augmentation or optimizing
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

A system and techniques are described for managing key-value pairs using an architecture that does not restrict its users to any specific platform or storage subsystem. According to one aspect of the invention, the repository is portable in that the architecture need not change based on the environment and platform in which the repository is used. Rather, the portion of the architecture that is platform-specific is limited to plug-ins at a storage abstraction layer of the repository. The plug-ins expose the same storage abstraction interface to the other layers of the repository, but are implemented to interact with different platforms and storage subsystems. Consequently, in response to being ported from one platform to another, the repository may simply change the plug-in to invoke for persistent storage operations.

Claims

1. A method for storing key-value pairs, the method comprising:

on a node on which a first client and a second client reside, exposing a repository interface through which the first and second clients make calls to store and access key-value pair information in a repository;

receiving a first call from the first client through a routine that implements a portion of said repository interface; and

based on said first call, establishing a first component that is associated with said first client but not said second client as a sole caching component responsible for managing a cache for said repository on said node;

receiving, at a second component that is associated with said second client but not said first client, a second call from the second client;

determining whether said second component is the caching component for said node; and

in response to determining that said second component is not said caching component for said node, passing said second call to said caching component for processing by said caching component.

2. The method of claim 1 wherein:

the repository supports a plurality of access modes, including a caching access mode and a default access mode;

the step of receiving the first call includes receiving a call that specifies one of the caching access mode and the default access mode; and

the method includes the step of establishing the first component of said repository as the sole caching component for the node only if said first call specifies said caching access mode.

3. The method of claim 1, wherein said node is a first node of a plurality of nodes, and further comprising the step of:

in response to determining that the cache managed by the caching component on the first node does not include information required by a particular request from said first client, sending said particular request to a third component residing on a second node that is remote relative to said first node.

4. The method of claim 2 wherein:

the plurality of access modes further include an installation access mode and a read only access mode;

clients use said installation access mode when initially creating said repository; and

clients use said read only access mode when booting from said repository.

5. A non-volatile or volatile computer-readable storage medium storing instructions for storing key-value pairs, the non-volatile or volatile computer-readable storage medium comprising instructions for performing the steps of:

on a node on which a first client and a second client reside, exposing a repository interface through which the first and second clients make calls to store and access key-value pair information in a repository;

receiving a first call from the first client through a routine that implements a portion of said repository interface; and

based on said first call, establishing a first component that is associated with said first client but not said second client as a sole caching component responsible for managing a cache for said repository on said node;

receiving, at a second component that is associated with said second client but not said first client, a second call from the second client;

determining whether said second component is the caching component for said node; and

in response to determining that said second component is not said caching component for said node, passing said second call to said caching component for processing by said caching component.

6. The non-volatile or volatile computer-readable storage medium of claim 5 wherein:

the repository supports a plurality of access modes, including a caching access mode and a default access mode;

the step of receiving the first call includes receiving a call that specifies one of the caching access mode and the default access mode; and

the method includes the step of establishing the first component of said repository as the sole caching component for the node only if said first call specifies said caching access mode.

7. The non-volatile or volatile computer-readable storage medium of claim 6, wherein said node is a first node of a plurality of nodes, and further comprising the step of:

in response to determining that the cache managed by the caching component on the first node does not include information required by a particular request from said first client, sending said particular request to a third component residing on a second node that is remote relative to said first node.

8. The non-volatile or volatile computer-readable storage medium of claim 6 wherein:

the plurality of access modes further include an installation access mode and a read only access mode;

clients use said installation access mode when initially creating said repository; and

clients use said read only access mode when booting from said repository.