Механизм отката для ориентированной на куски стратегии обработки Spring Batch

Question

Как мы все знаем, в Spring Batch используется обработка, ориентированная на куски, начиная с версии 2.0.

Означает ли это, что в случае возникновения исключения в модуле записи элемента диспетчер транзакций источника данных откатит весь блок или только связанный элемент?

На самом деле, я попробовал и увидел, что фреймворк откатывает весь кусок. Это не то, что мне нужно, потому что я не хочу, скажем, 499 элементов, которые были успешно обработаны, откатываться в блоке, состоящем из 500 элементов, когда последний элемент вызывает исключение.

Единственное решение, которое мне удалось найти, - добавить указанный ниже атрибут в мой тасклет. Однако я не уверен, что это правильно.

<batch:transaction-attributes propagation="NOT_SUPPORTED"/> 

Другое мнение заключалось в том, чтобы просто уменьшить размер куска до 1 (одного), но этот также не имеет особого смысла.

Возможно, Spring Batch не подходит для моей проблемной области. Если да, пожалуйста, скажите мне, чтобы я больше не боролся с подобным поведением, специфичным для фреймворка.

Любые предложения будут с благодарностью.

Answer 1

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

Answer 2

Вы можете открыть другую транзакцию в методе записи с помощью Propagation.REQUIRES_NEW для обработки этого варианта использования.

Answer 3

Ваше право: вся партия фрагментов откатывается.

Я столкнулся с той же проблемой и сделал следующее:

• адаптировать размер пакета в соответствии с базой данных (я использовал оператор пакета для сохранения своих обновлений). 25 была для нас хорошей ценностью: лучше, чем 1 (пакетные преимущества), не слишком много (огромные транзакции).
• перезапустите этот шаг ограниченное время: мы позволили повторное выполнение этой задачи максимум в 3 раза.

Это хорошо работало, потому что исправления могли происходить во время пакетной обработки (исправления, сделанные с помощью GUI).

В конце нашего процесса все данные, помеченные как неудавшиеся и повторенные 3 раза, были окончательно помечены как сбои в нашем пакетном отчете: затем требуется человеческое исправление или специальный процесс.