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

Question

I know that I should not bother with threads in EJB containers, so I don’t know how to properly do the following in an EJB environment:

Accepted :

• Standing Bean Client
• Standing Bean Server Session
• MessageQueue Queue
• Message Driven Bean "Mdb", which processes messages from the "queue"
• n Session without considering the state of Beans W1-Wn

Scenario :

The client calls the server method, which in turn sends several messages to the queue. After that, the server performs some other actions. At the same time, Mdb consumes a message, calls Wi, which performs a rather long calculation and gets the result. Now Mdb gives the result to the server. When the server has received all the "results" for each sent message, it performs several more calculations with the results of W s and returns this result to the client.

My problem is :

In Java SE, I would simply do .wait () so that the server would wait for the results of W s after the server did work after sending messages. Then mdb will be .notify () when it sets the results. Since I should not bother with threads in EJB containers, as indicated in the specification, I lost the reason that I could not find a suitable way to achieve the same behavior in an EJB environment.

Any help on this issue would really be appreciated, thanks in advance.

PS: I work with JBoss 5.1.0 if there are any specific measures to solve this problem.

Answer 1

An appropriate solution for this is a messaging request / response template. In a nutshell, you can perform "synchronous" operations through messaging systems by sending a message and waiting for a response message (all this is legal in the J2EE world). There are many ways you can achieve this in practice, but the general idea is that you send request messages with some unique identifier, and then wait for response messages using the message filter set for the request identifiers (s), which you are (usually the "relativeId" field is used ). The MDB will receive request messages, process them, and send response messages using the specified unique identifiers from the request messages. you can do it all with one queue, or you can use separate request / response queues, or you can do crazy things, such as creating “temporary” response queues (per request). you can tell the MDB where to send request messages using the Message.setJMSReplyTo method.

The general scheme:

• client call server
• Server:
  • creates messages, gain correlationId and replyTo
  • creates QueueSender, sends messages
• mdb (repeat for each message):
  • receives a message
  • processes the message
  • sends a response message with correlation id
• Server:
  • creates a message filter with correlation ID
  • creates a QueueReceiver with a message selector
  • calls receive() until all messages have been received and processed (or not executed)
  • performs final processing, responds to the client

(Obviously, the server goes directly from step 2 to step 4, I just wrote it in such a way as to highlight the control flow.)

Answer 2

which object acts as a server, MDB returns all messages? it probably needs some kind of CountDownLatch to wait, in the amount of the number of messages (which is changed by MDB to reach zero). When it becomes zero, it wakes up, can run the code that is returned to the client. See API Document for CountDownLatch.