Как EJB может распараллелить длительный процесс с интенсивной загрузкой процессора?

Этот конкретный вопрос возникал несколько раз, и я резюмирую, что есть несколько возможных решений, только одно из которых я бы порекомендовал.

Используйте WorkManager из commonj API. Он позволяет управлять потоками в контейнере Java EE и специально разработан для вашего варианта использования. Если вы используете WebSphere или WebLogic, эти API уже доступны на вашем сервере. Для других вам придется внедрить стороннее решение в себя.

Информация WorkManager

Связанные вопросы Почему создание потоков не рекомендуется

Есть много способов сделать это.

Во-первых, вы можете использовать таймер EJB для создания однократно запускаемого процесса, который запускается немедленно. Это хорошая техника для запуска процессов в фоновом режиме. Таймер EJB связан с конкретной реализацией сеансового компонента. Вы можете добавить таймер EJB к каждому сеансу Bean, который вы хотите сделать, или у вас может быть один сеансовый компонент, который затем может вызывать логику вашего приложения через некоторый механизм диспетчеризации.

Для меня я передаю сериализуемый большой двоичный объект параметров вместе с именем класса, который соответствует определенному интерфейсу, в общий сеансовый компонент, который затем выполняет класс. Таким образом, я могу легко создать фон для чего угодно.

Одно предостережение относительно таймера EJB заключается в том, что таймеры EJB являются постоянными. После создания таймера EJB он остается в контейнере до завершения или отмены его задания. Проблема в том, что если у вас есть длительный процесс, и сервер выходит из строя, при перезапуске процесс продолжится и восстановится. Помните, что это может быть хорошо, но только если ваш процесс готов к перезапуску. Но если у вас есть простой процесс, повторяющий «10 000 элементов», если сервер отключается на элементе 9 999, когда он возвращается, вы можете легко увидеть, что он просто начинается с элемента 1. Все это работоспособно, просто предостережение, чтобы знать из.

Другой способ сделать что-то в фоновом режиме - использовать очередь JMS. Поместите сообщение в очередь, и обработчик будет синхронизирован с остальной частью вашего приложения.

Важная часть здесь, и кое-что, что я также сделал, используя работу с Timer Bean, заключается в том, что вы можете контролировать, сколько «заданий» будет выполняться в зависимости от того, сколько экземпляров MDB вы настроите для системы.

Итак, для конкретной задачи по запуску процесса в нескольких параллельных порциях я беру задачу, разбиваю ее на «части», а затем отправляю каждую часть в очередь сообщений, где их выполняют MDB. Если я разрешаю 10 экземпляров MDB, у меня может одновременно выполняться 10 «частей» любой задачи.

Это действительно работает на удивление хорошо. Есть небольшие накладные расходы, связанные с разделением процесса и маршрутизацией его через очередь JMS, но это все в основном «время запуска». Как только это начнется, вы получите реальную выгоду.

Еще одним преимуществом использования очереди сообщений является то, что вы можете иметь ваши фактические длительные процессы, выполняющиеся на отдельном компьютере, или вы можете легко создать кластер машин для обработки этих процессов. Тем не менее, интерфейс такой же, и код не знает разницы.

Я обнаружил, что как только вы отодвинете долго выполняющийся процесс на задний план, вы можете заплатить цену менее мгновенного доступа к этому процессу. То есть нет причин непосредственно контролировать сами выполняемые классы, просто пусть они публикуют интересную информацию и статистику в базе данных или JMX, или что-то еще, вместо того, чтобы иметь что-то, что может контролировать объект напрямую, потому что он использует одно и то же пространство памяти.

Мне легко удалось настроить структуру, которая позволяет запускать задачи либо в таймере EJB, либо в очереди разброса MDB, задачи одинаковы, и я мог отслеживать их прогресс, останавливать их и т. Д.

