InfoSphere Replication Server, usually called Q Replication or Q Rep, enables greater data availability for critical applications. It replicates data between source and target tables based on rules that the DBA and applications enable. Using a process called Q Capture on the source side, Q Replication reads the DB2 log for committed DB2 updates and uses WebSphere MQ to transmit them to the target. On the target side, the Q Apply process reads the queue and applies the same updates to the local replica. Q Rep is able to handle a high volume of transactions, as messages, between the source and target databases, or subsystems. There is some latency between the database replicas, but it is typically very small. To rebuild each transaction, it is critical that the messages that represent it are received and applied in the correct sequence (serialized application).
If a message cannot be delivered because, for example, the target queue is full, WebSphere MQ routes it to a dead-letter queue, if one is available. This can cause problems for the Q Apply program because messages can arrive on the target queue out of sequence. If this occurs the replication process is stopped until the problem can be addressed by an administrator.
To avoid this situation, the preferred WebSphere MQ environment for replication, and other applications that require messages to be processed in a strict sequence, has been not to define a dead-letter queue. This prevents messages being routed elsewhere, which preserves their sequence. An administrator only has to restart the channel once the problem has been resolved.
Our service organization supports several other applications that require a dead-letter queue. Before WebSphere MQ V7.1, the dead-letter queue was a global setting for all channels defined on a queue manager. Therefore, applications that require a dead-letter queue could not share a queue manager with applications such as Q Replication. Naturally, not being able to share a queue manager makes the support cost of these applications more expensive. With WebSphere MQ V7.1, each channel can be configured to use the dead-letter queue, or not, independently. We are planning to migrate our WebSphere MQ infrastructure to V7.1 to take advantage of this feature, and many other important enhancements, that will help us to meet several requirements from our customers and lower the service cost.
I recently participated in a project with a team of WebSphere MQ experts from IBM to write the IBM Redbooks publication IBM WebSphere MQ V7.1 and V7.5 Features and Enhancements. The book will help you understand the benefits of upgrading to WebSphere MQ V7.1 and V7.5 and how to implement the new functions.
Other blog posts from the team:
Introducing coexistence support for WebSphere MQ on Windows, UNIX, and Linuxby Jamie Squibb
WebSphere MQ v7.1 SMDS: What goes up will come downby Carolyn Elkins
Improving z/OS WebSphere MQ availability: Structure failure or connectivity loss?by Barry Dearfield
Likes before 03/04/2016 - 1
Views before 03/04/2016 - 4547