Создание новых java-потоков в Message Driven Bean (MDB)

Запуск новых потоков в MDB — плохая практика. Это будет работать, но новые потоки не контролируют контейнер приложения, поэтому могут вести себя непредсказуемо. Они могут даже испортить управление потоками, которое контейнер пытается поддерживать. Хуже всего то, что если приложение развернуто в кластере, то пользовательские потоки с треском провалятся.

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

Это плохая идея, если вы выполняете транзакционную работу в потоках.

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

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

Запуск потока из MDB нарушает спецификацию.

Enterprise JavaBeansTM, версия 3.0, Основные контракты и требования EJB указаны в разделе 21.1.2 Ограничения по программированию:

• Корпоративный компонент не должен использовать примитивы синхронизации потоков для синхронизации выполнения нескольких экземпляров.

• Корпоративный компонент не должен пытаться управлять потоками. Корпоративный компонент не должен пытаться запускать, останавливать, приостанавливать или возобновлять поток или изменять его приоритет или имя. Корпоративный компонент не должен пытаться управлять группами потоков.

Вы в корне упускаете суть Java EE и MDB.

Контейнер Java EE — это управляемая среда выполнения. Основная идея контейнера Java EE заключается в том, что, делегируя определенные ортогональные задачи, такие как управление транзакциями, контейнеру, компонент остается сосредоточенным на бизнес-логике и (в утопии) является повторно используемым компонентом, который делает мало предположений о своей среде выполнения.

До MDB контейнер Java EE был пассивно-реактивной системой, которая не позволяла координировать действия асинхронных активных агентов на стороне контейнера. Затем Message Driven Beans решили эту проблему, предоставив вам стандартный способ запустить асинхронное действие на стороне сервера.

У вас есть исходное событие e0, которое используется MBD0. В сообщении MDB0 сгенерирует e1 и поставит в очередь сообщение в ответ на MBD1, которое затем выполнит свою работу и отправит сообщение MDB2 и т. д.

У вас есть простой рабочий процесс из n последовательных шагов с использованием семантики обмена сообщениями pub/sub (и o/c с асинхронной семантикой), и все вовлеченные потоки управляются контейнером. Если вы хотите, чтобы участники одновременно работали, а затем собирали результаты и запускали финальное действие, рассмотрите возможность использования шаблонов, включающих темы JMS.