Dear experts,
On 05/08/2011 12:56, Nigel Deakin wrote:
> 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}
>
I haven't received any feedback from the expert group on this. Is this because you all think this is a good idea?
I did receive one comment on the JIRA issue from Tim Fox (a well-known JMS expert, though not on the EG) who thought
that clientId should continue to be used to distinguish between two subscriptions with the same name. I replied to say
that if clientId were supplied the old behaviour would remain. This change would simply make clientId optional.
I think this change will be particularly beneficial to MDBs, where applications currently have to contrive a rather
meaningless clientID.
The expert group has 15 members, several of whom we haven't heard much from. Can you all please express a view on this
small change? Responses of the form "+1" (or "like" :-) are just fine. I will take silence as implied agreement, but I'd
rather the group takes decisions rather more actively than this.
Nigel