Browse Prior Art Database

A Method for Detecting/Resolving Contention within Catalog Processing

IP.com Disclosure Number: IPCOM000198604D
Publication Date: 2010-Aug-10
Document File: 3 page(s) / 42K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a means of identifying Catalog Address Space tasks which have been halted and, as a result, block other tasks from using the space. The method described senses the contention condition, determines whether the condition warrants action, and executes an action which is intended to mitigate an evolving contention issue.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3

A Method for Detecting/Resolving Contention within Catalog Processing

Today, Catalog uses system resources to serialize critical activities. Tasks other than Catalog and/or other Catalog tasks also use these resources. The possibility exists that while Catalog service tasks are waiting on an event, the event may not finish or complete. It could take the event an unreasonably long time to return, leaving the Catalog Address Space (CAS) service task waiting -- possibly indefinitely.

The system administrators do not usually become aware of the situation until it is a significant problem; they attempt to diagnose the problem using tools like Global Resource Serialization (GRS). It is rarely an easy or pleasant situation, and often results in service engagements with Level 2. Currently, GRS and other tools are useful in identifying the cause of the problems post-mortem, but rarely do these tools identify an evolving problem or act to mitigate the problem. In order to respond appropriately, the code or person detecting the problem needs specialized information about how the resource is currently being used. Given this last statement, only Catalog is in a position to act appropriately or recommend an appropriate action associated with diminished Catalog behavior due to resource contention.

This proposed design is a means of identifying those CAS tasks which seem to be halted while waiting on an event. When the system identifies these tasks as having passed a threshold, in all cases, it creates a record/notification. The system designates some CAS tasks as reasonably safe to terminate and once they have passed the threshold wait time terminates them, freeing them for more work. The solution senses the contention condition, determines whether the condition warrants action, and executes an action which is intended to mitigate an evolving contention issue. The first step, sensing, need not be a Catalog function. The second step, determining action threshold, and possibly the third step, execution/action, might require Catalog-specific knowledge or capabilities in order to analyze or act. The current solution addresses the need for Catalog-specific intelligence in order for the system to automate and quickly react.

Catalog Contention detection provides a three-part mechanism for Catalog autonomic behavior:

1. Catalog must self-monitor or sense important data associated with healthy Catalog operation. Specifically for this disclosure, Catalog is monitoring contention for Catalog required resources.

2. Catalog must either programmatically or through user preferences set thresholds or tolerances related to specific self-monitoring events. In the case of critical resources, the threshold is the amount of time Catalog should wait for the resource before taking an action.

3. The system executes a set of programmed actions or user preferences in an attempt to resolve the issue which is now beyond threshold. Specifically when related to resources, th...