Impact calculation for version management in a distributed information service

• US 4,714,996 A
• Filed: 11/26/1985
• Issued: 12/22/1987
• Est. Priority Date: 11/26/1985
• Status: Expired due to Term

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Gladney, Henry M., Mattson, Richard L., Lorch, Douglas J.
• Primary Examiner(s): Zache, Raulfe B.
• Application Number:
  US06/801,896
• Time in Patent Office: 756 Days
• Field of Search: 364/200 MS File, 364/300
• US Class Current: 1/1
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: G06F 16/275 Synchronous replication
• CPC Class Codes: G06F 2216/09 Obsolescence
• CPC Class Codes: H04L 69/00 Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass networks security protocols H04L9/40; wireless communication networks H04W
• CPC Class Codes: Y10S 707/99954 Version management

Abstract

In a distributed processing system having a source node accessing data objects from a database and a replica node storing replicas of requested source data objects received from the source location, the impact to replicas caused by a change in a source data object is calculated by assigning a version number to the change. An identifier of the portion of the source database affected by the change is generated, as well as a list of replicas containing objects from the affected portion of the database. For a replica location communicating with the source location, a table of the replicas from the list is then recorded along with the version number for communicating to the replica location.

Claims

1. In a system for managing obsolescence of replicas of data objects, the objects being utilized in multiple nodes of a distributed processing system having at least one node operating as a source location having access to a source database containing data objects and at least one node operating as an object replica location having means for storing replicas of requested data objects received from a source location, each source data object being alterable whereby a change in a source data object will cause an impact to its replicas, a method for calculating the impact of a change to a source data object within the system, comprising the steps at the source location of:

(a) responsive to the change in the source data object, assigning a version number to the change and generating an identifier of a portion of the source database affected by the change;

(b) responsive to said identifier, generating a list of replicas including objects from the affected portion of the source database; and

(c) for a replica location in communication with the source location, recording a bad messages table of replicas in the list along with the version number assigned to the change for communication to the replica location.

2. The method of claim 1, wherein said step of generating a list of replicas formed from the affected portion of the source database includes the steps of:

(a) maintaining for replicas supplied to replica locations a where used list of identifiers of portions of the source database used to form respective ones of said replicas; and

(b) extracting the list of replicas including objects from the affected portion of the source database from the where used list.

3. The method of claim 1, wherein the version number is assigned as a function of a timestamp.

4. The method of claim 1, further including the steps of:

(a) maintaining a list of replica locations in communication with the source location; and

(b) wherein the step of recording a bad messages table is repeated for each replica location in the list of replica locations.

5. The method of claim 1, wherein said identifier is a hash code based on a request identifying portions of the source database intended to be used in generating a replica.

6. The method of claim 1, wherein said identifier includes at least a portion of a request identifying portions of the source database intended to be used in generating a replica.

7. In a system for managing obsolescence of replicas of data objects, the objects being utilized in multiple nodes of a distributed processing system having at least one node operating as a source location having access to a source database containing data objects and at least one node operating as an object replica location having means for storing replicas of requested data objects received from a source location, each source data object being alterable whereby a change in a source data object will cause an impact to its replicas, a method for calculating the impact of a change to a source data object within the system, comprising the steps at the source location of:

(a) maintaining a list of replica locations in the system;

(b) responsive to the change in the source data object, assigning a version number to the change, generating a set of identifiers of portions of the source database affected by the change and entering the version number and set of identifiers in a change table.

(c) maintaining a where used table listing replicas supplied to replica locations and sets of identifiers of portions of the source database including objects used to form said replicas listed in the where used table;

(d) joining the change table and where used table to generate a work table keyed by the version number associated with the change of replicas for those identifiers in the where used table that also occur in the change table; and

(e) generating a bad message table associating the replica locations in the list of replica locations with entries in said work table generated in step (d).

8. The method of claim 7, further including the step of:

(a) responsive to several changes in the source database that are indicated to take effect as an atomic transaction, associating an identical version number with each of the several changes and respective entries in said bad messages table generated in step (e) of claim 7.

9. The method of claim 7 or 8, further including the step of:

(a) deleting from said change table identifiers of portions of the source database successfully processed to create entries in the bad messages table.

10. The method of claim 7, further including after the step of joining the change table and the where used table the step of:

(a) deleting any duplicate entries in said work table generated in step (d) of claim 7.

11. The method of claim 7, further including after the step of joining the change table and the where used table the steps of:

(a) generating a new version of each replica in said work table generated in step (d) of claim 7 that includes the change indicated by the version number associated with the replica;

(b) generating an old version of each replica in said work table that excludes the change indicated by the version number associated with the replica; and

(c) deleting replicas from said work table if the old version and the new version of such replicas are identical.

12. The method of claim 11, further including, prior to the deleting step (c), the steps of:

(a) for each version number in the bad messages table indicating a change to take effect in a future time, generating a future version including said change in said future time of each replica in the work table; and

(b) adding an entry to the bad messages table associating the version number indicating the change to take effect in said future time with replicas in the work table if the future version differs from the new version generated in step (a) of claim 11.

13. The method of claim 11, further including prior to the step of deleting the steps of:

(a) generating a newer version of each replica in the work table that includes all changes up to and including changes associated with a version number indicating a future change, the version number indicating a future change being found in the bad messages table;

(b) adding the replica in question to the bad messages table together with the future change version number if the new version in step (a) of claim 11 differs with the new version generated in step (a).

14. The method of claim 7, wherein the version number is assigned as a function of a timestamp.

15. The method of claim 7, wherein an identifier is generated as a hash code based on a request identifying portions of the source database intended to be used in generating a replica.

16. The method of claim 7, wherein said identifier includes at least a portion of a request identifying portions of the source database intended to be used in generating a replica.