Exactly one cache framework

Details Exactly one cache framework Exactly one cache framework

2002-09-04

2004-11-30

Ellis, Kevin L. (Department: 2188)

Electrical computers and digital processing systems: multicomput

Remote data accessing

Reexamination Certificate

active

06826601

ABSTRACT:

COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
CROSS-REFERENCED CASES
The following U.S. Patent Applications are cross-referenced and incorporated herein by reference:
U.S. patent application No. 60/305,986 entitled “DATA REPLICATION PROTOCOL,” by Dean Bernard Jacobs, Reto Kramer, and Ananthan Bala Srinivasan, filed Jul. 16, 2001.
U.S. patent application entitled “EXACTLY ONCE JMS COMMUNICATION” by Dean Bernard Jacobs and Eric Halpern, filed concurrently herewith.
TECHNICAL FIELD
The present invention is related to technology for distributing objects among servers in a network cluster.
BACKGROUND
In distributed computer systems, it is often the case that several servers and/or networking nodes need to work together. These servers and nodes have to be coordinated, as there is typically networking information that needs to be shared among the machines in order to allow them to function as a single entity. Typical approaches to machine coordination can be very expensive in terms of resources and efficiency.
In general some synchronization required for the nodes to agree, as there may be several messages passing between the nodes. This requirement for synchronization may, however, be undesirable in a clustered networking environment. Many clustered environments simply avoid imposing any such synchronization requirement. There are applications, however, where agreement is necessary.
In one case where agreement is needed, a device can exist to which a cluster may want exclusive access. One such device is a transaction log on a file system. Whenever a transaction is in progress, there are certain objects that need to be saved in a persistent way, such that if a failure occurs those persistently-saved objects can be recovered.
For these objects that need to be saved in one place, there is typically a transaction monitor that runs on each server in that cluster or domain, which then uses a local file system to access the object. Each server can have its own transaction manager such that there is little to no problem with persistence. There is then also no need for coordination, as each server has its own transaction manager.
For example, there can be a cluster including three servers, each server having a transaction manager. One of those servers can experience a failure or other problem causing the server to be unavailable to the cluster. Because the failed server is the only server having access to a particular transaction log, none of the transactions in that particular log can be recovered until the server is again available to the cluster. Recovery of the log can be difficult or at least inefficient, as a problem with the server can take a significant amount of time to fix. Significant server problems can include such occurrences as the shorting out of a motherboard on the server or a power supply being burnt out.
BRIEF SUMMARY
The present invention includes a system for managing objects, such as can be stored in servers on a network or in a cluster. The system includes a data source, application, or service, such as a file system or Java Message Service component, which can be located inside or outside of a cluster. The system can include several servers in communication with the file system or application, such as through a high-speed network connection.
The system includes a lead server, such as can be agreed upon by the other servers. The lead server can be contained in a hardware cluster or in a software cluster. The system can include an algorithm for selecting a lead server from among the servers, such as an algorithm built into a hardware cluster machine. The lead server in turn will contain a distributed consensus algorithm for selecting a host server, such as a Paxos algorithm. The algorithm used for selecting the lead server can be different from, or the same as, the algorithm used to select the host server.
The host server can contain a copy of the item or object, such as can be stored in local cache. The host server can provide local copy access to any server on the network or in a cluster. The host server can also provide the only access point to an object stored in a file system, or the only access point to an application or service. Any change made to an item cached, hosted, or owned by the host server can also be updated in the file system, application, or service.
If the host server becomes unable to host the object, a new host can be chosen using a distributed consensus algorithm. The new host can then pull the necessary data for the object from the file system or service. The other servers in the cluster can be notified that a new server is hosting the object. The servers can be notified by any appropriate means, such as by point-to-point connections or by multicasting.


REFERENCES:
patent: 5212793 (1993-05-01), Donica et al.
patent: 5249290 (1993-09-01), Heizer
patent: 5612865 (1997-03-01), Dasgupta
patent: 5761507 (1998-06-01), Govett
patent: 5768504 (1998-06-01), Kells et al.
patent: 5774689 (1998-06-01), Curtis et al.
patent: 5802291 (1998-09-01), Balick et al.
patent: 5819107 (1998-10-01), Lichtman et al.
patent: 5910180 (1999-06-01), Flory et al.
patent: 5926775 (1999-07-01), Brumley et al.
patent: 5991804 (1999-11-01), Bolosky
patent: 6055243 (2000-04-01), Vincent et al.
patent: 6067477 (2000-05-01), Wewalaarachchi et al.
patent: 6173327 (2001-01-01), De Borst et al.
patent: 6189046 (2001-02-01), Moore et al.
patent: 6212556 (2001-04-01), Arunachalam
patent: 6243753 (2001-06-01), Machin et al.
patent: 6269373 (2001-07-01), Apte et al.
patent: 6338089 (2002-01-01), Quinlan
patent: 6343287 (2002-01-01), Kumar et al.
patent: 6393459 (2002-05-01), Lurndal
patent: 6411956 (2002-06-01), Ng
patent: 6453356 (2002-09-01), Sheard et al.
patent: 6466972 (2002-10-01), Paul et al.
patent: 6484204 (2002-11-01), Rabinovich
patent: 6490610 (2002-12-01), Rizvi et al.
patent: 6542845 (2003-04-01), Grucci et al.
patent: 6687848 (2004-02-01), Najmi
patent: 2002/0116474 (2002-08-01), Copeland et al.
patent: 2002/0147652 (2002-10-01), Gheith et al.
patent: 2003/0018732 (2003-01-01), Jacobs et al.
patent: 2003/0046442 (2003-03-01), Maryka et al.
patent: 2003/0065708 (2003-04-01), Jacobs et al.
Nishio et al., “A Time-Out Based Resilient Token Transfer Algorithm For Mutual Exclusion in Computer Networks”, IEEE, 1989 P386-393.*
U.S. patent application Ser. No. 09/975,590, Jacobs et al., filed Jul. 16, 2001.
U.S. patent application Ser. No. 10/234,597, Jacobs et al., filed Sep. 4, 2002.

Affiliated with

Also associated with

Rating

Exactly one cache framework does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Exactly one cache framework, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Exactly one cache framework will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3352449