+1
On Wed, Sep 14, 2011 at 4:16 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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<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
>
>
--
Julien Dubois
Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
Phone: +33 (0)6 25 02 34 18