I refer to this JIRA issue
http://java.net/jira/browse/JMS_SPEC-73
Define how messages from a topic are delivered to clustered application server instances
Please find attached a new version of Chapter 12 "Resource adapter".
Some time ago we addressed this issue by defining a new MDB activation property "shareSubscriptions" which could be true
or false: the default was true.
A value of true means that the same durable subscription name or non-durable subscription will be used for each instance
in the cluster. A value of false means that a different durable subscription name or non-durable subscription will be
used for each instance in the cluster.
No-one objected to this proposal though there wasn't a lot of feedback.
Since then, however, here at Oracle we have been looking into how we might implement this in the various application
servers we develop here, including GlassFish (the RI). It has become apparent that simply declaring that topic
subscriptions must by default be shared by all instances in the cluster would require an incompatible change to existing
products, which currently offer their own non-standard behaviour related to clustering. I suspect the same issue will
apply to other application servers.
I have therefore revised the definition of the activation properties clientId, subscriptionName and shareSubscriptions
that were given in the new Chapter 12 "Resource adapter". The goal remains the one on the subject line of this email:
to allow the deployer to specify how messages from a topic should be delivered to MDBs running in a clustered
application server. However I have amended the proposals to avoid the possibility of introducing incompatible changes to
existing application servers, essentially by making the current behaviour remain the default.
In addition I have made a number of changes to reflect changes elsewhere in JMS 2.0 (i.e. the introduction of shared and
unshared subscriptions) and some changes expected in JCA 1.7.
There's quite a lot here so I would really appreciate your views on this. I look forward to hearing from you!
Here is a summary of the changes:
---------------------------------
The former property "shareSubscriptions" (which had the possible values of true or false) is renamed "subscriptionScope"
and has the possible values "cluster" or "instance" (see the attachment for a proper definition). This new name makes
the purpose of this property more explicit, and also avoids possible confusion with the new createSharedConsumer and
createSharedDurableConsumer methods in the JMS API. The term "shared subscriptions" is now used ONLY when talking about
the JMS API.
By default "subscriptionScope" is unset and it is undefined how messages from a topic are delivered in a cluster. This
is essentially the current situation and is provided to achieve backwards compatibility. I am deliberately vague about
this case to avoid conflicts with existing implementations.
The case where subscriptionScope is "instance" or "cluster" is explicitly defined. So the best way to ensure portability
is to specify subscriptionScope explicitly.
Setting clientID becomes optional in all cases.
Setting subscriptionName remains optional in the case where subscriptionScope is "instance" or "cluster" .
I have added some guidelines as to how these various cases may be implemented. In particular I have explained that when
subscriptionScope="cluster" (i.e. the same subscription is used by multiple application server instances) then it is
expected that a JMS 2.0 "shared subscription" will be used. However I have tried to avoid specifying that a shared
subscription should be used when it is not strictly necessary. We have had some debate here at Oracle about whether we
should require that all MDB subscriptions use "shared subscriptions" (even if they are only being used by a single
application server instance) and I would welcome more views.
A related aspect of the earlier proposals was to allow the deployer to leave subscriptionName unset. The container would
generate a suitable name based on the MDB name and the instance name. The resource adapter would look up this
information from various places in JNDI. The Java EE and EJB spec was amended to define these
A goal of both the previous and the current proposals was to allow subscriptionName to be unset. The container would
generate a suitable name from the MDB name and instance name. In the previous proposals the resource adapter would
lookup the MDB name from java:comp/UniqueMDBName (which would be defined in EJB 3.2) and the instance name would be
looked up from java:comp/InstanceName (which would be defined in Java EE 7).
However I have since been advised that this may be problematical and so I have therefore arranged with the JCA spec lead
to provide the same functionality by adding new methods to the JCA BootstrapContext and MessageEndpointFactory
interfaces that are passed to the resource adapter. See the attached extract from the spec for details. The actual JCA
changes are described here:
http://java.net/jira/browse/CONNECTOR_SPEC-1
Nigel