Method and system for data element change across multiple instances of data base cache

A method and system for updating and maintaining cache coherency across nodes in a cluster. The method uses a combination of read and write locks on the instances of the cache, with some embodiments using a master locking database. Periodic validations of timestamps are used to identify lack of coherency of the cache, such as resulting from a network failure.

BACKGROUND OF INVENTION

1. Field of the Invention

The invention pertains to the field of data base cache, and more particularly to cache management with data updates.

2. Background of the Related Art

Various types of database cache are known, with techniques for update or refresh of the cache upon a change in one of the data elements. Examples are J2EE Container Managed Persistence and products such as Persistence. However, these products do not provide a locking strategy that works at a logical transaction level. Most Container Managed Persistence mechanisms rely on network connectivity between the nodes to ensure cache integrity. Further, existing products are designed to work within a single cluster.

What is needed is a system and method for cache management across heterogeneous clusters.

The preceding description is not to be construed as an admission that any of the description is prior art to the present invention.

SUMMARY OF INVENTION

In one aspect, the invention provides a method and system for management of data cache. A database lock of a named cache is requested, the named cache is locked, a local lock of the named cache at a local node is acquired, a timestamp corresponding to the local lock is generated, a cache item of the named cache is invalidated in the local node, the local lock of the named cache is released, a message is sent to a remote node identifying the cache item of the named cache, an acknowledgment of the message is received from the remote node, an update of the cache item of the named cache is sent, the named cache is updated and the database lock of the named cache is released.

In another aspect, the invention provides a method and system for management of data cache. A cache miss of a cache item is identified, a read lock of a named cache is requested, the named cache including the cache item, the named cache is read locked, the cache item is requested from a master locking database, the cache item is received, and the read lock of the named cache is released.

In another aspect, the invention provides a method and system for management of data cache. A cache miss of a cache item is identified, a read lock of a global database is requested, the global database including the cache item, the global database is read locked, the cache item is requested from a master locking database, the cache item is received, and the read lock of the global database is released.

In another aspect, the invention provides a method and system for management of data cache. A predetermined event is determined to have occurred, a read lock of a named cache is requested, a timestamp is requested, an indication of a read lock of the named cache is received, a timestamp is received, the received timestamp is compared with a previous timestamp, responsive to the comparison, a predetermined action is performed, and the read lock of the named cache is released.

The specific aspects and advantages of the invention described and illustrated herein are illustrative of those which can be achieved by the present invention and are not intended to be exhaustive or limiting of the possible advantages that can be realized. Thus, the aspects and advantages of this invention will be apparent from the description herein or can be learned from practicing the invention, both as embodied herein or as modified in view of any variations which may be apparent to those skilled in the art. Accordingly, the present invention resides in the novel parts, constructions, arrangements, combinations and improvements herein shown and described

It is understood that the drawings are for illustration only and are not limiting.

DETAILED DESCRIPTION OF THE DRAWINGS

The invention solves a problem of maintaining cache coherency in a distributed system with a central database server. The cache coherency mechanism ensures that updates are synchronous across all instances of the cache in the distributed system (i.e., that an update takes effect on all nodes in the system at the same time and no node is ever out of synchronization with another node.) In this way, the system is never in an inconsistent state. To accomplish this, the invention uses an integrated lock across threads, across Virtual Machines and across address spaces.

The invention has backup mechanisms in case of network failures and also allows the system to be brought back up into a consistent state after a complete failure. The invention allows caches to be taken down and brought up in different address spaces at different times but does not dictate the way that persistence is implemented (i.e., this mechanism can be used on top of existing code, allowing custom cache flushing mechanisms).

Use of a master database in one embodiment of the invention provides a way to enforce synchronization across the system using transactionality. Other known invalidation mechanisms usually either implement a custom invalidation mechanism (such as a send/ack invalidation mechanism), or use some form of global lock. The present invention is generally easier than implementing a custom global cache synchronization mechanism. The cache implementation of the invention also provides an easy way to integrate the distributed cache with other transactional database updates. This design maps cache invalidations against logical data groupings that are different than the physical table structure of the database. The synchronization mechanism also avoids causality race conditions (sequencing, etc).

Referring first toFIG. 1, system100of the invention includes local node102, cache manager104and remote node(s)106. One embodiment also includes a primary or master locking database110. Network108interconnects local node102, cache manager104and remote node(s)106. Where system100includes primary database110, database110is also interconnected to the other elements of system100by network108. Network108is any of a number of different types of wired and wireless networks, including local area network (LAN) and wide area network (WAN).

