B Topic Subscription Identifiers

Examine how the topic subscription identifiers are generated.

In JMS, a subscription is identified and located based on the following:

  1. The topic with which the subscription is associated

  2. The connection "Client ID" string that is specified for the connection that is used to access the subscription

  3. If durable subscriptions are used, the subscription name. The subscription name is established by either of the following means:

    • When the durable subscription is created

    • By the SubscriptionName configuration property

    If the SubscriptionName property is provided, that property is used. Otherwise, the subscription name is generated when the subscription is created.

  4. The "Client ID Policy" option, by which a subscription is also identified in WebLogic JMS. If two WebLogic JMS subscription references on the same physical topic have the same client ID and subscription name, then the references resolve to:

    • A single subscription, if the client ID policies are also the same

    • Two different subscriptions, if the client ID policies are different

A WebLogic MDB container automatically generates items 1 through 4 in the preceding list, based on the following settings:

  • ejb-name

  • jms-client-id

  • topicMessagesDistributionMode

  • SubscriptionName configuration property

  • distributedDestinationConnection

  • generate-unique-client-id

  • subscriptionDurability

  • Other elements of the MDB deployment and JMS configurations

The last four settings, apply only to Compatibility mode MDBs.

Table B-1 summarizes how the settings are used to generate subscription IDs:

Table B-1 How Subscription IDs are Generated

Setting ClientID Subscription Name for the Durable Subscription Case Client ID Policy for WebLogic Topics

topicMessagesDistributionMode = One-Copy-Per-Application

jmsClientIDBase

SubscriptionName property, if used, or ejb-name

Unrestricted

topicMessagesDistributionMode = One-Copy-Per-Server

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ currentServerName

SubscriptionName property, if used, or ejb-name

Unrestricted

topicMessagesDistributionMode = Compatibility

generateUniqueClientID = true

distributedDestinationConnection = LocalOnly

subscriptionDurability = DurableFoot 1

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ uniqueKey

Same as the ClientId, or SubscriptionName property, if used

Restricted

Same as previous row, except:

distributedDestinationConnection = EveryMember

jmsClientIDBase

+ "_"

+ currentDomainName

+ "_"

+ uniqueKey

+ "_"

+ DDMemberName

Same as the ClientId, or SubscriptionName property, if used

Restricted

topicMessagesDistributionMode = Compatibility

generateUniqueClientID = false

subscriptionDurability = DurableFoot 1

jmsClientIDBase

Same as the ClientId, or SubscriptionName property, if used

Restricted

Footnote 1

Non-durable Compatibility mode MDBs do not set a Client-ID or Subscription-Name, and use the default Restricted Client ID Policy.

Key:
  • jms-client-id — an optional MDB attribute string set by the MDB descriptor or an annotation; alternatively (but rarely), the jms-client-id can be set by changing the MDB to reference a custom JMS connection factory that in turn has a client-id configured

  • SubscriptionName — an optional setting to establish the durable subscription name. If specified, this setting takes precedence over any automatically generated name.

  • ejb-name = the name of the EJB

  • jmsClientIDBasejms-client-id (if specified by user) or ejb-name (if jms-client-id is not specified)

  • currentDomainName — the name of the WebLogic domain that runs the MDB

  • currentServerName — the name of the Oracle WebLogic Server that the MDB is running on

  • uniqueKey — a string that contains some of the MDB deployment elements, possibly the currentServerName. If the destination is a WebLogic destination that is hosted by a JMS server that is using a migratable target, then this string includes the migratable target name.

  • DDMemberName — the name of a distributed destination member; or, alternatively, the destination name if the topic is a singleton or a distributed destination in releases of Oracle WebLogic Server prior to 10.3.4.

Client ID uniqueness is enforced as follows:

  • For foreign (non-WebLogic) JMS vendors: Some JMS vendors prevent more than one connection from specifying the same connection Client ID. (An exception is thrown on an attempt to create the second connection.) This limitation in turn can prevent more than one free pool from using the same Client ID, because each free pool creates a single JMS connection with potentially the same Client ID as other free pool connections. After a first free pool instance of the MDB starts on a server instance in the cluster, an additional instance of the EJB can deploy successfully on another clustered server; but when the MDB attempts to create a JMS connection, a Client ID conflict is detected and that instance of the MDB fails to fully connect to JMS.

  • For WebLogic JMS: For WebLogic JMS in releases of Oracle WebLogic Server prior to 10.3.4, JMS connections were restricted so only one connection with the same Client ID could exist in the scope of a cluster. However, for Oracle WebLogic Server 10.3.4 and later, WebLogic JMS connection factories or connections can optionally set a Client ID Policy to control this restriction. With a Client ID Policy of RESTRICTED, the pre-10.3.4 behavior remains in effect, while with a Client ID Policy of UNRESTRICTED, this limitation is lifted. See Developing JMS Applications for Oracle WebLogic Server. Unrestricted client IDs make it possible for multiple WebLogic subscriber connections and subscriptions to share the same client ID. Both One-Copy-Per-Server and One-Copy-Per-Application Topic Message Distribution Modes set the ClientIDPolicy to Unrestricted. Note that if two WebLogic JMS subscription references on the same physical topic have the same Client ID and durable subscription name, then the references resolve to a single subscription if the Client ID Policy is also the same, but they resolve to two different subscriptions if the Client ID Policies are different.