Избегайте перекрытия таймера в расписании EJB, запущенном внутри wildfly

У меня есть расписание таймера EJB в одноэлементном EJB, работающем внутри Wildfly 10.10:

@Singleton
@Startup
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class MySingletonBean {

    public method() {
        //uses synchronization primitives to fine control the concurrent access
    }

    @Schedule(hour = "*", minute = "*", second = "*", persistent = false)
    public void update() {
        //each 120 seconds update method timeouts and the overlapping/log message occurs
    }
}

Задача внутри модели update() выполняется плавно, тратя в основном менее 1 секунды. Однако каждые 2 минуты, из-за потребностей бизнеса, время ожидания метода расходуется более 1 секунды.

Эта проблема:

Каждые 2 минуты wildfly выводит сообщение журнала, например:

(EJB по умолчанию - 1) WFLYEJB0043: предыдущее выполнение timer [] все еще выполняется, пропуская это перекрывающееся запланированное выполнение в: .

Для меня ясно, что означает это сообщение: предыдущий таймер не завершился до следующего запуска и произошло перекрытие.

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

Мои вопросы:

1 - Как отказаться от следующего расписания в случае, когда таймер работает медленно, избегая дублирования / одновременного обновления?

2 - Как избежать сообщения журнала, если невозможно отменить перекрывающийся график?

Кстати, я думал о том, чтобы разбить метод обновления на два разных графика (1 секунда и 120 секунд). Но перерыв метода обновления подразумевает перерыв всей структуры данных при обновлении, каким-то сложным и незаметным, по крайней мере, на данный момент.

Любая помощь приветствуется!

2 ответа

Я согласен с dgebert, потому что ConcurrencyManagement по умолчанию управляется контейнером, а блокировка по умолчанию - запись, если у вас нет кластера. в кластере каждый узел имеет собственный синглетон и управление блокировками. если вы не сконфигурируете центральную базу данных для обслуживания таймера, все узлы будут выполнены и вызовут параллельные проблемы в недопустимой структуре данных.

Какой боб ваш "таймер"? Я думаю, что сделать это @Singleton может быть достаточно для вашего случая. Если это будет Синглтон, нет способа получить доступ к методу более чем одним потоком.

Другие вопросы по тегам