I have raised this JIRA issue:
http://java.net/jira/browse/JMS_SPEC-39
This issue has arisen in discussions with the EJB and Java EE spec leads about how we can improve the way in which MDBs
are configured. I have been discussing whether durableSubscriptionName and clientID can be defined as standard
activation config properties of a MDB. This discussion raised the question of why clientId is needed when defining a
durable subscription, and whether it could be made optional. I couldn't think of a good reason for making it mandatory,
and agreed to raise this with the JMS EG.
Comments, please - especially from vendors.
Here is the description in JIRA
-------------------------------
This is a proposal to make clientId optional when creating a durable subscription
In JMS 1.1, a durable subscription is defined by the combination of clientId and subscriptionName. Section 6.11.1 of the
Specification states:
{quote}
Sessions with durable subscribers must always provide the same client
identifier. In addition, each client must specify a name that uniquely identifies
(within client identifier) each durable subscription it creates.
{quote}
Whilst it is clear that a durable subscription needs to have a name to allow it to be identified, it is less clear why
it needs to be identified by clientId. This is the only place in the JMS API where a connection must have clientId set.
This requirement to have clientId set causes complication for applications, especially in a Java EE application, where
clientId must be set on the connection factory. This means that the connection factory can only be used to create a
single instance, and if a connection pool is used it must be constrained to allow only a single instance.
It is therefore proposed that the use of clientId be made optional when creating a durable subscription. In this case,
the subscription will be defined by the name of the subscription alone.
This change is not intended to change the existing restrictions stated in Section 6.11.1:
{quote}
Only one session at a time can have a TopicSubscriber for a particular durable subscription.
{quote}
Nigel