EJB design: Using Threads in Server Side Environment and EJB Solution

  1. I'm following a project, this one uses massively native IBM MQ Queues for receiving messages, trasforming these, and sending again through another MQ Queue. I've to manage a lot of Queues in concurrent way, so I thought about using Concurrent Threads to read and write from Queues, but in J2EE is not possible to use threads in server side, so I need another solution. The solution found, is to use Message Driven Beans with JMS technology connected to NEW ADDED QUEUES, used only to activate the reading and writing from the original native IBM MQ Queues. In this solution, I have tyo types of Queue, a type used only to activate the original Queue reading and writing and the other type with the real messages to transform. The first Queues used with Message Driven Bean. It's clear that using Threads makes the solution, simpler than second one. What do you think about. Thanks a lot for Answers and Sorry for my poor English!!!
  2. You are correct that the EJB spec. forbids custom usage of threads. However, if you are a lucky JBoss user, you are allowed using "async calls", which is a "managed wrapper" for thread creation. This feature will officially be supported by the EJB 3.1 spec. On the other side, even though the ejb spec. forbids thread creation, no app server will physically restrict tread creation. As long as you really know what you are doing, custom managed theads works, even though it is not a solution officially recommended. /N
  3. JCA[ Go to top ]

    Message Driven Beans (MDB) are, as you have observed, the standard solution here. Ideally what you want is to couple your MDB directly to the real MQ (I'm surprised that this isn't possible out of the box). Just be clear here what I am saying is that MDB are not restricted to JMS. The Java Connector API (part of J2EE 1.4) provides a standard way to write a "resource adapter" defining arbitrary resource types and MDB drivers (including you own interface for MDB, and a standard interface to use container provided threads). see packages javax.resource.spi and sub-packages. I would expect either the app server or the IBM MQ implementation to provide an RA to can do what you need, but in the limit you could write your own.
  4. Sometimes we use J2EE features simply for the sake of it. I suggest you evaluate why do you need to use MDB in the first place. Here are few options:- 1) If your current project uses MQ massively, there is a very good reason you should switch to Java MQ library. This will make your life easy and will give you all the power to handle multi-threading features. 2) Have a MDB listening to IBMMQ queue. Easiest way to achieve this is by configuring initial-context-factory to appropriate class provided by IBMMQ JMS library. e.g. : "java.naming.factory.initial=com.ibm.mq.jms.context.WMQInitialContextFactory" [Reg message from Clive Brettingham-Moore : I am not aware of Connector API but I fail to see why is it required here] 3) You solution of using JMS and MDB together also makes sense. Just take care regarding transaction-attributes. Hope this helps.