John,
Currently a durable subscription is identified by the tuple (client_id, subscription_name). This means there can be many
different durable subscriptions with the same value of subscription_name but different values of client_id. I think the
thinking was that different clients can use the same subscriptionName but have different durable subscriptions.
My proposal is that we allow clientId to be null when creating (or activating) a durable subscription. In this case the
durable subscription would be identified by the tuple (null, subscription_name).
The two naming methods could coexist at the same time.
My main reason for proposing this change is to allow easier configuration of MDBs. In this case, clientId has no useful
meaning and applications have to set it to some dummy value (perhaps the same as subscriptionName). I'd like to remove
the need to do this.
Nigel
On 16/09/2011 00:53, John D. Ament wrote:
> Nigel,
>
> What else would be used to identify the subscription?
>
> On Wed, Sep 14, 2011 at 10:16 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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
>
> 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
>
>