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