Difference between StatefulRetryOperationsInterceptor and RetryOperationsInterceptor

Question

I went through the javadoc of both StatefulRetryOperationsInterceptor and RetryOperationsInterceptor but still didn't understand the difference between. Can anyone explain to me the difference between them and when to use them. Below is the explanation given on javado

RetryOperationsInterceptor

A MethodInterceptor that can be used to automatically retry calls to a method on a service if it fails. The injected RetryOperations is used to control the number of retries. By default it will retry a fixed number of times, according to the defaults in RetryTemplate. Hint about transaction boundaries. If you want to retry a failed transaction you need to make sure that the transaction boundary is inside the retry, otherwise the successful attempt will roll back with the whole transaction. If the method being intercepted is also transactional, then use the ordering hints in the advice declarations to ensure that this one is before the transaction interceptor in the advice chain.

StatefulRetryOperationsInterceptor

A MethodInterceptor that can be used to automatically retry calls to a method on a service if it fails. The argument to the service method is treated as an item to be remembered in case the call fails. So the retry operation is stateful, and the item that failed is tracked by its unique key (via MethodArgumentsKeyGenerator) until the retry is exhausted, at which point the MethodInvocationRecoverer is called. The main use case for this is where the service is transactional, via a transaction interceptor on the interceptor chain. In this case the retry (and recovery on exhausted) always happens in a new transaction. The injected RetryOperations is used to control the number of retries. By default it will retry a fixed number of times, according to the defaults in RetryTemplate.

Both the description looks same. Please respond your help is appreciated

Answer 1

The RetryOperationsInterceptor does everything within the context of the internal RetryTemplate. The execute method does not exit until retries are exhausted. No other work can occur on the calling thread until retries are complete.

If the advised method also has, for example, a transaction interceptor after the retry interceptor, the proxy is cloned on each doWithRetry call, allowing a new transaction to be started each time.

With the StatefulRetryOperationsInterceptor, the exception is re-thrown to the caller and the caller is responsible for calling again until retries are exhausted after which, either the recoverer is called, or an ExhaustedRetryException is thrown (by default).

Typical use of the stateful interceptor is with a message-driven application (e.g. JMS, RabbitMQ). Given that these systems can redeliver the failed message, and the redelivery can be later (based on other settings), other work can be processed on the calling thread before the failed request is retried.

IMPORTANT: The stateful interceptor has support for a rollbackClassifier; which indicates to the RetryTemplate that a particular request should be retried within the same transaction (i.e. the execute method does not throw the exception, it retries without starting a new transaction).

This only works when the retry interceptor is AFTER the transaction interceptor. Do not use this feature when the transaction interceptor is after the retry interceptor. In that case, the calling code must decide whether or not to retry the call, based on the exception type.