57 lines
5.0 KiB
HTML
57 lines
5.0 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:pls="http://www.w3.org/2005/01/pronunciation-lexicon" xmlns:ssml="http://www.w3.org/2001/10/synthesis" xmlns:svg="http://www.w3.org/2000/svg"><head><title>Retry Policies</title><link rel="stylesheet" type="text/css" href="docbook-epub.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"/><link rel="prev" href="ch09.xhtml" title="Chapter 9. Retry"/><link rel="next" href="ch09s03.xhtml" title="Backoff Policies"/></head><body><header/><section class="section" title="Retry Policies" epub:type="subchapter" id="retryPolicies"><div class="titlepage"><div><div><h2 class="title" style="clear: both">Retry Policies</h2></div></div></div><p>Inside a <code class="classname">RetryTemplate</code> the decision to retry
|
||
or fail in the <code class="methodname">execute</code> method is determined by a
|
||
<code class="classname">RetryPolicy</code> which is also a factory for the
|
||
<code class="classname">RetryContext</code>. The
|
||
<code class="classname">RetryTemplate</code> has the responsibility to use the
|
||
current policy to create a <code class="classname">RetryContext</code> and pass
|
||
that in to the <code class="classname">RetryCallback</code> at every attempt.
|
||
After a callback fails the <code class="classname">RetryTemplate</code> has to
|
||
make a call to the <code class="classname">RetryPolicy</code> to ask it to update
|
||
its state (which will be stored in the
|
||
<code class="classname">RetryContext</code>), and then it asks the policy if
|
||
another attempt can be made. If another attempt cannot be made (e.g. a
|
||
limit is reached or a timeout is detected) then the policy is also
|
||
responsible for handling the exhausted state. Simple implementations will
|
||
just throw <code class="classname">RetryExhaustedException</code> which will cause
|
||
any enclosing transaction to be rolled back. More sophisticated
|
||
implementations might attempt to take some recovery action, in which case
|
||
the transaction can remain intact.</p><div class="tip" title="Tip" epub:type="notice"><table style="border: 0; "><tr><td style="text-align: center; vertical-align: top; width: 25; " rowspan="2"><img alt="[Tip]" src="images/tip.png"/></td><th style="text-align: left; ">Tip</th></tr><tr><td style="text-align: left; vertical-align: top; "><p>Failures are inherently either retryable or not - if the same
|
||
exception is always going to be thrown from the business logic, it
|
||
doesn't help to retry it. So don't retry on all exception types - try to
|
||
focus on only those exceptions that you expect to be retryable. It's not
|
||
usually harmful to the business logic to retry more aggressively, but
|
||
it's wasteful because if a failure is deterministic there will be time
|
||
spent retrying something that you know in advance is fatal.</p></td></tr></table></div><p>Spring Batch provides some simple general purpose implementations of
|
||
stateless <code class="classname">RetryPolicy</code>, for example a
|
||
<code class="classname">SimpleRetryPolicy</code>, and the
|
||
<code class="classname">TimeoutRetryPolicy</code> used in the example
|
||
above.</p><p>The <code class="classname">SimpleRetryPolicy</code> just allows a retry on
|
||
any of a named list of exception types, up to a fixed number of times. It
|
||
also has a list of "fatal" exceptions that should never be retried, and
|
||
this list overrides the retryable list so that it can be used to give
|
||
finer control over the retry behavior:</p><pre class="programlisting">SimpleRetryPolicy policy = new SimpleRetryPolicy();
|
||
// Set the max retry attempts
|
||
policy.setMaxAttempts(5);
|
||
// Retry on all exceptions (this is the default)
|
||
policy.setRetryableExceptions(new Class[] {Exception.class});
|
||
// ... but never retry IllegalStateException
|
||
policy.setFatalExceptions(new Class[] {IllegalStateException.class});
|
||
|
||
// Use the policy...
|
||
RetryTemplate template = new RetryTemplate();
|
||
template.setRetryPolicy(policy);
|
||
template.execute(new RetryCallback<Foo>() {
|
||
public Foo doWithRetry(RetryContext context) {
|
||
// business logic here
|
||
}
|
||
});</pre><p>There is also a more flexible implementation called
|
||
<code class="classname">ExceptionClassifierRetryPolicy</code>, which allows the
|
||
user to configure different retry behavior for an arbitrary set of
|
||
exception types though the <code class="classname">ExceptionClassifier</code>
|
||
abstraction. The policy works by calling on the classifier to convert an
|
||
exception into a delegate <code class="classname">RetryPolicy</code>, so for
|
||
example, one exception type can be retried more times before failure than
|
||
another by mapping it to a different policy.</p><p>Users might need to implement their own retry policies for more
|
||
customized decisions. For instance, if there is a well-known,
|
||
solution-specific, classification of exceptions into retryable and not
|
||
retryable.</p></section><footer/></body></html> |