Cloned and shared subscriptions
In IBM MQ Version 8.0 or later, there are two methods for giving multiple consumers access to the same subscription. These two methods are by using cloned subscriptions, or by using shared subscriptions.
Cloned subscriptions
Cloned subscription is an IBM MQ extension. Cloned subscriptions enable multiple consumers in different Java virtual machines (JVMs) concurrent access to the subscription. This behavior can be used by setting the CLONESUPP property to Enabled on a connectionFactory object. By default CLONESUPP is Disabled. Cloned subscriptions can be enabled only on durable subscriptions. If CLONESUPP is enabled, each subsequent connection that is made by using this connectionFactory is cloned.
A durable subscription can be considered cloned if one or more consumers are created to receive messages from that subscription, that is, they were created specifying the same subscription name. This can be done only if the connection under which the consumers were created has CLONESUPP set to Enabled on the MQConnectionFactory. When a message is published on the subscription's topic, a copy of that message is sent to the subscription. The message is available to any of the consumers, but only one receives it.
Note: Enabling cloned subscriptions extends the JMS specification.Shared subscriptions
The JMS 2.0 specification introduces shared subscriptions, which allows messages from a topic subscription to be shared among multiple consumers. Each message from the subscription is delivered to only one of the consumers on that subscription. Shared subscriptions are enabled by the relevant call to the JMS 2.0 API.
The APIs can be called in either of the following ways:- From a Java SE application (or Java EE Client Container).
- From a servlet or the implementation of an MDB.
If a shared subscription is enabled, then it cannot be unshared.
Shared subscriptions can be created as either durable or non-durable subscriptions. There is no requirement to separately create any objects on the queue manager side beyond the normal JMS configuration, any objects that are required are created dynamically.
Deciding between shared or cloned subscriptions
When you are determining whether to use shared or cloned subscriptions, consider the benefits of both. Where possible use shared subscriptions as it is specification defined behavior, rather than an IBM MQ specific extension.
The following table contains some of the points to consider when you are deciding between shared and cloned subscriptions:| Shared Subscriptions | Cloned Subscriptions |
|---|---|
| Shared subscriptions are a standard part of the JMS 2.0 specification. | Cloned subscriptions are an IBM MQ specific extension. |
| Shared subscriptions are created by using explicit API method calls. | Cloned subscriptions are controlled administratively at the ConnectionFactory level. |
| Shared subscriptions can be durable or nondurable. | Cloned subscriptions can only be durable. |
| Shared subscriptions are explicitly created on an individual subscription basis. | Cloned subscriptions are used for any durable subscription under a connection for which the function is enabled. |
| If a subscription is created as shared it cannot later be changed to unshared, or vice versa. | A subscription can be changed from cloned to uncloned each time it is reopened if the CLONESUPP property of the owning connection has changed. |
Attempts to alter the sharability of an existing subscription
If a subscription is created as shared it cannot later be changed to unshared, or vice versa.
From IBM MQ Version 9.0.0, Fix Pack 1, the IBM MQ queue manager has been updated so that if a JMS 2.0 application creates a durable unshared subscription, and another non JMS 2.0 application then tries to resume the subscription, the following reason code is returned:2432 (MQRC_SUB_ALREADY_EXISTS