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.