Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Mechanism for the safe reconciliation of orphaned database message data within a Queue Sharing Group

IP.com Disclosure Number: IPCOM000020564D
Original Publication Date: 2003-Nov-27
Included in the Prior Art Database: 2003-Nov-27
Document File: 3 page(s) / 52K

Publishing Venue

IBM

Abstract

Some messages for shared queues within a Queue Sharing Group are stored in two separate and distinct locations - the shared message payload is stored in a database as Binary Large Object (BLOB) segments, and the shared message identifying headers are stored in a Coupling Facility (CF). These messages are accessed solely by the tracking data held in the CF. Due to timing errors, or system errors, a problem arises when message payload data resides in the database, but has no tracking placeholder held in the CF. A SAFE mechanism is thus required to reconcile (purge) the orphaned message payload data residing in the database.

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

Page 1 of 3

Mechanism for the safe reconciliation of orphaned database message data within a Queue Sharing Group

Disclosed is a mechanism for the safe reconciliation of obsolete (or orphaned) message data held within a database eg an IBM* DB2* database, for Shared Queues. Timing techniques, and data versioning techniques, are used to ensure that live in-flight message data is NOT inadvertently purged. Furthermore, tracking data is created and monitored within the database so that this mechanism is evenly executed across a number of disparate execution queue managers within the execution group.

    Some messages for shared queues within a Queue Sharing Group are tracked (stored) in 2 separate and distinct locations - the shared message payload is stored in a database as BLOB segments, and the shared message identifying headers (containing tracking information) are stored in a Coupling Facility. These messages are utilised by multiple queue managers within a queue sharing group, and are accessed solely by the tracking data held in the CF.

    Due to timing errors, or system errors, a problem arises when message payload data resides in the database, but has no tracking placeholder held in the CF. A SAFE mechanism is thus required to reconcile (purge) the orphaned message payload data residing in the database.

    The problem is exacerbated by the fact that such a condition (orphaned data held in the database) is always a NATURAL condition for shared messages within the queue sharing group, because for any such message, the payload data is ALWAYS written to the database FIRST, and the tracking information written to the CF last of all.

    The reconciliation mechanism must thus distinguish between orphaned message data where the CF placeholder is permanently lost, and orphaned message data which is the result of a transient condition (the latter must NOT be purged).

    A solution of simply just deleting unreferenced data in the database is not sufficient due to operating factors (see next section).

The reconciliation mechanism must be aware of various operating factors:-
a) transient conditions It is quite valid, at any given point in time, for unreferenced message data to reside in the database and yet have no associated tracking data held in the CF. The solution (detailed in the next section) uses both time delay and pending/commit/rollback deletion techniques to cope with these transient conditions (and thus avoiding the deletion of real active message data).
b) multiple queue manager environment, and timing considerations A queue sharing group consists of multiple queue managers which may (or may not) be executing concurrently. The reconciliation mechanism must therefore be processed at the queue manager level ie. within EACH queue manager. Because of this, and to avoid the reconciliation mechanism from being performed by queue managers too frequently, or concurrently, the proposed solution stores reconciliation tracking data in the database in a common area tha...