B Topic Subscription Identifiers

In JMS, a subscription is identified and located based on (a) the topic with which it is associated, (b) the connection "Client ID" string that is specified for the connection that is used to access the subscription, and (c), if using durable subscriptions, the subscription name that is specified when the durable subscription is created.

Furthermore, in WebLogic JMS, a subscription is also identified by (d) the "Client ID Policy" option. 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 Policy is also the same, but they resolve to two different subscriptions if the Client ID Policies are different.

A WebLogic MDB container generates a, b, c, and d automatically, based on the following settings:

The ejb-name
jms-client-id
topicMessagesDistributionMode
distributedDestinationConnection
generate-unique-client-id
subscriptionDurability
Other elements of the MDB deployment and JMS configurations

The last four settings, above, 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
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 `ejb-name` = the name of the EJB `jmsClientIDBase` = `jms-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 WebLogic Server that the MDB is running on `uniqueKey` = a string that contains some of the MDB deployment elements, possibly the `currentServerName`, plus, if the destination is a WebLogic destination that is hosted by a JMS server that is using a migratable target, then it includes this 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 WebLogic Server prior to 10.3.4.
`topicMessagesDistributionMode` = `One-Copy-Per-Application`	`jmsClientIDBase`	`ejb-name`	Unrestricted
`topicMessagesDistributionMode` = `One-Copy-Per-Server`	`jmsClientIDBase` + "_" + `currentDomainName` + "_" + `currentServerName`	`ejb-name`	Unrestricted
`topicMessagesDistributionMode` = `Compatibility` `generateUniqueClientID` = `true` `distributedDestinationConnection` = `LocalOnly` `subscriptionDurability` = `Durable`^Foot 1	`jmsClientIDBase` + "_" + `currentDomainName` + "_" + `uniqueKey`	Same as the `ClientId`	Restricted
Same as previous row, except: `distributedDestinationConnection` = `EveryMember`	`jmsClientIDBase` + "_" + `currentDomainName` + "_" + `uniqueKey` + "_" + `DDMemberName`	Same as the `ClientId`	Restricted
`topicMessagesDistributionMode` = `Compatibility` `generateUniqueClientID` = `false` `subscriptionDurability` = `Durable`^Footref 1	`jmsClientIDBase`	Same as the `ClientId`	Restricted

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

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 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 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. For more information, see Programming JMS 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.