Incorrect behaviour of RepositoryItemReader#jumpToItem() on restart

[spring-projects-issues]

Oleh Rohov opened BATCH-2526 and commented

After restart of batch step RepositoryItemReader reads last already processed item

https://github.com/olehrgf/spring-batch-repository-item-reader-bug

---

Affects: 3.0.7

Reference URL: https://github.com/olehrgf/spring-batch-repository-item-reader-bug

Referenced from: pull request #443

1 votes, 3 watchers

[spring-projects-issues]

Antoine Kapps commented

We faced that issue as well.

Restart operations do not work correctly, with 2 distinct problems :

1. As explained in the description, the first item read is the last successfully committed one. In other words, it is the one before the indicated index.
2. There are different transactions for "open()" and "read()" step operations. If the processed entity contains lazy-loaded associations, they fail to be retrieved by the processor (using Hibernate we get a LazyInitializationException).

I submitted a PullRequest addressing both aspects of the issue :

• I figured out that the unit tests for "jumpToItem()" and "setCurrentIndex()" were actually expecting the wrong value. They differ from the ones that would have been retrieved if "jumpToItem()" had not been overriden (AbstractItemCountingItemStreamItemReader).
• I refactored the method so that the page is fetched only by the "read()" operation. That is, not by "open() ← jumpToItem()". This way the entities are in the same transaction as where they are processed. Even if lazy loading might not be a very good idea in the context of batch processing, I feel like it is coherent to ensure a happy behavior anyway...

[spring-projects-issues]

Henrik Caesar commented

Also ran into this issue. Any plan on when this can be fixed? It has been open 1,5 years and there is even a PR with a fix provided by Antoine.

[fmbenhassine]

Resolved with #443 .