From 852531300355db766b53114e3b3d1b27d60ea5e5 Mon Sep 17 00:00:00 2001 From: dsyer Date: Thu, 2 Oct 2008 19:04:17 +0000 Subject: [PATCH] Tweak retry docs for 2.0m2 --- docs/src/site/docbook/reference/retry.xml | 69 ++++++++++++----------- 1 file changed, 35 insertions(+), 34 deletions(-) diff --git a/docs/src/site/docbook/reference/retry.xml b/docs/src/site/docbook/reference/retry.xml index 413c6e041..09262c2c9 100644 --- a/docs/src/site/docbook/reference/retry.xml +++ b/docs/src/site/docbook/reference/retry.xml @@ -94,8 +94,9 @@ Foo result = template.execute(new RetryCallback() { public Foo doWithRetry(RetryContext context) { // business logic here }, - new RecoveryCallback() { - // recover logic here + new RecoveryCallback() { + Foo recover(RetryContext context) throws Exception { + // recover logic here } });]]>If the business logic does not succeed before the template decides to abort, then the client is given the chance to do @@ -143,42 +144,42 @@ Foo result = template.execute(new RetryCallback() { RetryContextCache with a cluster cache of some sort (even in a clustered environment this might be overkill). -Part of the reponsibility of the - RetryOperations is to recognise the failed - operations when they come back in a new execution (and usually wrapped - in a new transaction). To facilitate this, Spring Batch provides the - RetryState abstraction. This works in - conjunction with a special execute methods in - the RetryOperations. + Part of the reponsibility of the + RetryOperations is to recognise the failed + operations when they come back in a new execution (and usually wrapped + in a new transaction). To facilitate this, Spring Batch provides the + RetryState abstraction. This works in conjunction + with a special execute methods in the + RetryOperations. - The way the failed operations are recognised is by identifying - the state across multiple invocations of the retry. To identify the - state the user can provide an RetryState - object, and this is responsible for returning a unique key identifying - the item. The identifier is used as a key in the - RetryContextCache. + The way the failed operations are recognised is by identifying the + state across multiple invocations of the retry. To identify the state + the user can provide an RetryState object, and + this is responsible for returning a unique key identifying the item. The + identifier is used as a key in the + RetryContextCache. - - Be very careful with the implementation of - Object.equals() and Object.hashCode() in - the key returned by RetryState. The best - advice is to use a business key to identify the items. In the case - of a JMS message the message ID can be used. - + + Be very careful with the implementation of + Object.equals() and Object.hashCode() in the + key returned by RetryState. The best advice is + to use a business key to identify the items. In the case of a JMS + message the message ID can be used. + - When the retry is exhausted there is also the option to handle - the failed item in a different way, instead of calling the - RetryCallback (which is presumed now to be - likely to fail). Just like in the stateless case, this option is - provided by the RecoveryCallback, which can be - provided by passing it in to the execute method - of RetryOperations. + When the retry is exhausted there is also the option to handle the + failed item in a different way, instead of calling the + RetryCallback (which is presumed now to be likely + to fail). Just like in the stateless case, this option is provided by + the RecoveryCallback, which can be provided by + passing it in to the execute method of + RetryOperations. - The decision to retry or not is actually delegated to a regular - retry policy, so the usual concerns about limits and timeouts can be - injected through the RetryPolicy (see - below). - + The decision to retry or not is actually delegated to a regular + retry policy, so the usual concerns about limits and timeouts can be + injected through the RetryPolicy (see + below). +