Although not illustrated inFIG. 1, each of local node102, cache manager104, remote node(s)106and database110include one or more fixed and removable software code storage media, processor and memory to run the software code as well as input/output devices and network interface devices.

Steps in one embodiment of the invention are illustrated in FIG.2. At step202, local node102determines that a cache element in a named cache requires modification. The need for modification may include the need for an update, or a data change.

At step204, local node102requests a database lock of the named cache. It is also possible that the request for a database lock at step204is a request for a global lock of the master database.

At step206, cache manager104receives the request for a database lock of the named cache (or global lock of the master database), and locks the named cache (or master database).

At step208, cache manager104sends an indication to local node102that the named cache (or master database) is locked.

At step210, local node102receives the indication from cache manager104that the named cache (or master database) is locked.

At step212, local node102acquires a local write lock of the named cache. Although called a write lock, the write lock includes a read lock of the named cache.

At step214, local node102sends a timestamp to cache manager104for use in an update of the lock table.

At step216, cache manager104receives the timestamp, and at step218cache manager104updates the lock table with the timestamp from local node102. It is also possible that the timestamp is merely requested by local node102and cache manager104provides the timestamp.

After sending the timestamp at step214, then at step220, local node102invalidates the cache item of the named cache that is held by local node102.

At step222, after invalidating the cache item, local node102releases the write lock of the named cache.

At step224, local node102broadcasts an invalidation message to all remote nodes106, identifying the cache item of the named cache.

At step226, each remote node106receives the broadcast invalidation message, identifying the cache item of the named cache.

At step228, each remote node106acquires a local write lock of the named cache in their own remote node.

At step230, each remote node106invalidates the cache item of the named cache in their own remote node.

At step232, after invalidating the cache item of the named cache in their own remote node, each remote node106sends an acknowledgment (ack) message to local node102.

At step234, each remote node106releases the local write lock of the named cache in the remote node.

At step236and238, after broadcasting the invalidation message at step223, local node102waits for acknowledgment from each of the remote nodes106.

It is possible that there is some delay in sending the acknowledgment (ack) from each remote node, or that the network connection to one or more of the remote nodes is lost and therefore the remote node does not receive the broadcast message, or is unable to send an acknowledgment. Therefore, although not illustrated, in one embodiment, a time-out timer may limit the length of time that local node102waits at steps236and238for all acknowledgments.

At step240, after all acknowledgments have been received from remote nodes106, local node102sends the update of the cache item in the named cache to master locking database110.

At step244, master locking database110receives the update and performs the update to cache item of the named cache in the master locking database.

At step246, master locking database110commits the update of the cache item to the named cache of the master database.

At step248, after confirmation of the commit at step246, cache manager104releases the lock of the named cache (or global database).

As illustrated inFIG. 2, once the steps are complete, local node102and remote node(s)106have invalidated the cache item of the named cache in the remote nodes, but have not updated the cache item of the named cache in the local node or remote nodes. Therefore, when a request is made to either the local node102or the remote node(s)106for the cache item of the named cache, the local node or remote node generates a cache miss and must make a call to master database110.

Referring now toFIG. 3, steps for dealing with a cache miss are illustrated. At step302, the node (either the local node102or remote node106that generated the cache miss), identifies a cache miss of the cache item.

At step304, the node (102or106) requests a read lock of the named cache (or global database).

At step306, cache manager104receives the request, and read locks the named cache (or global database).

At step308, cache manager104sends an indication to the node (102or106) that the named cache (or global database) is read locked.

At step310, the node (102or106) receives an indication that the named cache (or global database) is read locked.

At step312, the node (102or106) requests the cache item from master locking database110.

At step314, master locking database110receives the request for the cache item, and at step316, master locking database110sends the cache item from the master locking database110.

At step318, the node (102or106) receives the cache item from master locking database110.

At step320, the node (102or106) sends a release of the read lock of the named cache (or global database) to cache manager104.

At step322, cache manager104receives the release of the read lock, and at step324releases the read lock of the named cache (or global database).

After completing the steps illustrated inFIG. 3, the node that experienced a cache miss of the cache item in the named cache has received an update of the cache item.

Referring now toFIG. 4, an embodiment of the invention includes cache manager104, but does not include a separate master locking database110. In this embodiment, the named cache is replicated and distributed among local node102and remote nodes106.

Steps202through238are similar to or the same as the correspondingly numbered steps of FIG.2.

