Browse Prior Art Database

Bind on Group Disclosure Number: IPCOM000081902D
Original Publication Date: 2005-Feb-28
Included in the Prior Art Database: 2005-Feb-28
Document File: 2 page(s) / 40K

Publishing Venue



This article describes a method whereby applications can take advantage of workload management and high availability offered by clustered systems for groups of messages. It overcomes some limitations of existing clustering implementations by routing new groups of messages to new instances of the destination. While it does this it constrains the routing of messages within a group to a single instance of the destination.

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

Page 1 of 2

Bind on Group

Applications can use message groups to logically link a set of messages together. This might be because the amount of data in the group is too large to be handled as a single message, or because the parts of the group are created over an extended period of time. The consumer of such a group usually wishes to know that it is complete and that all of it is available to be processed. For clustered messaging systems this implies that all of the messages comprising the group are sent to the same instance of the destination. It is usually helpful to the recipient if they can be sure the messages will arrive in creation order, or failing that close to creation order, since the receiving application will often wish to reconstruct state from the contents of the group by processing them in their creation order.

    The method used here is to allow the application to require the group of messages to be bound to a single instance of the destination. A new destination can be chosen for each new group started, but new messages for incomplete groups must be sent to the same instance of the destination that previous messages in the group were sent to.

    For example, IBM* WebSphere* MQ clustering currently supports two bind options, BIND_NOT_FIXED and BIND_ON_OPEN. These allow the messaging system administrator or application writer to control when a new destination (queue) and route to that destination (Channel) chosen. Using BIND_ON_OPEN selects a destination and route when the queue is first accessed by opening it, all messages PUT with the queue handle obtained flow to the same queue along the same channel. Using BIND_NOT_FIXED selects a destination and route for each messages as it is produced by the application. In this mode, messages from the same producer, may be sent to different instances of the destination or along different channels.

    This disclosure allows the application writer or system administrator to select BIND_ON_GROUP, so that a producer uses the same route and destination instance until a new g...