Browse Prior Art Database

Method to Control and Monitor Status of Objects on Multiple Resource Managers

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

Publishing Venue

IBM

Abstract

New to Content Manager Version 8.2 is replication. Replication is defined as making an asynchronous copy of an object from one resource manager/collection tuple to a different resource manager/collection tuple. Each resource manager/collection tuple may have defined from 0 to 128 unique resource manager/collection tuples that specify where replications are made. These definitions comprise the replica rules for a resource manager/collection tuple. This solution is to keep a status flag on the library server with the object and its resource manager/collection tuple. At any time, the status of an item’s object on any resource manager/collection tuple would be available. The status would indicate if the item actually had an object, if the item was in the process of being stored, if storing the item failed, and if the resource manager/collection tuple was waiting for the replicator. This solution would guarantee when the client attempts to retrieve an item, the client would know immediately which resource manger/collection tuple has an object. This would eliminate the need to query all the resource manager/collection tuples to see if they have an object. Also, keeping the status would guarantee that only those resource manager/collection tuples with up to date objects would be queried. There would be no risk of unknowingly retrieving an out of date object. Therefore, when a client requested the location of an object from the library server, the library server would be able to return the resource manager/collection tuple with the up to date object.

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

Page 1 of 4

Method to Control and Monitor Status of Objects on Multiple Resource Managers

Introduction

Content Manager is a system of organizing items. This system consists of 3 components: clients, resource managers, and a library server. Clients are the user interface to store and retrieve items . Some items may have an object, such as a document or image, associated with it. These objects are stored on a resource manager. Resource managers are divided into collections, so an object is more specifically stored on a resource manager /collection tuple. The library server is an index of all the items and all the objects that are stored on the resource managers/collection tuples.

New to Content Manager Version 8.2 is replication. Replication is defined as making an asynchronous copy of an object from one resource manager/collection tuple to a different resource manager/collection tuple. Each resource manager/collection tuple may have defined from 0 to 128 unique resource manager/collection tuples that specify where replications are made . These definitions comprise the replica rules for a resource manager /collection tuple.

The process for retrieving an item is the client sends a message to the resource manager to store an object on one of its collections. The client then sends a message to the library server that an object has been stored on the resource manager/collection tuple. When the user then wants to retrieve the object, the client sends a message to the library server requesting the location of the object. The library server returns a message to the client with the resource manager /collection tuple the requested item resides on. The client then sends a message to the identified resource manager to retrieve the object off its identified collection. Finally, the resource manager returns the requested object to the client .

The problem arises if the default resource manager/collection tuple for the item has replicas defined. Since replication is an asynchronous process, when an object is created and stored on a resource manager /collection tuple the replica resource manager/collection tuples will not have the object until the replicator runs and gives them their copy of the object . There is no way to know which resource managers/collection tuples have the object.

One solution would to modify the process for when a client requests the location of the object from the library server for the library server to return to the client the list of resource manager /collection tuples that could have the object. The client would then send a message to all the resource manager/collection tuples until one returned with the object .

The glaring problem with this solution is the time required in sending messages to the all the resource managers for an object, waiting for them to see if they have the object, and then return with whether or not they have the object . Also, even if they do return an object, there is no way for the resource manager to know...