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