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.
The JMS 2.0 specification does not define any standard way of driving an MDB from a sharedSubscription, so IBM MQ Version 8.0 or later provides the sharedSubscription activation specification property for this purpose. For more information about this property, see Configure the resource adapter for inbound communication and Examples of how to define the sharedSubscription property.
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 we 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 we are deciding between shared and cloned subscriptions:Parent topic: Use JMS 2.0 functionality
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.
Related reference
Related information