This topic describes the consequences of applications that connect
to an existing cloned durable subscription, but specify parameters that differ
from those that were used to create the existing subscription.
When an application connects to an existing durable subscription, but specifies
parameters that differ from those that were used to create the existing subscription, the
subscription is deleted then recreated with the new parameters.
A durable subscription can be changed in this way only when it has no active
consumers. In the basic case, there is only one active consumer at any time,
so the application can change the durable subscription without affecting other
subscribers. However, the situation is more complicated for cloned subscriptions.
A cloned durable subscription has multiple active subscribers, which are
usually clones of a particular application.
- For cloned message-driven bean (MDB) applications, the subscribers are
always active on the subscription, and so the administrator must stop all
instances of the MDB application before the subscription can be altered. (If
the MDB application instances are recycled one at a time then each individual
instance is thrown out when it tries to connect using the changed properties,
because there are existing consumers.)
- For cloned EJB applications, administrators should ensure that all instances
of the EJB application are stopped before the subscription can be changed,
to avoid the following problem. Enterprise beans have active subscribers for
a durable subscription for relatively short spaces of time. If the EJB application
instances are recycled individually then there is a race period where the
enterprise bean with the new view of the world deletes and recreates the subscription,
then an old version of the enterprise bean returns the subscription to the
original state.