CompletionPolicy
), rules about how to deal with exceptions (
@@ -62,15 +103,21 @@
In general we try to dissuade users from extending framework
classes.
- The Java language doesn't give us as much flexibility to
+ The Java language doesn't give us as much
+ flexibility to
mark classes and interfaces as internal. Generally you can expect
- anything at the top level of the source tree in packages
+ anything at the top level of the
+ source tree in packages
org.springframework.batch.*
to be public, but not necessarily sub-classable. Extending our
concrete implementations of most
- strategies is discouraged in favour
+ strategies is
+ discouraged in favour
of a composition or forking
- approach.
+ approach. If your code can use only the
+ interfaces from Spring
+ Batch, that gives you the greatest possible
+ portability.
SchedulerFactoryBean
.
@@ -108,23 +158,27 @@
Use a scheduling tool. There are plenty of them out
there.
Examples: Quartz, Control-M, Autosys. Quartz
- doesn't have all the
+ doesn't have
+ all the
features of Control-M or
Autosys - it is supposed to be lightweight.
If you
- want something even more lightweight you can just
+ want something even more
+ lightweight you can just
use the OS
(cron, at, etc.).
Simple sequential dependencies can be implemented
using the
- job-steps model of Spring Batch, and the non-sequential features in
+ job-steps model of Spring Batch, and the non-sequential
+ features in
Spring Batch 2.0. We think
this is quite common. And
in fact it makes
it easier
- to correct a common mis-use of scehdulers
+ to correct a common mis-use
+ of scehdulers
- having
hundreds
of jobs configured, many of which are not
@@ -135,7 +189,7 @@
PartitionStep
).
There are a number of
technologies that could play a role here. The
essence is
- just a set of concurrent remote calls to distributed
+ just a set of concurrent remote calls
+ to distributed
agents that can handle some business processing. Since
the business
- processing is already typically modularised
+ processing is already typically
+ modularised
- e.g. input an item,
process it - Spring Batch can
strategise the distribution in a number
of ways. One
implementation that we have had some experience with
- (and have a prototype for) is a set of remote web services
- handling
- the
- business processing. We send a specific range
+ is a
+ set of remote web services
+ handling the
+ business processing.
+ We send a
+ specific range
of primary keys for
the inputs to each of
a number of
remote calls. The same basic
- strategy would work with
+ strategy would
+ work with
any
- of the Spring Remoting protocols (plain
+ of the Spring
+ Remoting protocols (plain
RMI,
HttpInvoker, JMS,
- Hessian etc.) with little more than a
+ Hessian etc.) with
+ little more than a
couple of
lines change in the
execution layer
@@ -194,10 +256,12 @@
leading to resilience and high
throughput. We are often faced with
mission-critical
- applications where audit trails are essential, and
+ applications
+ where audit trails are essential, and
guaranteed processing is demanded, but where there are
extremely
- tight limits on performance under load, or
+ tight limits on
+ performance under load, or
where high throughput
gives a competitive advantage.
Matt Welsh's work shows that a Staged
@@ -208,17 +272,21 @@
AQ, MQ, Tibco etc.) gives us a lot of
resilience out of the box.
There are particular benefits
- in a system where there is feedback
+ in a
+ system where there is feedback
between downstream
and upstream stages, so the number of consumers
can be
- adjusted to account for the amount of demand. So how
+ adjusted to
+ account for the amount of demand. So how
does this
fit into Spring Batch? The
spring-batch-integration
project has this pattern implemented in Spring Integration, and can
- be used to scale up the remote processing of any step with many
- items to process.
+ be used to scale up the remote processing of any
+ step with many
+ items to process. See in particular the "chunk" package, and the ItemWriter and ChunkHandler
+ implementations in there.