Можем ли мы в Spring batch использовать один и тот же объект ItemReader в нескольких заданиях, запускаемых планировщиком при весенней загрузке?

#java #spring #spring-boot #spring-batch

#java #spring #spring-boot #spring-batch

Вопрос:

У меня есть сценарий, в котором мне нужно прочитать данные из источника. Я создал пользовательский InputReader, поскольку источник отправляет данные json, сериализованные в objects, а возвращаемый тип — это интерфейс. Мне нужно иметь несколько заданий, поскольку содержимое будет варьироваться в зависимости от типа. Например, тип может быть PlacedOrder или RejectedOrder или CompletedOrder, все они реализуют интерфейс OrderDomain

Согласно приведенному выше примеру, если у меня может быть 3 задания с 3 разными шагами, но с одинаковым CustomItemReader, и тип будет PlacedOrder / RejectedOrder / CompletedOrder в качестве параметра задания. Я сомневаюсь, что «тип», полученный из JobParameter из StepExecution, будет иметь условие гонки, если 3 задания имеют 3 шага, но один и тот же объект CustomReader. Экземпляр reader создается в классе конфигурации в Spring boot, например:

 @Bean
public ItemReader<OrderDomain> orderReader()
{
    return new CustomOrderReader();
} 
  

Я могу создать «тип» в качестве глобальной переменной для использования в методе doRead(), но я сомневаюсь, будет ли он перезаписан другим потоком.

Какие варианты у меня есть? создайте несколько объектов пользовательского средства чтения, используя @Qualifier, а затем используйте их на соответствующих этапах, используя квалификатор?

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

Спасибо

Комментарии:

1. CustomOrderReader Потокобезопасен? Это все, от чего это зависит. Если это так, вы можете поделиться им. Если это не так, вам нужен отдельный экземпляр для каждого из них (например, путем создания прототипа bean).

2. @Kayaman, нет, это не так. Но даже если я сделаю это потокобезопасным, как мне убедиться, что параметр задания считывается из метода BeforeStep -> written to global var -> sync doRead(), считывает переменную с правильным значением?

3. Тогда нет смысла делать его потокобезопасным. Вы бы не хотели использовать глобальные переменные и синхронизацию вручную.

4. Спасибо @Kayaman, это то, что я хотел подтвердить.