Вы можете комбинировать технику разброса для создания нескольких заданий таймера EJB. Одним из бесплатных преимуществ MDB является то, что он действует как пул потоков, который может ограничивать ваши задания (чтобы вы не перегружали свою систему слишком большим количеством фоновых процессов). Вы получаете это «бесплатно», просто используя функции управления EJB в контейнере.

Наконец, в Java EE 6 есть новый «асинхронный» (или что-то в этом роде) квалификатор для методов Session Bean. Я не знаю подробностей о том, как это работает, так как я еще не играл с новым контейнером Java EE 6. Но я полагаю, что вы, вероятно, не захотите менять контейнеры только для этого объекта.

EJB - это, в конечном счете, транзакционный компонент для системы клиент-сервер, обеспечивающий семантику запроса / ответа. Если вы оказались в положении, когда вам нужно пометить длительную транзакцию в рамках цикла запроса / ответа, значит, где-то ваш системный архитектор (ure) ошибся.

Ситуация, которую вы описываете, четко и правильно обрабатывается архитектурой на основе событий с серверной частью обмена сообщениями. Первоначальное событие инициирует процесс (который затем может быть тривиально распараллелен, если рабочие подписываются на тему события), а сам процесс агрегирования вызывает событие по завершении. Вы по-прежнему можете сжать эту последовательность в рамках цикла запроса / ответа, но при необходимости вы нарушите букву и дух спецификаций архитектуры системы Java EE.

Назад в будущее - Java EE 7 имеет гораздо больше поддержки параллелизма через ManagedThreadFactory, службу ManagedExecutor и т. Д. (JSR 236: Утилиты параллелизма для Java EE), с помощью которых вы можете создавать свои собственные 'управляемые' потоки. Это больше не табу в EE AS поддерживая его (Wildfly?), используя API ManagedThread *

Подробнее

https://jcp.org/aboutJava/communityprocess/ec-public/materials/2013-01-1516/JSR236-EC-F2F-Jan2013.pdf http://docs.oracle.com/javaee/7/tutorial/doc/concurrency-utilities002.htm

Однажды я участвовал в проекте, в котором транзакции EJB выполнялись до 5 часов за раз. Аааааааааааааааааааа!

В этом же приложении был консультант-специалист BEA, который одобрил запуск дополнительных потоков из транзакций. Хотя это не рекомендуется в спецификациях и других местах, это не приводит к автоматическому отказу. Вы должны знать, что ваши дополнительные потоки находятся вне контроля контейнера, и поэтому, если что-то пойдет не так, это ваша вина. Но если вы можете быть уверены, что количество потоков, запущенных в худшем случае, не превышает разумных пределов и что все они полностью завершаются в разумные сроки, тогда вполне возможно работать таким образом. Фактически, в вашем случае это звучит как почти единственное решение.

Возможны несколько немного эзотерических решений, когда ваше приложение EJB обращается к другому приложению для службы, которое затем само выполняет многопоточность, прежде чем вернуться к вызывающей стороне EJB. Но это, по сути, просто смещение проблемы.

Однако вы можете рассмотреть возможность объединения потоков, чтобы сохранить верхний предел количества порожденных потоков. Если у вас слишком много потоков, ваше приложение будет вести себя ужасно.

Вы достаточно хорошо проанализировали ситуацию, и нет, для этого нет никакого паттерна, соответствующего модели EJB.

Создание цепочек в основном запрещено, потому что это происходит в обход приложения . стратегии управления потоками сервера, а также из-за транзакций.

Я работал над проектом с аналогичными требованиями и решил создать дополнительные потоки (тогда это противоречило sepc). Операция для распараллеливания была доступна только для чтения, поэтому она работала в отношении транзакции (поток в основном не имел связанной транзакции с ними). Я также знал, что не буду порождать слишком много потоков на вызовы EJB, поэтому количество потоков не было проблемой. Но если предполагается, что ваши потоки изменяют данные, вы серьезно нарушите транзакционную модель EJB. Но если вы работаете с чистыми вычислениями, это может быть нормально.

Надеюсь, поможет...