Developing Advanced PubSub Applications 13-5
13.2.2.2 How a Non-durable Subscription is Closed
After all subscribers that share the same subscription close, the subscription is cleaned up. Specifically, when the last subscriber consumer on a shared subscription calls
close, the subscription and all the associated JMS resources cleaned up.
There is no runtime mbean that represents a non-durable subscription, regardless of whether it is a shared or exclusive subscription. It is possible to monitor individual
susbcribers using the appropriate JMSConsumerRuntimeMBean.
13.2.3 How Sharing a Durable Subscription Works
In previous releases, the subscription key ClientID, SubscriptionName uniquely identified a subscription within a cluster where the subscription could only
exist on a single destination instance or a single member of a DT within the cluster. In this WebLogic Server release, the subscription key becomes ClientID,
ClientIDPolicy, SubscriptionName. All durable subscribers that use the same subscription key share the same subscription if they subscribe to a regular topic,
or if they subscribe to the same member of a distributed topic. Multiple subscriptions that use the same subscription key can exist on multiple distributed destination
member destinations.
The first subscriber that is created with a particular subscription key creates the subscription. All subsequently created subscribers with the same subscription key
share the subscription created by the first subscriber if all subscription details such as: the selector, noLocal option, and the physical destination match and they are on the
same physical destination.
If a subscription is created with a selector and the noLocal option, a subscriber created on the same physical destination using the same subscription key with a
different selector and noLocal option will:
■
Replace the existing durable subscription and cleanup all pending messages that are saved for the durable subscription if there are no active subscribers using this
existing subscription.
■
Throw InvalidSubscriptionSharingException if there are active subscribers using the same subscription key with a different selector or noLocal
option.
13.2.3.1 How a Shared Subscription Policy for a Durable Subscription is Determined
The Subscription Sharing Policy for a particular durable subscription is dynamically determined by the first active subscriber on the subscription and does not change
unless all current subscribers close and new subscribers attach with a different policy. Any attempt to change the policy of a subscription that already has active subscribers
throws an InvalidSubscriptionSharingException. For example:
■
If a durable subscription has an EXCLUSIVE subscriber and the Subscription Sharing Policy is EXCLUSIVE, any attempt to create an additional subscribers on
the subscription throws InvalidSubscriptionSharingException, regardless of whether the yet-to-be-created subscriber is EXCLUSIVE or
SHARABLE.
■
If a durable subscription has active subscribers with a SHARABLE policy, the Subscription Sharing Policy is SHARABLE, any attempt to create a new
EXCLUSIVE subscriber on the subscription throws InvalidSubscriptionSharingException. Please note that changing
13-6 Programming JMS for Oracle WebLogic Server
Subscription Sharing Policy on an existing durable subscription does not delete any messages that already exist on the subscription.
13.2.3.2 How to Unsubscribe a Durable Subscription
Before unsubscribing a subscription, you must consider the Client ID Policy for the subscription:
■
Applications that use a Client ID Policy with a value of RESTRICTED unsubscribe a durable subscription using the standard Session.unsubscribeString
name API.
■
Application that use a Client ID Policy with a value of UNRESTRICTED unsubscribe a durable subscription using the
WLSession.unsubscribeString name, Topic topic extension by supplying the subscription name and the topic or a DT member object.
13.2.3.3 Considerations when Unsubscribing a Durable Subscriber
The following section provides information on how to unsubscribe or avoid scenarios that throw an exception:
■
If there are active consumers on the subscription, a call to unsubscribe throws a JMSException.
■
If there are no active consumers, on a subscription, a call to unsubscribe deletes the matching durable subscription identified by the subscription key
ClientID, ClientIDPolicy, SubscriptionName.
■
unsubscribe of a durable subscription is done per standalone topic or per member of a DT.
■
A subscription created using a connection with a RESTRICTED Client ID can only be cleaned up from a connection that uses the same RESTRICTED Client ID.
■
A subscription created using a connection with an UNRESTRICTED Client ID can only be cleaned up from a connection using the same UNRESTRICTED Client ID.
■
If WebLogic JMS does not find a matching subscription on the topic that was created with the same Client ID and ClientIDPolicy as the unsubscribe call, an
InvalidDestinationException is thrown.
■
If an unsubscribe call with an UNRESTRICTED Client ID specifies a DT or does not specify any Topic, an InvalidDestinationException is thrown.
■
Although .Net and C API messaging applications can share subscriptions by using the Client ID Policy and Subscription Sharing Policy on a connection factory
deployed on WebLogic Server 10.3.4.0 or later, an unsubscribe API extension is not yet available for subscriptions that use an Unrestricted Client ID. The workaround
Note: Changing the Subscription Sharing Policy on an existing
durable subscription does not delete any messages that already exist on the subscription.
Note:
Prior to WebLogic Server 10.3.4.0, all Client ids are RESTRICTED by default. A given client id could only be used by one
connection at any given time in a WLS JMS cluster.
Developing Advanced PubSub Applications 13-7
is to use administrative measures described in Section 13.2.3.4, Managing Durable
Subscriptions.
13.2.3.4 Managing Durable Subscriptions
