About Question enthuware.oce-ejbd.v6.2.604 :

[admin]

When the specification clearly says the following -

Section 5.4.17.1 : JMS Message-Driven Beans
The Deployer should avoid associating more than one message-driven bean with the same JMS Queue. If there are multiple JMS consumers for a queue, JMS does not define how messages are distribued between the queue receivers.

I am not sure what is your point.

[sanju.ait@gmail.com]

Yes, this is true. JMS does not define how messages will be distributed between queue receivers.

This statement is true in absence of messageSelector, but if messageSelectors comes into the scene, it will distribute based on filtering criteria defined in messageSelector. That's the purpose of messageSelectors.

[himaiMinh]

Regarding to the explanation of option 5 :

If the destination is a topic, then each MDB (not each instance of each MDB) listening to to the topic will receive the message.

But from a study guide written by Ivan Krizan, p. 133, we can have a ejb-jar.xml that define instances of the same MDB that listens to the topic like this:

//Example from the study guide:
<enterprise-beans>
<message-driven>
<ejb-name>TopicListener1</ejb-name>
<ejb-classes>com.ivan.scbcd6.ejbs.TopicListenerEJB</ejb-classes>
</message-driven>
<message-driven>
<ejb-name>TopicListener2</ejb-name>
<ejb-classes>com.ivan.scbcd6.ejbs.TopicListenerEJB</ejb-classes>
</message-driven>

</etnerprise-beans>

In this example, there are two instances defined in this DD, will listen to the topic specified in TopicListenEJB class.

[admin]

Instances are created by the container at run time. You are defining two MDBs here. The bean class is same for both the MDBs.

[himaiMinh]

There are some confusing concepts we need to be clear:

1. The spec discourages more than one message driven bean (eg only MDB class A) to be associated with one JMS queue. That means no more than one MDB class listening to the events of one queue.

2. The spec allows more than one message driven bean to be associated with one topic.
That means more than one MDB class (eg MDB class A , MDB class B...)listening to the events of one topic.

3. The spec allows multiple instances of one message driven bean (eg instances of MDB A) to process the messages in a queue/topic simultaneously.

Correct me if I am wrong.

[admin]

If you observe the usage of the word "instance" in the specification, you will see that by instance it means the object of the bean class. This is a run time thing.
While a "bean" is a single conceptual thing, that you create by defining it in the deployment descriptor (or annotation).

Now, you can create multiple beans using the same bean class as shown in example above where you have to beans using the same class listening to the same topic. From the container's perspectives these are two different beans and both will receive the message that is sent to the topic. Of course, creating two beans using two different bean classes is also possible and both will receive the message.

You can do the same with a queue but as you pointed out, it is not recommended by the spec.

Now, can you tell me what is the confusion?

thank you,
Paul.

[himaiMinh]

Hi, Paul. Thanks for your clarification.
So, if we have one bean listening to a queue, that means the container may create multiple instances of that bean listening to that queue?

[admin]

Yes, but that depends on whether the container is allowed to do instance pooling. A container may even allow you to control the number of instances in the pool.

[himaiMinh]

In the explanation of option 5,

Durable subscription means that the message will be delivered to the bean even if the bean is down temporarily. The message will be received by only one instance if the container has created multiple instances to process the messages

But in the spec, I don't see it says the message in the durable topic will be delivered to only one instance of the bean when the bean is temporarily unavailable (or when the EJB server is down).

[admin]

That is quite imperative. If the container creates instances on its own (which it may do to process multiple messages in parallel), you have no idea how many instances are there. Think about what will happen if the same message is processed multiple times