At step402, local node102updates the cache item of the named cache in the local node, and at step404, local node102commits the update to the named cache and ends.

Referring now toFIG. 5, which illustrates an embodiment for handing a cache when there is a cache manager but no separate master locking database. In this embodiment, the named cache is replicated and distributed among local node102and remote nodes106. In the example illustrated inFIG. 5, the update of the cache item is made to local node102, and remote node106experiences a cache miss.

Steps302through310and320through324are the same or similar to the similarly number steps of FIG.3.

At step502, remote node106, which experienced the cache miss, requests the cache item from local node102.

At step504, local node102receives the request for the cache item, and at step506, sends the requested cache item to remote node106.

At step508, remote node106receives the cache item from the local node and, although not illustrated in the figure, updates the cache item in the local cache of the remote node.

Referring now toFIG. 6, an embodiment of the invention helps to ensure that if a node becomes disconnected from the network, or misses a cache item invalidation, that failure will be detected and can be resolved. The steps illustrated inFIG. 6are performed on a regular basis by each node.

At step602, the node determines whether a previously set countdown timer of a predetermined length has expired, looping if the timer has not expired.

At step604, when the countdown timer has expired, the node sends a request to cache manager104for a read lock of the named cache and the most current timestamp in the lock table.

At step606, cache manager104receives the request for a read lock, and read locks the named cache.

At step608, cache manager104gets the most current timestamp in the lock table.

At step610, cache manager104sends the timestamp and an indication that the named cache is read locked to the requesting node.

At step612, the node receives the indication that the named cache is read locked along with the timestamp.

At step614, the node compares the timestamp received from the cache manager with the timestamp from the previous check.

At step616, the node determines whether a timestamp is missing.

If, at step616, the node determines that no timestamp is missing, then at step618, the node stores the timestamp, received at step612as the timestamp of the last check.

At step620, the node sends a message to the cache manager releasing the read lock of the named cache.

At step622, in response to the message releasing the read lock of the named cache, cache manager104releases the read lock of the named cache and ends, or loops by re-starting the count-down timer that is monitored at step602.

If at step616, the node determines that a timestamp is missing, then at step624, the node sends a request to master locking database110for an update of the named cache.

At steps626,628, master locking database110receives the request for an update of the named cache and sends the update to the node.

At step630, the node receives the requested update and updates the named cache.

At steps632through636, the node stores the timestamp and releases the read lock of the named cache, just as described with reference to steps618through622.

Referring now toFIG. 7, an embodiment of the invention reorders some of the previously described steps and deletes some of the steps.

At step702, local node102determines that a cache element in a named cache requires modification. The need for modification may include the need for an update, or a data change.

At step704, local node102sends the update of the cache item in the named cache to master locking database110.

At step706, master locking database110receives the update and performs the update to cache item of the named cache in the master locking database.

At step708, master locking database110commits the update of the cache item to the named cache of the master database.

At step710, local node102acquires a local write lock of the named cache. Although called a write lock, the write lock includes a read lock of the named cache.

At step712, local node102sends a timestamp to cache manager104for use in an update of the lock table.

At step714, cache manager104receives the timestamp, and at step716cache manager104updates the lock table with the timestamp from local node102.

After sending the timestamp at step712, then at step718, local node102invalidates the cache item of the named cache that is held by local node102.

At step720, after invalidating the cache item, local node102releases the write lock of the named cache.

At step722, local node102broadcasts an invalidation message to all remote nodes106, identifying the cache item of the named cache.

At step724, each remote node106receives the broadcast invalidation message, identifying the cache item of the named cache.

At step726, each remote node106acquires a local write lock of the named cache in their own remote node.

At step728, each remote node106invalidates the cache item of the named cache in their own remote node.

At step730, after invalidating the cache item of the named cache in their own remote node, each remote node106sends an acknowledgment (ack) message to local node102.

At step732, each remote node106releases the local write lock of the named cache in the remote node.

At steps734and736, after broadcasting the invalidation message at step722, local node102waits for acknowledgment from each of the remote nodes106.

The process is complete once all of the remote nodes have acknowledged the invalidation message.

Although illustrative embodiments have been described herein in detail, it should be noted and will be appreciated by those skilled in the art that numerous variations may be made within the scope of this invention without departing from the principle of this invention and without sacrificing its chief advantages.

Unless otherwise specifically stated, the terms and expressions have been used herein as terms of description and not terms of limitation. There is no intention to use the terms or expressions to exclude any equivalents of features shown and described or portions thereof and this invention should be defined in accordance with the claims that follow.