A durable topic subscriber MDB uses its name to generate its client-id.   
Since JMS enforces uniqueness on this client-id, this means that if a durable 
subscriber MDB is deployed to multiple servers only one server will be able 
to connect.  Some applications want a different behavior where
each MDB pool on each server gets its own durable subscription.


The MDB durable subscription id, which must be unique on its topic, comes from:

 1) <jms-client-id>MyClientID</jms-client-id>
       (the weblogic dtd)

 2) if (1) is not set then the client-id
    comes from the ejb name.


The durable subscription is uniquely identified within a cluster by a 
combination of "connection-id" and "subscription-id".    Only one active 
connection may use a particular "connection-id" within a WebLogic cluster.  
The connection id comes from:

 1) The "ClientId" attribute configured on the WebLogic connection factory.
    This defaults to null.  Note that if the ClientId is set on a connection
    factory, only one connection created by the factory
    may be active at a time.

 2) If (1) is not set, then, as with the subscriber-id,
    the connection-id is derived from jms-client-id descriptor attribute:

    <jms-client-id>MyClientID</jms-client-id>
       (the weblogic dtd)

 3) If (1) and (2) are not set, then, as with the subscriber-id,
    the connection-id is derived from the ejb name.


Work-around:  

A) Create a custom connection-factory for each server:
   1) configure "JNDIName" to the same value across all servers
           ("myMDBCF" in this example)
   2) configure "ClientId" to a unique value per server
   3) enable "UserTransactionsEnabled"     
   4) enable "XAConnectionFactoryEnabled"
   5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
   6) target the CF at a single WebLogic server
(Number 5 is required for non-transactional topic MDBs)

B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection 
factory to the JNDI name of the custom connection factories configured in 
(A).   Optionally, also specify the subscriber-id via the jms-client-id 
attribute.

<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>exampleBean</ejb-name>
    <message-driven-descriptor>
      ... 
      <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
      ...
      <jms-client-id>myClientID</jms-client-id>
      ...
    </message-driven-descriptor>
    ...
  </weblogic-enterprise-bean>
</weblogic-ejb-jar>

C) Target the application at the same servers that have the custom connection 
factories targeted at them. 

Notes/Limitations:

1) If the MDB is moved from one server to another, the MDB's corresponding 
connection-factory must be moved with it.

2) This work-around will not work if the destination is not in the same 
cluster as the MDB.  (The MDB can not use the local connection factory, which 
contains the connection-id, as connection factories do not work unless they 
are in the same cluster as the destination.)

3) This work-around will not work for non-WebLogic JMS topics.