Browse Prior Art Database

Strict Read Order Control for a Queing System Disclosure Number: IPCOM000015719D
Original Publication Date: 2002-Mar-15
Included in the Prior Art Database: 2003-Jun-21
Document File: 4 page(s) / 52K

Publishing Venue




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

Page 1 of 4

Strict Read Order Control for a Queing System


     There are various possible definitions of 'correct order' in a queing system, in particular PUT time ordering and PREPARE time ordering. For some applications this ordering is critical, for others it is not.

     This disclosure proposes user control (by application or by queue definition) of whether ordering should be respected at read time. It can apply whatever ordering rule is specified.

     This has several benefits: An application that is order sensitive can retrieve messages in the defined order. An application that is not order sensitive can give the system the chance to optimize processing.

     An application may easily implement a reliable queue browser that does not miss or repeat messages.


     A messaging product such as IBM's MQSeries* defines that messages will be retrieved in PUT time ordering. However, a message cannot be seen by a reading application until it has been committed. Thus supposing two applications A and B operate as follows:

A puts A1







B puts B1

A puts A2

A commits

B puts B2

B commits

     A laid back reader, that does not start reading until the entire write sequence is complete, will see messages in the order A1, B1, A2, B2. An eager reader (with high priority that always has a get with wait outstanding on the queue), will see messages in the order A1, A2, B1, B2. It is almost impossible to code in such a way that either of these order is assured.

     A laid back browser will see messages in the order A1, B1, A2, B2. It is almost impossible to code in such a way that this is assured. An eager browser will see messages in the order A1, A2, B2. It will miss message B1 unless it rebrowses from the start of the queue (in which case it will revisit all the other messages).

     This does not permit applications to retrieve from queues in an assured order. It also puts sufficient constraint on the queue manager that it limits the queue manager's performance options.

PREPARE time ordering

     Pending patent application with the internal reference GB920010082 proposes mechanisms for PREPARE time ordering (A1, A2, B1, B2). However, this requires that for queues where such an ordering is defined it must be observed by the reader or broswer. This does not permit performance optimization for non-critical readers and browsers.


Page 2 of 4


     This invention assumes that (for at least some queues) there is a well defined 'correct' order. This correct order may be PUT time ordering, PREPARE time ordering, or some other well specified ordering. It need not be the same for all queues: some queues may be defined as PUT time ordered, and others on the same queue manager as PREPARE time ordered. Usually, the ordering will be defined by queue attributes as either PUT time or PREPARE time.

     The invention states that there be GET/BROWSE control of whether or not messages must be read in a pre-defined order. This may be controlled by queue attribute, by application prog...