Enthuware

The explaination for the wrong answer "It must allow deployment of a Message Driven Bean to listen for multiple JMS queues." is not clear. It looks like it's the explaination for "It must allow deployment of multiple Message Driven Beans to listen for single JMS queue."

Also, for the wrong answer: "If a MDB is associated with a durable subscription, each bean instance in the pool will receive each message.", if changed to
If a MDB is associated with a durable subscription, each MDB in the pool will receive each message.

Would it make it correct?

Is there anything like durable Queue? Or Queue is always durable assumed by the container?

Thanks.

Jofen wrote:Also, for the wrong answer: "If a MDB is associated with a durable subscription, each bean instance in the pool will receive each message.", if changed to
If a MDB is associated with a durable subscription, each MDB in the pool will receive each message.

Would it make it correct?

Yes, because an MDB is a logical thing. A container might create multiple instances of the bean class. This is what the explanation says as well.

Is there anything like durable Queue? Or Queue is always durable assumed by the container?

Thanks.

Section 5.4.17.1 says,

Durable topic subscriptions, as well as queues, ensure that messages are not missed even if the EJB server is not running. Reliable applications will typically make use of queues or durable topic subscriptions rather than non-durable topic subscriptions.

So it can be safely said that a queue is always durable.

HTH,
Paul.

I totally agree with

The explaination for the wrong answer "It must allow deployment of a Message Driven Bean to listen for multiple JMS queues." is not clear. It looks like it's the explaination for "It must allow deployment of multiple Message Driven Beans to listen for single JMS queue."

Could that be fixed?

Christian wrote:I totally agree with

The explaination for the wrong answer "It must allow deployment of a Message Driven Bean to listen for multiple JMS queues." is not clear. It looks like it's the explaination for "It must allow deployment of multiple Message Driven Beans to listen for single JMS queue."

Could that be fixed?

Actually, this explanation applies to both the options. Since it is already explained what the specification says regarding associating an MDB with multiple queues, there doesn't seem to be a need to repeat the same thing again for the second option.

HTH,
Paul.

"It must allow deployment of multiple Message Driven Beans in same application to listen for single JMS queue."

Here it refers to Application Server.
So if a bean developer wants to have more than one MDB's listen to a Queue based on messageSelector, it is a very valid case.

So it is a must from a container provider side that multiple MDB's should be able to listen to a Queue, though this is a not the most common use case but it is a valid use case.

It is talking about different MDBs, not different instances of the same MDB.
The explanation quotes the section of the specification. You may want to check it out.
-Paul.

Yes different MDB's can also listen to same Queue with the help of messageSelector.

And its container provider responsibility to pass messages to different MDB's based on messageSelector.

So this is a must from container provider.

Can you please specify in the specification where it says that it is a must for container provider?

To implement messageSelector is a must for container provider, please correct me if implementing messageSelector in MDB's is not must for container provider. If it is not must for a container provider to implement messageSelector, than what is the behavior expected in that case of usage of messageSelector?

Also it is mentioned at
Book : Java Message Service, Second Edition by Mark Richards, Richard Monson-Haefel, and David A. Chappell
Chapter : 6

Message selectors are applied to message consumers when creating a QueueReceiver,
QueueBrowser, or TopicSubscriber. When message selectors are used, the consumer will
receive only messages that apply to the specified filter. Message selectors use message
properties and headers as criteria in conditional expressions. These conditional expressions
use boolean logic to declare which messages should be delivered to a JMS
consumer.

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.

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.

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.

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

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.

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.

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?

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.

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).

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