На мой взгляд, идеальным решением для вашей задачи будет использование JMS и\или Quartz. У меня на проекте примерно похожая задача и это решение превосходно себя оправдывает. Я вижу два варианта решения с использованием этих технологий, какой выбирать решать вам, а я их кратко попытаюсь описать.

1) Plain JMS, вы в приложении контролируете момент, когда нужно запустить асинхронную обработку - допустим вставилась запись, вы точно знаете, что ее нужно асинхронно обработать - вы создаете JMS мессадж со всеми необходимыми данными(id записи и пр.) и кидаете ее в JMSQueue. Создаете JMSListener который получает сообщения из очереди, кастите мессадж к типу Сommand и вызываете метгод command.execute() - в этом методе пишете всю логику по асинхронной обработке. Плюсы - с момента изменения и до момента асинхронной обработки проходит очень мало времени. Также плюсом является двольно понятная архитектура и не надо использовать никакие таймеры и кварцы. Минусы - если задачи очень маленькие, то в принципе может быть большой оверхед, так как на каждый чих создается сообщение, а это ресурсы. Также неподходит допустим, если данные могут измениться вне вашего контроля, тогда лучше использовать вариант 2

2) Batch process(JMS+Quartz). Именно он у нас и используется. У нас есть сущности AbstractCommand и AbstractProcess. AbstractCommand - это абстрактная комманда, в методе execute - происходит основная логика, но в отличие от первого варианта, команда может быть сгенерирована допустим для 10-20 записей(меньше оверхед). Эти команды генерятся в AbstractProcess в методе generateCommand() который возвращает конкретный тип команды. Теперь сам алогритм

Настройка -
1) Создаем таблицу batch_process - в ней записываем java-class процесса и его cron-expression - параметры шедулинга
2) Создаем JMSQueue
3) Создаем Процессы и команды, имена процессов сохраняем в batch_process
4) Создаем JMSListener
Алгоритм
1) В момент старта приложения ищем все записи в таблице бач_процесс и шедулим их в Quartz на основе cron_expression, можно это делать в ServletContextListener
2) Кварц шедулит на выполнение процесс(когда надо)
3) Вызывается метод generateCommand() - в это месте вы можете просканировать таблицу какую вам надо, найти айди для асинхронной обработки, рассувать полученные айди по коммандам(если комманда тяжеловесная - то на одну запись одна комманда, если легкая - то можно и 10 айди запихать)
4) Сгенерированные команды пихаем в JMS
5) Вызывается Listener который открывает коннекшн, создает транзакцию и вызывает метод execute() у комманды
6) Закрываем транзакцию и коннекшн.
Плюсы - ресурсы тратятся более умно, больший throughtput, минусы - время на настройку(единожды), и непредсказуемое время от начала события(запись изменилась) до асинхронной ее обработки, в нашем случае это некритично. Вообще у нас еще много всего дописано над этой идеей, почти фреймворк, но углубляться не буду, идею вы должны были понять.

А теперь о цифрах - как я уже говорил мы используем 2)
Мы создали кластер на WebLogic из 4 нод, и расшаренную JMS Queue. В среднем количество комманд в день - 20-30 тысяч, усредненная комманда - это 7 селектов, два апдейта, один инсерт, один делит. Тестировали пиковую нагрузку - 100 тысяч, все отработало на ура и без тормозов, так что видно что есть резерв.

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

авторВторой описанный вами случай как раз использует шедулер. Т.е не пишущий процесс (в базу или файл) генерит jms месадж, а некий джоб который по шедулеру через определенный промежуток времени опрашивает базу или папку на наличие новых сущностей и генерит месадж содержащий информацию о новых записях. Я правильно понял?
Да, только можно генерировать не один мессадж, а на каждую запись по jms мессаджу, как и в первом варианте, таким образом практически приходя к варианту 1, таким образом у вас появляется дополнительная гибкость, зачем она обьясню далее.

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

