Browse Prior Art Database

A method of sharing a message store amongst multiple messaging engines without using shared storage

IP.com Disclosure Number: IPCOM000191855D
Original Publication Date: 2010-Jan-18
Included in the Prior Art Database: 2010-Jan-18
Document File: 3 page(s) / 51K

Publishing Venue

IBM

Abstract

Disclosed is a system such that multiple messaging engines can appear (to applications) to "share" a message store (e.g. a message queue) without having shared storage. The system works by passing messages between the messaging engines in order to co-ordinate the storage and retrieval of messages on the "shared" message store.

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

Page 1 of 3

A method of sharing a message store amongst multiple messaging engines without using shared storage

Messaging engines can never be 100% reliable: hardware and software can fail. There are a large number of different techniques that can be employed to combat this,for example:
(i) WebSphere MQ on z/OS* has the concept of a "Queue Sharing Group"; multiple queue managers can put and get messages from a "shared queue" (stored on special hardware called a coupling facility). If one queue manager is no longer available, applications can connect to a different queue manager and retrieve messages on a shared queue that were placed there by the original queue manager.
(ii) WebSphere MQ has an "high availability" feature so that if two queue managers share a disk, when the first fails, the second queue manager starts up and can access messages put by the first queue manager.

    Both these examples of sharing a message store involve some shared storage. This means that the sharing can be fast - only one copy of the message is written to the shared storage and all the messaging engines can access it. It also introduces a single point of failure - if the shared storage fails, no messaging engine can access the message. This means that expensive, highly-reliable storage must be used.

    Some techniques, (including (ii) above) are active/passive systems which means that "backup" hardware is usually unused, waiting for fail-over from the primary system.

    This disclosure outlines a method of emulating a shared message store by each messaging engine maintaining their own copy of the message store and keeping them synchronised via exchanging messages amongst themselves.

    The method outlined has (compared to solutions involving shared storage) a high performance overhead and involves the complexity of transactions distributed across multiple machines however for some scenarios , the method outlined here would be sufficient without requiring expensive hardware.

    Such a system could be employed in situations where very few shared messages are sent (though as all the message engines are active, many non-shared messages can occur).

    A hypothetical example where this might apply is a factory line. Each step in the production line is automated and the machine performing each step runs a client that connects to a messaging engine. Almost no messages flow between the machines but if one machine has a problem, all machines must stop within a set period of time of the line will be damaged incurring very large expense. If all the clients were connected to a single message engine, if that message engine were to fail then communication would cease. Instead the clients can connect to a group of message engines and if one fails then the clients can reconnect to other engines and continue communication unaffected.

    Each messaging engine that will have access to the "shared" message store creates their own (locally-stored) message store. In...