IP Library Granted Patent US 7,792,885
Granted Patent B2
US 7,792,885 · App. 11/248,147 · Granted Sep 7, 2010

Database RAM cache

Assignee: Alcatel Lucent
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 7,792,885
App. No.
11/248,147
Granted
Sep 7, 2010
Kind
B2
Abstract

A system and method are provided for providing a shared RAM cache of a database, accessible by multiple processes. By sharing a single cache rather than local copies of the database, memory is saved and synchronization of data accessed by different processes is assured. Synchronization between the database and the shared cache is assured by using a unidirectional notification mechanism between the database and the shared cache. Client APIs within the processes search the data within the shared cache directly, rather than by making a request to a database server. Therefore server load is not affected by the number of requesting applications and data fetch time is not affected by Inter-Process Communication delay or by additional context switching. A new synchronization scheme allows multiple processes to be used in building and maintaining the cache, greatly reducing start up time.

Claims (39)

1. A method of providing a plurality of processes with access to data stored in a cache, comprising:

copying the data from a database to the cache in a shared memory, the shared memory being directly accessible by each process of the plurality of processes without using a database server;

maintaining synchronicity between the database and the cache, wherein any alteration of the database triggers creation of a message comprising a table identifier (ID) of a table within the database, a row ID, and an action flag, wherein the action flag signifies one of addition, deletion, and update in the database;

when the action flag signifies either deletion or update, setting a row status flag to the table ID and the row ID that correspond to the action flag in the cache as update pending or deletion pending;

modifying the cache in response to the message, wherein the action flag specifies the modification performed in a row identified by the table ID and row ID;

providing each process with an Application Program Interface (API) that allows each process to access the data within the cache; and

preventing said API from accessing said data from within the cache when the row status flag of an accessed row is marked as update pending or deletion pending.

2. The method of claim 1 , further comprising:

using a plurality of worker threads to copy the data from the database to the cache, wherein the cache comprises: for each table in the database, at least one linked list of data segments storing data from the table,

a plurality of control segments in the cache, wherein each control segment stores an address of a different first data segment in each linked list, and each data segment corresponds to a unique worker thread, whereby the worker thread corresponding to a second data segment copies data from the database into the second data segment in the cache once the first data segment is full, except that a last entry in a last data segment in the linked list of data segments stores an invalid address, and

a master segment containing a plurality of entries within the cache, wherein each master segment entry stores an address for a different control segment.

3. The method of claim 1 , further comprising:

rowlocking a portion of the data in the cache when a corresponding row and table in the database is deleted or modified until the deletion or modification in the database is verified, thereby preventing the processes from accessing the portion of the data while deletions or modifications in the database are being synchronized with the cache.

4. The method of claim 1 , further comprising:

creating at least one worker thread, each worker thread assigned a task of modifying a portion of the cache;

creating a notification group object (NGO);

upon completion of each worker thread of its assigned task, destroying the NGO; and

upon destruction of the NGO, removing any rowlock for the portion of the cache identified by the message.

5. A cache that stores data from a database having a plurality of tables, the cache having a data structure stored on a computer-readable medium, wherein the computer-readable medium is a shared memory that is directly accessible by a plurality of processes without using a database server, the data structure comprising:

for each table of the plurality of tables, at least one linked list of data segments storing data from the table, wherein each first data segment corresponds to a unique worker thread and has an address of a second data segment as its last entry, whereby the worker thread corresponding to the second data segment copies the data from the database to the second data segment in the cache once the first data segment is full, except that a last entry in a last data segment in the linked list of data segments stores an invalid address, wherein any alteration of the database triggers creation of a message comprising a table identifier (ID) of a table within the database, a row ID, and an action flag, wherein the action flag signifies one of addition, deletion, and update in the database;

a plurality of control segments, wherein each control segment stores an address of a different first data segment in each linked list of data segments;

a master segment containing a plurality of entries, wherein each master segment entry stores an address for a different control segment; and

row status flags that block access to data in the cache in a specified row of each table when said row status flags are marked as update pending or deletion pending, wherein the row status flags are set to corresponding table IDs and row IDs in the cache as update pending or deletion pending when the action flag signifies either deletion or update.

6. The method of claim 1 , wherein the message is three integers in length, each integer respectively corresponding to the table ID, the row ID, and the action flag.