У этого подхода есть два слабых места по сравнению с шедулером, хотя они могут вас и не касаться. 1) У нас в системе ресурс(БД) может измениться не только из нашего кода, но и допустим через ESB или стороннюю программу, исходников которой у нас нет, таким образом нам без шедулера вообще никак. 2) Асинхронная обработка может быть разной сложности, допустим в одном случае нам надо просто послать email на определенный адрес, в другом проапдейтить три таблицы и вызвать сторонний веб-сервис, так вот как показала практика создавать jms-мессадж для отправки одного email, как раз-таки приводит к оверхеду, оптимальнее раз в 6 часов вытянуть все адреса и в цикле их обработать.

авторВторой вариант мне кажется более сложным и ресурсоемким по следующим причинам:
1)Постоянное сканирование ресурса на наличие новых записей, в случае если мы хотим минимизировать время между появлением новой записи и ее обработки, промежуток времени между обращением к ресурсу(интервал срабатывания таймера) должен быть очень маленьким.

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

автор2)Мы должны самостоятельно менеджить обрабатывающие потоки. Допустим нам пришел месадж о том что существует 10 необработанных записей. Соответственно, нам нужно стартануть 10 потоков которые будут работать с соответствующими записями, а в первом варианте подобную работу выполняет непосредственно ejb контейнер запуская новые инстансы MDB в случае если текущий не успевает обрабатывать входящие месаджи.

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

Следует добавить, что эти стратегии можно и смешивать, все зависит от задачи.

Ну и вывод -
1 вариант:
Плюсы 1) Минимальное время отклика 2) Более простая и понятная модель
Минусы 1) Не подходит если вы не контролируете все изменения ресурса 2) Может приводить к генерации значительного количества комманд, которые могут привести к падению произодительности 3) Не обладает такой гибкостью как вариант 2

2вариант:
Плюсы - 1) Единственный вариант когда вы не полностью контролируете код 2) Возможность более оптимально распределять мессаджи и таким образом нагрузку. 3) более гибок
Минусы - 1) Сложнее реализация, в том числе подбор параметров для шедулинга 2) Не удобен если время отклика критично 3) При некоторых обстоятельствах действительно привносит оверхед.

Таким образом Вам остается проанализировать свое приложение и попытаться воспользоваться сильными сторонами из каждого подхода, не забывая о том, что подходы можно совмещать

авторЗнакомые задачи из разряда, у нас трехзвенка, но иногда в базу пишут напрямую ;)
К несчастью, в крупных проектах такое зачастую случается не по причине плохого проектирования. Например наше приложение - крошечная часть корпоративной системы страхования, есть отдельная система учета аккаунтов, есть отдельная система баланса определенного мембера и истории покупок в виртуальных магазинах, есть система, которая возвращает параметры здоровья мембера. Наше маленькое приложение - по сути интерпретатор бизнес-правил, который принимает на вход информацию аккаунта(пол, дата рождения, семья) а также медицинские параметры(вес, рост, диабет, давление и т.п.) прогоняет правила и рекомендует мемберу некие "активности" - например сбросьте вес и т.п, в случае если мембер успешно выполняет задачу - ему начисляются вирутальные деньги, которые он может потратить а компании-наемнику выгода в том,что он платит меньше за страховку, в итоге выгода всем. Но вот беда, наши рекомендации очень сильно зависят от внешних систем(аккаунтинг, медицинское обследование и т.п), и вот когда там что-то меняется(мембер переехал в другой штат, или вес изменился и т.п.) - нам соотвественно нужно перепрогнать наши рекоммендации. Мы используем ESB, но проблема в том, что некое сообщение(например об изменении адреса мембера) может повлиять на наши рекомендации, а некоторые нет, и в общем случае задача определения того, нужно нам реагировать или нет - очень дорогостоящая. Поэтому мы просто сохраняем эвенты в таблице, они нам могут понадобиться а могут и нет.
Каждый час стартует процесс который сканирует наши рекомендации, если их срок подходит к концу - но мы знаем что рекомендация зависит от места проживания, мы ищем эвент о смене адреса, и в зависимости от этого предпринимаем действия.
Это лишь единичный случай той сложности, с которой постоянно приходится сталкиваться, и дело вовсе не в том, что кто-то пишет в нашу базу, печалька...