Revisit the concurrency model #4955
Description
The current approach to concurrency with a "parallel iteration" concept (based on TaskExecutorRepeatTemplate, ResultHolderResultQueue, RepeatSynchronizationManager, TransactionSynchronizationManager, etc) is not friendly to concurrent executions as it requires a lot of state synchronization at different levels (Step level with a semaphore, chunk level with ThreadLocal for execution contexts, and item level with locks). This results in several issues like maxItemCount not being honored in a multi-threaded step, inconsistent state when a transaction is rolled-back leading to optimistic locking issues, throttling issues, poor performance, etc. Here is a non exhaustive list of related issues:
- FlatFileItemRead isnt respecting the maxitemcounter [BATCH-2801] #805
- maxItemCount property is exceeded [BATCH-2516] #1085
- Multithreaded step reprocess chunk in violation of RetryPolicy [BATCH-2199] #1401
- Bad performances of multithreaded tasklet using chunks due to throttling algorithm [BATCH-2081] #1516
- A failing Item blocks processing of further item while using multi threaded step [BATCH-1832] #1757
- Deprecate throttle limit in favour of using similar features in TaskExecutor implementations #2218
- https://stackoverflow.com/questions/18262857
- https://stackoverflow.com/questions/62095234
v6 is a good opportunity to revisit the concurrency features provided out-of-the-box, which should be adapted to the new implementation of the chunk-oriented processing model introduced in #3950.