Spring Batch: Multi-Threaded Steps
Spring Batch: Multi-Threaded Steps
Learn more about Spring Batch multi-threaded steps.
Join the DZone community and get the full member experience.Join For Free
In this article, we'll show how to create multi-threads for the step during execution.
The Spring TaskExecutor Abstraction
Spring 2.0 introduces a new abstraction for dealing with executors. Executors are the Java 5 name for the concept of thread pools. The "executor" naming is due to the fact that there is no guarantee that the underlying implementation is actually a pool; an executor may be single-threaded or even synchronous. Spring’s abstraction hides implementation details between Java SE 1.4, Java SE 5, and Java EE environments.
You may also like: [DZone Refcard] Spring Batch
TaskExecutor interface is identical to the
java.util.concurrent.Executor interface. In fact, its primary reason for existence was to abstract away the need for Java 5 when using thread pools. The interface has a single method
execute(Runnable task) that accepts a task for execution based on the semantics and configuration of the thread pool.
TaskExecutor was originally created to give other Spring components an abstraction for thread pooling where needed. Components such as the
AbstractMessageListenerContainer, and Quartz integration all use the
TaskExecutor abstraction to pool threads. However, if your beans need thread pooling behavior, it is possible to use this abstraction for your own needs.
There are a number of pre-built implementations of
TaskExecutor included with the Spring distribution. In all likelihood, you shouldn’t ever need to implement your own.
SimpleAsyncTaskExecutor: This implementation does not reuse any threads, rather it starts up a new thread for each invocation. However, it does support a concurrency limit, which will block any invocations that are over the limit until a slot has been freed up. If you are looking for true pooling, see the discussions of
SyncTaskExecutor: This implementation doesn’t execute invocations asynchronously. Instead, each invocation takes place in the calling thread. It is primarily used in situations where multi-threading isn’t necessary such as simple test cases.
ConcurrentTaskExecutor: This implementation is an adapter for a
java.util.concurrent.Executorobject. There is an alternative,
ThreadPoolTaskExecutor, that exposes the
Executorconfiguration parameters as bean properties. It is rare to need to use the
ConcurrentTaskExecutor, but if the
ThreadPoolTaskExecutorisn’t flexible enough for your needs, the
ConcurrentTaskExecutoris an alternative.
SimpleThreadPoolTaskExecutor: This implementation is actually a subclass of Quartz’s
SimpleThreadPool, which listens to Spring’s lifecycle callbacks. This is typically used when you have a thread pool that may need to be shared by both Quartz and non-Quartz components.
ThreadPoolTaskExecutorThis implementation is the most commonly used one. It exposes bean properties for configuring a
java.util.concurrent.ThreadPoolExecutorand wraps it in a
TaskExecutor. If you need to adapt to a different kind of
java.util.concurrent.Executor, it is recommended that you use a
WorkManagerTaskExecutor :CommonJ is a set of specifications jointly developed between BEA and IBM. These specifications are not Java EE standards but are standard across BEA’s and IBM’s Application Server implementations.
This implementation uses the CommonJ
WorkManageras its backing implementation and is the central convenience class for setting up a CommonJ
WorkManagerreference in a Spring context. Similar to the
SimpleThreadPoolTaskExecutor, this class implements the
WorkManagerinterface and, therefore, can be used directly as a
Hope you enjoyed this post! Please leave your questions and comments below.
Opinions expressed by DZone contributors are their own.