Есть множество способов сделать это.
Во-первых, вы можете использовать EJB Timer для создания однократного запуска процесса, который начнется немедленно. Это хорошая техника для порождения процессов в фоновом режиме. Таймер EJB связан с конкретной реализацией Session Bean. Вы можете либо добавить таймер EJB к каждому сессионному компоненту, который вы хотите сделать, либо у вас может быть один сессионный компонент, который затем может вызывать логику вашего приложения через некоторый механизм диспетчеризации.
Для меня я передаю сериализуемый блоб параметров вместе с именем класса, которое соответствует определенному интерфейсу, универсальному сессионному компоненту, который затем выполняет класс. Таким образом, я могу легко справиться с чем угодно.
Одно предупреждение о таймере EJB - это то, что таймеры EJB являются постоянными. После создания EJB-таймер остается в контейнере, пока его работа не будет завершена или отменена. Причиной этого является то, что если у вас длительный процесс, а сервер отключается, то при перезапуске процесс продолжится и возобновит работу. Помните, что это может быть хорошо, но только если ваш процесс готов к повторному запуску. Но если у вас есть простой процесс, повторяющий «10000 элементов», если сервер отключается на 9999 элементах, когда он возвращается, вы можете легко увидеть, что он просто начинается с первого элемента. Это все выполнимо, просто предостережение из.
Другой способ создать фоновый режим - использовать очередь JMS. Поместите сообщение в очередь, и обработчик будет работать асинхронно с остальной частью вашего приложения.
Самое умное здесь, и кое-что, что я также сделал, используя работу с Timer Bean, заключается в том, что вы можете контролировать, сколько «заданий» будет выполняться, исходя из того, сколько экземпляров MDB вы настроили в системе.
Итак, для конкретной задачи запуска процесса в нескольких параллельных порциях я беру задачу, разбиваю ее на «кусочки», а затем отправляю каждую часть в очереди сообщений, где MDB-компоненты их выполняют. Если я разрешу 10 экземпляров MDB, у меня может быть 10 «частей» любой задачи, выполняемой одновременно.
Это на самом деле работает на удивление хорошо. Есть небольшие накладные расходы, которые разделяют процесс и направляют его через очередь JMS, но это все, по сути, «время запуска». Как только это начнется, вы получите реальную выгоду.
Еще одним преимуществом использования очереди сообщений является то, что вы можете выполнять текущие долго выполняющиеся процессы на отдельной машине, или вы можете легко создать кластер машин для обработки этих процессов. Тем не менее, интерфейс такой же, и код не знает разницы.
Я обнаружил, что после того, как вы перешли на длительный процесс в фоновом режиме, вы можете заплатить цену за мгновенный доступ к этому процессу. То есть, нет никакой причины непосредственно контролировать исполняющие классы, просто пусть они публикуют интересную информацию и статистику в базе данных, или JMX, или что-то еще, вместо того, чтобы иметь что-то, что может контролировать объект напрямую, потому что он разделяет то же пространство памяти.
Мне было легко настроить инфраструктуру, позволяющую запускать задачи либо на EJB Timer, либо в очереди разброса MDB, задачи одинаковы, и я мог отслеживать их выполнение, останавливать их и т. Д.
Вы можете комбинировать технику рассеяния для создания нескольких заданий таймера EJB. Одним из бесплатных преимуществ MDB является то, что он действует как пул потоков, который может ограничивать ваши задания (поэтому вы не переполняете свою систему слишком большим количеством фоновых процессов). Вы получаете это «бесплатно», просто используя функции управления EJB в контейнере.
Наконец, в Java EE 6 появился новый «асинхронный» (или что-то) квалификатор для методов Session Bean. Я не знаю подробностей о том, как это работает, поскольку мне еще предстоит поиграть с новым контейнером Java EE 6. Но я думаю, вы, вероятно, не захотите менять контейнеры только для этого объекта.