Java Reference
In-Depth Information
As you can see, the code hasn't changed much, and the result is much more robust. The
RetryTemplate
itself is configured in the Spring context, although it's trivial to create in code. I declare it
in the Spring context only because there is some surface area for configuration when creating the object,
and I try to let Spring handle the configuration.
One of the more useful settings for the
RetryTemplate
is the
BackOffPolicy
in use. The
BackOffPolicy
dictates how long the
RetryTemplate
should “back off” between retries. Indeed, there's
even support for growing the delay between retries after each failed attempt to avoid lock stepping with
other clients attempting the same invocation. This is great for situations in which there are potentially
many concurrent attempts on the same resource and a race condition may ensue. There are other
BackOffPolicies
, including one that delays retries by a fixed amount.
<beans:bean id="retryTemplate" class="org.springframework.batch.retry.
➥
support.RetryTemplate">
<beans:property name="backOffPolicy" >
<beans:bean class="org.springframework.batch.retry.backoff.
➥
ExponentialBackOffPolicy"
p:initialInterval="1000" p:maxInterval="10000" p:multiplier="2" />
</beans:property>
</beans:bean>
You have configured a
RetryTemplate
's
backOffPolicy
so that the
backOffPolicy
will wait 1 second
(1000 milliseconds) before the initial retry. Subsequent attempts will double that value (the growth is
influenced by the multiplier). It'll continue until the
maxInterval
is met, at which point all subsequent
retry intervals will level off, retrying at a consistent interval.
AOP-based Retries
An alternative is an AOP advisor provided by Spring Batch that will wrap invocations of methods whose
success is not guaranteed in retries, as you did with the
RetryTemplate
. In the previous example, you
rewrote an
ItemWriter
to make use of the template. Another approach might be to merely advise the
entire
userRegistrationService
proxy with this retry logic. In this case, the code could go back to
the way it was in the original example, with no
RetryTemplate
!
<aop:config>
<aop:pointcut id="remote"
expression="execution(* com...*RetryableUserRegistrationServiceItemWriter.*(..))" />
<aop:advisor pointcut-ref="remote" advice-ref="retryAdvice" order="-1"/>
</aop:config>
<bean id="retryAdvice"
class="org.springframework.batch.retry.interceptor.
➥
RetryOperationsInterceptor"/>
9-9. Controlling Step Execution
Problem
You want to control how
step
s are executed, perhaps to eliminate a needless waste of time by
introducing concurrency or by executing
step
s only if a condition is
true
.
Search WWH ::
Custom Search