Spring Batch: пропуск при записи элемента

Question

Пружинная документация (стр. 46, раздел: 5.1.7) гласит:

По умолчанию, независимо от повторных попыток или пропуска, любые исключения, выданные из ItemWriter, вызовут откат транзакции, контролируемой Step. Если пропуск настроен, как описано выше, исключения, выданные из ItemReader, не вызовут откат.

Мой интервал коммита установлен на 10. Так что я понимаю, что вышеизложенный абзац таков: если они ошибочны при чтении 7-й записи из фрагмента из 10, элемент будет пропущен, а правильные 9 записей будут отправлены вперед itemReader ,

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

Однако, когда я включаю ошибку, выданную в моем skipPolicy, itemWriter записывает оставшиеся 9 записей в базу данных, пропуская ошибочную. Это противоречит тому, что упомянуто выше.

Может ли кто-нибудь объяснить, пожалуйста, понятие "пропустить во время записи элемента".

Кроме того, даже если выдается одна ошибка, я получаю следующее:

SkipCount как -1 дважды, затем как 0 один раз, и снова -1 один раз в моем методе shouldSkip (Object, Throwable). - Я не понимаю этого поведения.

Также количество откатов равно 2 - что это значит? почему это 2?

---

@ michael Можно ли было бы объяснить поведение, используя некоторый сценарий !!

как «Я читаю 20 записей из файла и записываю в базу данных после некоторой обработки. У меня есть политика пропуска для некоторого исключения. Что произойдет, если исключение возникнет во время - чтение, обработка, запись - как фрагменты будут зафиксированы, как работает повтор по умолчанию, как будет обновляться счет и т. д. и т. д. ... "

Это действительно будет для меня большой помощью, так как я все еще путаюсь с поведением ..

Answer 1

Из описания вашего варианта использования кажется, что вы смешиваете разные понятия.

Вы описываете сценарий пропуска , но, похоже, ожидаете, что пропуск должен работать как без отката *Сценарий 1006 *.

из документации партии пружин

skip :

ошибки, обнаруженные при обработке, не должныприведет к ошибке шага, но вместо этого следует пропустить

против без отката :

Если пропуск настроен, как описано выше, исключения выдаются изItemReader не вызовет откат.

в моих собственных словах пропустить означает:

Если при выполнении шага возникает ошибка во время чтения / обработки / записи, текущий чанк будет откатан икаждый элемент чанка читается / обрабатывается / пишется индивидуально - без плохого элемента.В основном Spring Batch возвращается к частоте коммитов 1 для плохого чанка и возвращается к указанной частоте коммитов после плохого чанка.

Также отсчет отката равен 2 - что это значит?почему это 2?

от B.5.BATCH_STEP_EXECUTION

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

(подчеркните мой)

Также, несмотря на то, что выдается одна ошибка, я получаю следующее:

SkipCount как -1 дважды, затем как 0 один раз, и снова -1 один раз в моем методе shouldSkip (Object, Throwable).- Я не получаю такого поведения.

Я попробовал простую работу с пропуском с обоими стилями конфигурации, skip-policy и skip-limit с skippable-exception, оба работали одинаково в отношении отката и пропускаcount

(метаданные шага в порядке, но если Skip (...) кажется вызванным намного больше, чем ожидалось)

Answer 2

Я хотел бы объяснить одну проблему, которую вы упомянули:

SkipCount как -1 дважды, затем как 0 один раз и снова -1 один раз в моем методе shouldSkip (Object, Throwable).- Я не понимаю этого поведения.

Я не знаю, на какую сигнатуру метода shouldSkip() вы ссылаетесь, но в моем интерфейсе SkipPolicy есть только один метод со следующей сигнатурой:

boolean shouldSkip(Throwable t, int skipCount) throws SkipLimitExceededException;

Метод должен решить, следует ли пропускать Exception e с учетом skipCount или нет.

К сожалению, программисты Spring Batch неправильно используют этот метод , чтобы проверить, является ли исключение пропускаемым вобщий независимо от текущего числа пропусков .Вот почему есть несколько вызовов этого метода с параметром skipCount, установленным на -1.

Так что просто не удивляйтесь поведению, которое вы видели.