7. The method of claim 1 , wherein a controller sets the row status flag, deletes the message from a first queue, and forwards the message to a second queue.

8. The method of claim 1 , further comprising:

determining that an action in the database is neither deletion, addition, nor update; and

in response to the determination, discarding the message and generating an error report.

9. The method of claim 4 , wherein the NGO is an object oriented programming object.

10. The method of claim 4 , wherein the NGO comprises at least one of a group status, a request count, a completed request count, a blocked status, and a condition variable.

11. A method of providing a plurality of processes with access to data stored in a cache, comprising:

copying the data from a database to the cache in a shared memory, the shared memory being directly accessible by each process of the plurality of processes without using a database server;

maintaining synchronicity between the database and the cache, wherein any alteration of the database triggers creation of a message comprising a table identifier (ID) of a table within the database, a row ID, and an action flag, wherein the action flag signifies one of addition, deletion, and update in the database;

when the action flag signifies either deletion or update, setting a row status flag to the table ID and the row ID that correspond to the action flag in the cache as update pending or deletion pending;

modifying the cache in response to the message, wherein the action flag specifies the modification performed in a row identified by the table ID and row ID;

providing each process with an Application Program Interface (API) that allows each process to access the data within the cache;

preventing said API from accessing said data from within the cache when the row status flag of an accessed row is marked as update pending or deletion pending;

determining that an action in the database is neither deletion, addition, nor update; and in response to the determination, discarding the message and generating an error report; and

using a plurality of worker threads to copy the data from the database to the cache, wherein the cache comprises: for each table in the database, at least one linked list of data segments storing data from the table, a plurality of control segments in the cache, wherein each control segment stores an address of a different first data segment in each linked list, and each data segment corresponds to a unique worker thread, whereby the worker thread corresponding to a second data segment copies data from the database into the second data segment in the cache once the first data segment is full, except that a last entry in a last data segment in the linked list of data segments stores an invalid address, and a master segment containing a plurality of entries within the cache, wherein each master segment entry stores an address for a different control segment, the message is three integers in length, each integer respectively corresponding to the table ID, the row ID, and the action flag, a controller sets the row status flag, deletes the message from a first queue, and forwards the message to a second queue

Assignments (9)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Dec 28, 2021
From: PROVENANCE ASSET GROUP LLC
To: RPX CORPORATION
Reel/Frame 059352/0001 →
RELEASE OF SECURITY INTEREST Recorded Nov 30, 2021
From: CORTLAND CAPITAL MARKETS SERVICES LLC
To: PROVENANCE ASSET GROUP HOLDINGS LLC; PROVENANCE ASSET GROUP LLC
Reel/Frame 058983/0104 →
RELEASE OF SECURITY INTEREST Recorded Nov 30, 2021
From: NOKIA US HOLDINGS INC.
To: PROVENANCE ASSET GROUP HOLDINGS LLC; PROVENANCE ASSET GROUP LLC
Reel/Frame 058363/0723 →
ASSIGNMENT AND ASSUMPTION AGREEMENT Recorded Feb 14, 2019
From: NOKIA USA INC.
To: NOKIA US HOLDINGS INC.
Reel/Frame 048370/0682 →
SECURITY INTEREST Recorded Sep 13, 2017
From: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP LLC
To: NOKIA USA INC.
Reel/Frame 043879/0001 →
SECURITY INTEREST Recorded Sep 13, 2017
From: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP, LLC
To: CORTLAND CAPITAL MARKET SERVICES, LLC
Reel/Frame 043967/0001 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Sep 13, 2017
From: NOKIA TECHNOLOGIES OY; NOKIA SOLUTIONS AND NETWORKS BV; ALCATEL LUCENT SAS
To: PROVENANCE ASSET GROUP LLC
Reel/Frame 043877/0001 →
CHANGE OF NAME Recorded Jul 12, 2010
From: ALCATEL
To: ALCATEL LUCENT
Reel/Frame 024663/0501 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Dec 1, 2005
From: PIPER, RICHARD MATTHEW; PILON, MARK CHRISTOPHER; LANDRY, FELIX M.
To: ALCATEL
Reel/Frame 017293/0796 →
Priority Claims (1)
CA 2484694 · Oct 14, 2004 · national
Continuity (1)
Related Publication 20060085418A1 · Apr 20, 2006