Эта ветка старая, но я думаю, что проблемы все еще актуальны в наши дни.Начиная с EJB 3.1 существует атрибут, задающий постоянство EJB, как указано @ mikko-maunu , но я чувствовал, что он был смоделирован с двумя обязанностями:
- , чтобы иметь расписаниеконфигурация сохраняется после повторной инициализации системы;
- для подтверждения всех, в конечном итоге, сбоев при запуске системы при инициализации.
Я думаю, что описанные выше концепции должны были быть смоделированы независимо, поэтому мы могли бы сохранить таймер EJBв базе данных, а также более точно контролируют, что делать с ошибочно сработавшими триггерами при повторной инициализации системы, т. е. в случае их повторного запуска или игнорирования.
В противном случае может показаться неудобным наличие модуля задания на основе таймера EJB, где некоторые изони хранятся в БД, а другие нет, просто потому, что мы не хотим обновлять ранее пропущенные триггеры для задания, запланированного слишком часто, например, ежечасно.
Я заметил,в JBoss 7.1 / Java EE 7 хранение информации о расписании в базе данных можетпредварительно поддерживает централизованное управление кластерной конфигурацией вместо повторяющихся и независимых экземпляров непостоянных временных графиков.Но коллатеральный эффект заключается в том, что для задания, запускаемого много раз в день, все равномерно пропущенные триггеры запускаются сразу при повторной инициализации системы.
Чтобы получить более точный контроль над постоянным таймером EJB при перезапуске, мымог бы при методе @ PostConstruct проверить, не истек ли таймер getNextTimeout()
.Если таймер должен игнорировать пропущенные по времени триггеры, мы можем отменить старый таймер и немедленно создать новый, используя то же расписание scheduleExpression, поэтому будут рассматриваться только будущие триггеры.Это кажется очень полезным для таймеров, запланированных для запуска много раз в день.
Другой возможный, возможно, более простой подход, в методе @ Timeout , проверять, является ли время следующего выполнения таймера следующим, getNextTimeout()
, предшествует текущей дате и времени, а затем решите, следует ли обрабатывать или отбрасывать предыдущие триггеры с пропуском зажигания.