Browse Prior Art Database

Support CM Update Action of Creating, Modifying or Removing Objects with CM Replication Enabled

IP.com Disclosure Number: IPCOM000030763D
Original Publication Date: 2004-Aug-25
Included in the Prior Art Database: 2004-Aug-25
Document File: 4 page(s) / 57K

Publishing Venue

IBM

Abstract

Content Manager V8.2 includes the feature of Replication. Replication can help provide both disaster recovery and higher availability. Customers wish to employ replication to help solve both of these requirements. For disaster recovery, the every thing replicated, widely separated servers, describes a useful configuration. Replication is defined as making an asynchronous peer copy of a resource item’s referenced blob on a different resource manager/collection tuple.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 4

Support CM Update Action of Creating, Modifying or Removing Objects with CM Replication Enabled

Content Manager V8.2 includes the feature of Replication. Replication can help provide both disaster recovery and higher availability. Customers wish to employ replication to help solve both of these requirements. For disaster recovery, the every thing replicated, widely separated servers, describes a useful configuration. Replication is defined as making an asynchronous peer copy of a resource item's referenced blob on a different resource manager/collection tuple.

With replication enabled, OOAPI sends a request to the library server to get the primary resource manager for the stored object plus other resource managers where the object has to be replicated. Library server maintains the replica list for each resource item/object. So to delete an object from OOAPI, the object in all the resource managers where the object was replicated have to be deleted.To resolve this issue, we maintain all the resource manager, replica list and to-be-delete information in the library server tables and CM Asynchronous Recovery will clean up deleted object from all resource mangers based on to-be-delete information.

In Content Manager V8.1, the OOAPI had to deal directly with just a single resource manager when performing resource object store or replace. If an object were to be updated with no content (to remove the object from the resource manager), then OOAPI would delete that object from the resource manager directly. However, in Content Manager V8.2 object deletion is not a one-step process since there are multiple resource managers to deal with.

With the new approach, we have the advantage of maintaining data integrity. In other words, library server maintains the object status (created, updated, deleted) at different instances of time so that to delete multiple objects from different resource managers but for the same item can be resolved. For example,

Given one primary RM and two replica RMs. From timestamp TS1 to TS2, an object obj is created in the primary RM and replicated to Replica1. At timestamp TS2, the object objs updated asobj'. At timestamp TS3, in order to remove the object for this item, object obj in Primary RM and object obj' in Replica1 need to be deleted and they will be sent to to-be-delete table in Library Server for CM asynchronous recovery.

Timestamp Primary Resource

Manager

No object No object No object

Algorithm

The follow algorithm applies to any update actions like creating, updating, or removing an object at any time with replication enabled. Given the definition as follows: Content: There is an object with underlining itemID / versionID on this RM/Coll.

No Content(NC): There is no object with underlining itemID / versionID on this RM/Coll.

Waiting Replicator(WR): This RM/Coll is waiting for the replicator which has the latest copy of the object.

Stored RM: The first place to store this object

The rest of RMs: The RMs ex...