Cloned and shared subscriptions

In IBM® MQ 8.0, 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 8.0 provides the sharedSubscription activation specification property for this purpose. For more information about this property, see Configuring 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 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® extension.

The following table contains some of the issues to consider when you are deciding between shared and cloned subscriptions:

Table 1. Considerations when you are choosing between shared subscriptions 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.