Spring/spring-batch
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[BATCH-424]: Incorporated some of Wayne's feedback

Browse Source
This commit is contained in:
dsyer
2008-03-14 14:56:23 +00:00
parent 099fd46c08
commit 1f608592fb
1 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/src/site/docbook/reference/retry.xml
View File

@@ -131,8 +131,7 @@ Object result = template.execute(new RetryCallback() {
<code>RetryOperations.execute()</code> method and potentially losing the <code>RetryOperations.execute()</code> method and potentially losing the
context that was on the stack. To avoid losing it we have to introduce a context that was on the stack. To avoid losing it we have to introduce a
storage strategy to lift it off the stack and put it (at a minimum) in storage strategy to lift it off the stack and put it (at a minimum) in
heap storage. For this purpose Spring Batch provides the heap storage. For this purpose Spring Batch provides a storage strategy
<classname>ItemReaderRetryPolicy</classname> and a storage strategy
<classname>RetryContextCache</classname>. The default implementation of <classname>RetryContextCache</classname>. The default implementation of
the <classname>RetryContextCache</classname> is in memory, using a the <classname>RetryContextCache</classname> is in memory, using a
simple <classname>Map</classname>. Advanced usage with multiple simple <classname>Map</classname>. Advanced usage with multiple
@@ -147,10 +146,9 @@ Object result = template.execute(new RetryCallback() {
<para>Part of the reponsibility of a stateful retry policy is to <para>Part of the reponsibility of a stateful retry policy is to
recognise the failed operations when they come back in a new recognise the failed operations when they come back in a new
transaction. To facilitate this in the commonest case where an object transaction. To facilitate this in the commonest case where an object
of some type (like a message or message payload) is being processed, (like a message or message payload) is being processed, Spring Batch
Spring Batch provides the provides the <classname>ItemReaderRetryPolicy</classname>. This works
<classname>ItemReaderRetryPolicy</classname>. This works in in conjunction with a special <classname>RetryCallback</classname>
conjunction with a special <classname>RetryCallback</classname>
implementation <classname>ItemReaderRetryCallback</classname>, which implementation <classname>ItemReaderRetryCallback</classname>, which
in turn relies on the user providing an in turn relies on the user providing an
<classname>ItemReader</classname> and an <classname>ItemReader</classname> and an
@@ -159,13 +157,17 @@ Object result = template.execute(new RetryCallback() {
writer.</para> writer.</para>
<para>The way the failed operations are recognised in this <para>The way the failed operations are recognised in this
implementation is by recognising the object that is returned from the implementation is by identifying the object that is returned from the
<classname>ItemReader</classname>. To recognise the item the user can <classname>ItemReader</classname>. To identify the item the user can
provide an <classname>ItemKeyGenerator</classname> strategy, either by provide an <classname>ItemKeyGenerator</classname> strategy, and this
is responsible for returning a unique key identifying the item. The
identifier is used as a key in the
<classname>RetryContextCache</classname>. An
<classname>ItemKeyGenerator</classname> can be provided either by
injecting it directly into the injecting it directly into the
<classname>ItemReaderRetryCallback</classname>, or by implementing the <classname>ItemReaderRetryCallback</classname>, or by implementing the
interface in the <classname>ItemReader</classname>, or by accepting interface in the <classname>ItemReader</classname>, or by accepting
the default which is to simply use the item to identify itself.</para> the default which is to simply use the item itself as a key.</para>
<para>When the retry is exhausted, because a stateful retry is always <para>When the retry is exhausted, because a stateful retry is always
in a fresh transaction, there is also the option to handle the failed in a fresh transaction, there is also the option to handle the failed
@@ -258,7 +260,7 @@ Object result = template.execute(new RetryCallback() {
The <classname>RetryOperationsInterceptor</classname> executes the The <classname>RetryOperationsInterceptor</classname> executes the
intercepted method and retries on failure according to the intercepted method and retries on failure according to the
<classname>RetryPolicy</classname> in the provided <classname>RetryPolicy</classname> in the provided
<classname>RepeatTemplate</classname>. </para> <classname>RepeatTemplate</classname>.</para>
<para>Here is an example of declarative iteration using the Spring AOP <para>Here is an example of declarative iteration using the Spring AOP
namespace to repeat a service call to a method called namespace to repeat a service call to a method called