Is there something that behaves like .wait() and .notify() in EJB environment?

Question

I know i must not tinker with threading in EJB Containers, therefore i do not know how to do the following thing in an EJB Environment the right way:

Involved are:

• Stateless Session Bean "Client"
• Stateless Session Bean "Server"
• MessageQueue "Queue"
• Message Driven Bean "Mdb" which processes messages from "Queue"
• n Stateless Session Beans W1 through Wn

Scenario is:

Client calls a Method of Server, which in turn sends several Messages to Queue. After that, Server does some other stuff. In the meantime, Mdb consumes a message, calls Wi which does some rather long calculation, and gets the result. Now Mdb gives the result to Server. When Server got all the "results" for every message it sent, it does some more calculations with the results from the W s, and returns that result to Client.

My Problem:

In Java SE I would simply do .wait() to have Server wait for the results of the W s, after Server did the work after sending the messages. Then mdb would .notify() when it has set the results. Since I must not tinker with threading in EJB Containers, as the specification states, I am lost cause I did not find any appropriate way to achieve the same behavior in EJB Environment.

Any help on that problem would really be appreciated, thanks in advance.

P.S.: I am working with JBoss 5.1.0, in case there are any vendor-specific measures to tackle that problem.

Answer 1

The appropriate solution for this is the "request/response" pattern for messaging. In a nutshell, you can do "synchronous" operations via messaging systems by sending a message and waiting for a response message (all of this is legal in the J2EE world). there are a variety of ways you can achieve this in practice, but the general idea is that you send the request messages with some sort of unique identifier, then wait for response messages using a message filter set for the request id(s) that you sent (this is generally what the "correlationId" field is used for). the MDB would get the request messages, process them, and send the response messages using the specified unique identifiers from the request messages. you can do all of this with one queue, or you can use separate request/response queues, or you can do crazy things like creating "temporary" response queues (per-request). you can tell the MDB where to send the request messages using the Message.setJMSReplyTo method.

The general pattern is:

1. client calls server
2. server:
   1. creates messages, sets correlationId and replyTo
   2. creates QueueSender, sends messages
3. mdb (repeat for each message):
   1. receives message
   2. processes message
   3. sends response message with correlationId
4. server:
   1. creates message filter with correlationId
   2. creates QueueReceiver with message selector
   3. calls receive() until all messages are received and processed (or times out)
   4. does final processing, responds to client

(Obviously, the server proceeds directly from step 2 to step 4, i just wrote it this way to highlight the control flow.)