39 lines
2.6 KiB
HTML
39 lines
2.6 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>Stateless Retry Cannot Recover</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="apcs07.xhtml" title="Special Case: Transactions with Orthogonal Resources"/><link rel="next" href="go01.xhtml" title="Glossary"/></head><body><header/><section class="section" title="Stateless Retry Cannot Recover" epub:type="division" id="statelessRetryCannotRecover"><div class="titlepage"><div><div><h2 class="title" style="clear: both">Stateless Retry Cannot Recover</h2></div></div></div><p>The distinction between a stateless and a stateful retry in the
|
|
typical example above is important. It is actually
|
|
ultimately a transactional constraint that forces the distinction,
|
|
and this constraint also makes it obvious why the distinction
|
|
exists.
|
|
</p><p>We start with the observation that there is no way to skip an item
|
|
that failed and successfully commit the rest of the chunk unless we
|
|
wrap the item processing in a transaction. So we simplify the
|
|
typical batch execution plan to look like this:</p><pre class="programlisting">
|
|
0 | REPEAT(until=exhausted) {
|
|
|
|
|
1 | TX {
|
|
2 | REPEAT(size=5) {
|
|
|
|
|
3 | RETRY(stateless) {
|
|
4 | TX {
|
|
4.1 | input;
|
|
4.2 | database access;
|
|
| }
|
|
5 | } RECOVER {
|
|
5.1 | skip;
|
|
| }
|
|
|
|
|
| }
|
|
| }
|
|
|
|
|
| }
|
|
</pre><p>Here we have a stateless RETRY(3) with a RECOVER(5) path that kicks
|
|
in after the final attempt fails. The "stateless" label just means
|
|
that the block will be repeated without rethrowing any exception up
|
|
to some limit. This will only work if the transaction TX(4) has
|
|
propagation NESTED.</p><p>If the TX(3) has default propagation properties and it rolls back,
|
|
it will pollute the outer TX(1). The inner transaction is assumed by
|
|
the transaction manager to have corrupted the transactional
|
|
resource, and so it cannot be used again.</p><p>Support for NESTED propagation is sufficiently rare that we choose
|
|
not to support recovery with stateless retries in current versions of
|
|
Spring Batch. The same effect can always be achieved (at the
|
|
expense of repeating more processing) using the
|
|
typical pattern above.</p></section><footer/></body></html> |