-
Notifications
You must be signed in to change notification settings - Fork 512
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support custom RetryConfiguration.getOrder() via @EnableRetry like @EnableAsync #22
Comments
Is it correct to say that the transactional advisor and retryable advisor are unordered in the snippet below? (using @EnableRetry to configure retries).
|
Yes, you can do this <tx:annotation-driven order="0"/> @Configuration
public class RetryConfiguration extends
org.springframework.retry.annotation.RetryConfiguration {
@Override
public int getOrder() {
return -1;
}
} |
Ok, thanks. |
Hey, I'm looking for this feature. Are there any plans on implement it? |
ping |
Pong! Is this project still being maintained? |
this feature would be very nice to handle @transactional |
+1 for this feature. We have multiple advisors in our project, and a Now we have to use an approach similar to what @quaff showed above. |
In case others are still having this issue, we ran into a problem using a After some mucking around with Spring's configuration loading we decided on manually setting the RetryConfiguration order in a
|
@wtritch |
This issue looks important, any other workaround? right now I'm reverting to having a service decorator with manual handling of retries with retryTemplate, which is far from ideal. |
@garyrussell Could you take a look at this? |
Fixes #22 Configure `@Retryable` before `@Transactional`, so we can handle transaction with stateless retries
Interesting - for those of use waiting to go to Spring Retry 2.0.0 what is the advice to get correct operation of code like the following
It sounds like precedence wise we want Retry logic to have higher precedence in AOP? |
order value of EnableRetry should less than EnableTransactionManagement, like this
|
@quaff , you show the configuration exactly for a new upcoming version.
|
configure @retryable before @transactional, so we can handle transaction with stateless @retryable, is stateful necessary anymore?
The text was updated successfully, but these errors were encountered: