EJB и Threading

Question

Из того, что я понимаю, незаконно создавать потоки внутри EJB, поскольку это может потенциально помешать жизненному циклу EJB. Однако является ли незаконным использование предопределенных классов Java из JDK, которые внутренне порождают и обрабатывают потоки, такие как Executor внутри EJB, в частности MDB?

Answer 1

Это то, для чего предназначен EJB 3.1 @Asynchronous, и он определенно должен использоваться вместо Исполнителя Как правило, очень опасно конкурировать с пулами потоков контейнера. Это отличный способ снизить производительность.

Поддержка Asynchronous будет использовать пулы потоков контейнера и будет намного безопаснее. См. этот ответ , чтобы узнать, как работает Asynchronous.

Answer 2

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

Answer 3

Самая большая проблема с потоками и EJB-компонентами заключается в том, что потоки являются ограниченным ресурсом, интенсивно используемым контейнером, а ошибки потоков приводят к утечкам из пула потоков, которые могут эффективно уничтожить весь экземпляр JVM. должен вести себя лучше, но он все равно будет использовать поток в течение некоторого времени;он также может мгновенно потерпеть неудачу, если кто-то настроил контейнер на использование доступных потоков.

Сводка о том, что вы собираетесь ходить по канату.

Answer 4

Чтобы добавить к ответу @Charlie Martin, что бы вам ни понадобился Исполнитель, вы можете разработать другой EJB для выполнения того же действия без Исполнителя. Это позволяет новому EJB работать в отдельном потоке, обрабатываемом контейнером. Недостатком является то, что вам, возможно, придется «переопределить колесо», поскольку вы по-прежнему не хотите использовать потоки / Executor из JVM. Это также увеличивает накладные расходы на получение одного EJB для поиска / запроса / подключения / вызова другого.

Суть в том, что EJB должны сами быть рабочими потоками. Может показаться излишним копировать код вместо того, чтобы использовать Executor, и это до определенного момента. Самое большое различие - это масштаб. Исполнители будут ограничены одной JVM, в то время как EJB могут быть масштабированы по JVM и по серверам.