Hi Nigel,
I agree that changing contract for createDurableSubscriber method between
v1.1 and v2.0 brake backwards compatibility. And allowance of different
behavior for createDurableConsumer method on Session and JMSContext will
definitelly bring confusion.
Probably it will be better to provide default behavior
for createDurableSubscriber methods on JMSContext the same as defined in
v1.1. However add posibility to allow multiple consumers behavior
explicitly. It could be done either by
overloading createDurableSubscriber methods with some boolean flag or by
introducing special methods createSharedDurableSubscriber for example. What
do you think?
Thank you,
Oleg
2012/11/7 Nigel Deakin <nigel.deakin_at_oracle.com>
> It has been pointed out to me that this feature (allowing multiple
> consumers to be created on the same topic subscription) introduces a small
> break on backwards compatibility. I think this is probably OK but probably
> merits wider discussion. I have therefore recorded this as an issue in the
> draft specification.
>
> I have added a new section to appendix A.3. "Unresolved issues in the JMS
> 2.0 Public Draft" as follows, which mentions the issue and suggests two
> possible ways to avoid it. Comments welcome now or later.
>
> A.3.3 Shared durable subscriptions: small loss of backwards compatibility
> ------------------------------**------------------------------**
> -------------
>
> JMS 2.0 allows multiple consumers to be created on the same durable or
> non-durable subscription.
>
> For non-durable subscriptions this is achieved using a new method
> createSharedConsumer on both Session and JMSContext.
>
> For durable subscriptions this is achieved by using the new method
> createDurableConsumer on Session and JMSContext or the existing method
> createDurableSubscriber on Session.
>
> In this last case it has been necessary to change the specified behaviour
> of an existing method.
>
> In JMS 1.1, the API documentation for the method createDurableSubscriber
> on Session stated that "only one session at a time can have a
> TopicSubscriber for a particular durable subscription". This implied that
> an attempt to create a second TopicSubscriber for a particular durable
> subscription would cause a JMSException to be thrown.
>
> However in JMS 2.0 this behaviour is explicitly allowed. The API
> documentation states "a durable subscription may have more than one active
> consumer (this was not permitted prior to JMS 2.0). This means that
> application code which would cause a JMSException to be thrown in JMS 1.1
> would not throw such an exception in JMS 2.0.
>
> This is technically a violation of backwards compatibility and is
> therefore recorded here as an issue. Comments are invited.
>
> If feedback indicates that this change is not acceptable then one
> alternative is to reinstate the old behaviour for the existing method
> createDurableSubscriber on Session whilst retaining the new behaviour for
> the new method createDurableConsumer on Session and JMSContext. This may,
> however, be a cause of confusion.
>
> An alternative would be for new method createDurableConsumer on Session
> and JMSContext and the existing method
>