I am wondering how can I apply spring reactive to spring batch. How can I do it. And why should we apply spring reactive to spring security ? Why do I can apply to spring security but I cannot apply reactive to spring batch

CodePudding user response：

A reactive version of Spring Batch does not exist. Spring developers are discussing this implementation in this Github issue.

I want to mark the following comment which explains all the reasons.

Spring Batch and Reactive Streams

First of all, Reactive Streams are designed for data streams (infinite) while Spring Batch is a batch processing framework designed for fixed datasets (finite). In my opinion, this is already a fundamental mismtatch that can result in a non-natural integration between these two tools.

Now even if we try to introduce "reactive" in some way in Spring Batch, we need to be careful about several design choices. The following excerpt from the Spring Framework FAQ section is key:

For handlers to be fully non-blocking, you need to use reactive libraries throughout the processing chain,
all the way to the persistence layer.

Spring Framework even recommends to keep using the blocking model if the stack is partially reactive:

By all means, keep using Spring MVC if you are developing web apps that don't benefit from a non-blocking
programming model, or that use blocking JPA or JDBC APIs for persistence (typically in combination with
thread-bound transactions).

Based on these statements, for a web application to be fully reactive, the entire stack should be reactive, from the controller all the way down to the persistence layer. This is no different for batch applications, except that we obviously don't have controllers here, but the end-to-end job execution should be reactive. It does not make sense to have a "reactive non-blocking step" that interacts with a blocking job repository.

So to really benefit from this reactive story, the entire framework should be reactive, from batch artefacts (reader, processor, writer, listeners, etc) to infrastructure beans (job repository, transaction manager, etc). And to achieve that, a huge effort is needed:

• A reactive job repository implementation should be provided
• All APIs using PlatformTransactionManager (namely BatchConfigurer, Tasklet, StepBuilderHelper, etc ) should be updated to use the newly introduced org.springframework.transaction.TransactionManager interface. This is to be able to provide either a ReactiveTransactionManager or a classic PlatformTransactionManager as needed.
• All implementations of readers/writers should be updated to use non-blocking APIs (File IO, Database IO, etc)
• And many other changes

Moreover, the current chunk-oriented processing model is actually incompatible with the reactive paradigm. The reason is that ChunkOrientedTasklet waits for the chunkProcessor (processor writer) to process the whole chunk before reading the next chunk:

Chunk inputs = chunkProvider.provide();
chunkProcessor.process(inputs);

So this implementation should be adapted as well. And all these changes are required without even talking about the current concurrency model of Spring Batch (that is incompatible with the reactive paradigm) and the optimistic locking strategy used at the job repository level..

In my opinion, "reactive support" is not a feature we can introduce in Spring Batch, it actually requires a complete re-write of 80% of the framework (if not more). For all these reasons, I believe the cost/benefit of such integration is too high to be considered, but I'm open to be convinced otherwise.