Использование FlatFileItemReader с TaskExecutor (безопасность потока)

Question

Есть много примеров, которые используют FlatFileItemReader вместе с TaskExecutor. Я предоставить образцы ниже (как с XML и Java Config):

• Using Oracle Coherence with Spring Batch
• Spring Batch Multithreading Example

Я использовал это мой сам с конфигурацией XML для больших томов CSV (GB размер) письма в базу данных с готовый JpaItemWriter. Кажется, что проблем нет даже без установки save-state = false или принятия какой-либо специальной обработки.

В настоящее время FlatFileItemReader задокументирован как небезопасный.

Мое предположение, что JpaItemWriter был «покрытие» проблему, сохраняющиеся Sets, т.е. коллекции, без дублей, если hashCode() и equals() освещали бизнес-ключ субъекта. Однако даже этого способа недостаточно для предотвращения дублирования из-за безопасного чтения и обработки без потоков.

Не могли бы вы пояснить: правильно ли/правильно/безопасно использовать готовый FlatFileItemReader в Tasklet, которому назначен TaskExecutor? Независимо от писателя. Если нет, то как объяснить теоретически отсутствие ошибок при использовании JPAItemWriter?

PS: Пример ссылки, которые я даю выше, использовать FlatFileItemReader с TaskExecutor, не упоминая при всех возможных проблем безопасности потоков ...

Answer 1

TL; DR Это безопасно использовать FlatFileItemReader с TaskExecutor при условии Writer является потокобезопасным. (Предполагая, что вы не занимаетесь перезапуском заданий, повторением шагов, пропуском и т. Д. В данный момент).

Update: Существует в настоящее время JIRA что официально подтверждает, что saveState должны быть установлены в false (т.е. отключить перезапуск), если кто-то хочет использовать FlatFileItemReader с TaskExecutor в потокобезопасных образом.

---

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

Spring Batch предоставляет некоторые реализации ItemWriter и ItemReader. Обычно они говорят в Javadocs, если они являются потокобезопасными или нет, или что вам нужно сделать, чтобы избежать проблем в параллельной среде . Если нет никакой информации в Javadocs, вы можете проверить реализацию, чтобы увидеть, есть ли состояние

Давайте обратимся ваши вопросы:

Не могли бы вы уточнить: это правильный/правильно/безопасный для использования из плоского FlatFileItemReader в Tasklet, который назначил TaskExecutor?Независимо от писателя. Если нет, то как мы можем объяснить теоретически отсутствие ошибок при использовании JPAItemWriter?

Утверждение «Рекорд автора» неверно. Используемый вами файл Writer должен быть потокобезопасным. JpaItemWriter является потокобезопасным, адаптируется к документам Java Java и может безопасно использоваться с FlatFileItemReader, который не является потокобезопасным. Объяснение того, как JpaItemWriter является потокобезопасным, сделает этот ответ длинным. Я рекомендую вам задать другой вопрос, если вы заинтересованы в том, как конкретные писатели справляются с безопасностью потоков. (Как уже упоминалось в Spring Batch документы, а)

PS: Пример ссылки, которые я даю выше, использовать FlatFileItemReader с TaskExecutor без упоминания на всех возможных проблем безопасности потоков ..

Если вы посмотрите на пример когерентности, вы увидите, что они явно изменяют CoherenceBatchWriter.java в . Рис. 6. Сначала они делают локальную переменную mapBatch, так что у нескольких потоков есть своя копия этого Map. Более того, если вы копаете дальше в API Coherence, вы должны найти, что возвращаемый NamedCache будет потокобезопасным.

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

---