Есть ли что-то, что ведет себя как .wait () и .notify () в среде EJB?

Question

Я знаю, что не должен возиться с потоками в контейнерах EJB, поэтому я не знаю, как правильно сделать следующее в среде EJB:

Вовлечены :

• Сессионный компонент без сохранения состояния "Клиент"
• Сессионный компонент без сохранения состояния "Сервер"
• MessageQueue "Очередь"
• Управляемый сообщениями компонент "Mdb", который обрабатывает сообщения из "очереди"
• n Сессионные компоненты без состояния от W1 до Wn

Сценарий: :

Клиент вызывает метод Сервер , который, в свою очередь, отправляет несколько сообщений в Очередь . После этого Сервер делает другие вещи. Тем временем, Mdb принимает сообщение, вызывает Wi , который выполняет довольно долгий расчет и получает результат. Теперь Mdb дает результат для Server . Когда Сервер получает все «результаты» для каждого отправленного сообщения, он делает еще несколько вычислений с результатами из W с и возвращает этот результат Клиенту .

Моя проблема :

В Java SE я бы просто сделал .wait (), чтобы Сервер ждал результатов W с после того, как Сервер выполнил работу после отправка сообщений. Тогда mdb будет .notify (), когда он установит результаты. Поскольку я не должен возиться с потоками в контейнерах EJB, как говорится в спецификации, я заблудился, потому что не нашел подходящего способа добиться того же поведения в среде EJB.

Любая помощь по этой проблеме будет признательна, спасибо заранее.

P.S .: Я работаю с JBoss 5.1.0, на случай, если есть какие-либо специфические меры поставщика для решения этой проблемы.

Answer 1

Подходящим решением для этого является шаблон «запрос / ответ» для обмена сообщениями.В двух словах, вы можете выполнять «синхронные» операции через системы обмена сообщениями, отправляя сообщение и ожидая ответного сообщения (все это допустимо в мире J2EE).Есть множество способов добиться этого на практике, но общая идея заключается в том, что вы отправляете сообщения-запросы с каким-то уникальным идентификатором, а затем ждете ответных сообщений, используя фильтр сообщений, установленный для идентификаторов запроса, которые выотправлено (это обычно то, для чего используется поле *1001* "correlationId").MDB получит сообщения запроса, обработает их и отправит ответные сообщения, используя указанные уникальные идентификаторы из сообщений запроса.Вы можете делать все это с одной очередью, или вы можете использовать отдельные очереди запросов / ответов, или вы можете делать сумасшедшие вещи, такие как создание «временных» очередей ответов (для каждого запроса).вы можете указать MDB, куда отправлять сообщения с запросом, используя метод Message.setJMSReplyTo.

Общий шаблон:

1. клиент звонит серверу
2. server:
   1. создает сообщения, устанавливает correlationId и replyTo
   2. создает QueueSender, отправляет сообщения
3. mdb (повтор для каждого сообщения):
   1. получает сообщение
   2. обрабатывает сообщение
   3. отправляет ответное сообщение с correlationId
4. сервер:
   1. создает фильтр сообщений сcorrelationId
   2. создает QueueReceiver с селектором сообщений
   3. , вызывает receive() до тех пор, пока все сообщения не будут получены и обработаны (или истечет время ожидания)
   4. выполняет окончательную обработку, отвечает клиенту

(Очевидно, сервер переходит непосредственно от шага 2 к шагу 4, я просто написал его таким образом, чтобы выделить поток управления.)

Answer 2

какой объект выступает в роли Сервера, чтобы MDB возвращал все сообщения? ему, вероятно, нужен какой-то CountDownLatch для ожидания в размере количества сообщений (который изменяется MDB, пока не достигнет нуля). Когда он станет равным нулю, он проснется, может запустить код, который возвращается клиенту. См. Документацию API для CountDownLatch.