Java – Message Driven Bean Selectors (JMS)

Pedant alert! I'm the kind of guy that reads the actual specs for technologies.

Reading the EJB spec version 3.0, section 21.1.2 (Programming Restrictions) disallows using threads in your code. Here's the language and the rationale ...

The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.

So if you do what you're saying, the EJB police will come knocking on your door in the middle of the night and take you away. Or your app might malfunction and the vendor will laugh when you complain. Or nothing bad at all will happen.

But, as duffymo says, why do this? If you want the scalability offered by lots of threads, can you configure that in for your MDB? The point of EJB's is to handle stuff like that for you.

When multiple consumers use the same queue, message selectors need to configured correctly across these consumers so that there is no conflict in determining the intended consumer.

In the case of message-driven-beans (a consumer of JMS messages), the selector can be specified in the ejb-jar.xml file thereby allowing for the configuration to be done at deployment time (instead of the opposing view of specifying the message selector during development).

Edit: In real life, this would make sense when different consumers are responsible for processing messages containing the same headers (often generated by the same producer) written onto the same queue. For instance, message selectors could be used in a trading application, to differentiate between buy and sell orders, when the producer is incapable of writing the JMS messages onto two separate buy and sell queues.