Кварцевые задания на нагрузку из БД фильтрации по групповым критериям

Question

В моем весеннем загрузочном приложении используется quartz стартер.Все созданные задания добавляются во время выполнения в БД.В БД используются разные сервисы, но задания могут обрабатываться только сервисами, которые заполняли БД заданиями.

При запуске любого сервиса мне нужно гарантировать, что только задания, созданные этим, будут добавлены в контекст кварцевых заданий.Мы можем обнаружить эти задания по указанным группам.

Вопросы:

1

Как управлять загрузчиком заданий с минимальными изменениями (используя готовое решение), фильтруя задания только поуказанная группа (разные группы не должны обрабатываться в этом контексте работы)?

2

Как зарегистрироваться только в кварцевом планировщике JobClasses, действительные для текущего сервиса?(Например, служба может поддерживать только задания googleRetry, но БД содержит fbRetry и connectedInRetry. Экземпляр должен загружать только задания googleRetry.) Я надеюсь, что он может управлять загрузкой заданий с другой стороны.

3

Я обнаружил в кварце DriverDelegate следующий метод

/**
 * <p>
 * Get the names of all of the triggers in the given group and state that
 * have misfired - according to the given timestamp.
 * </p>
 * 
 * @param conn
 *          the DB Connection
 * @return an array of <code>{@link
 * org.quartz.utils.Key}</code> objects
 */
List<TriggerKey> selectMisfiredTriggersInGroupInState(Connection conn,
    String groupName, String state, long ts) throws SQLException;

, но не использовал его.Я ожидаю, что он должен использоваться в специальном режиме восстановления (в случае восстановления фильтрации по группам в качестве примера), но без использования.Я пытался управлять CustomDelegate обновлением selectTriggersForRecoveringJobs с необходимой мне функциональностью, но в этом случае получал CURSOR issue.

Можно ли настроить режим восстановления кварца с помощью selectMisfiredTriggersInGroupInState, как?

Answer 1

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

spring:
  quartz:
    job-store-type: jdbc
    properties:
      org:
        quartz:
          thread-pool:
            thread-count: 5
          scheduler:
            instanceName: mailCluster

Имя экземпляра планировщика используется в разных таблицах в столбце SCHED_NAME. И это важное условие для фильтрации заданий \ триггеров во время загрузки из БД для экземпляра.