support custom RetryConfiguration.getOrder() via @EnableRetry like @EnableAsync

[quaff]

@EnableRetry(order = -1)
@Configuration
public class RetryConfiguration {

}

configure @retryable before @transactional, so we can handle transaction with stateless @retryable, is stateful necessary anymore?

[headstar]

Is it correct to say that the transactional advisor and retryable advisor are unordered in the snippet below? (using @EnableRetry to configure retries).

@Transactional
@Retryable
@Service
public class FooService {
}

[quaff]

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;
    }

}

[headstar]

Ok, thanks.

[aartigao]

Hey, I'm looking for this feature. Are there any plans on implement it?

[quaff]

ping

[DieterVDW]

Pong!

Is this project still being maintained?

this feature would be very nice to handle @transactional

[yoorick]

+1 for this feature.

We have multiple advisors in our project, and a MethodInvocation usually consists of a chain of two or more MethodInterceptors, and a particular order of them is important.

Now we have to use an approach similar to what @quaff showed above.

[wtritch]

In case others are still having this issue, we ran into a problem using a @Backoff annotation in a @Retryable @Transactional-annotated method. The @Backoff annotation includes an @Import(RetryConfiguration.class) which leads to double-registering retry AOP Advice (one for the class extending RetryConfiguration, and one for the imported RetryConfiguration.)

After some mucking around with Spring's configuration loading we decided on manually setting the RetryConfiguration order in a @PostConstruct which needs to be executed PRIOR to instantiating any advised beans. (Once a bean is advised the advice order is locked.)

@Configuration
@Order(Ordered.HIGHEST_PRECEDENCE)
@EnableRetry
public class OrderRetryConfiguration {

    @Autowired
    public RetryConfiguration retryConfiguration;

    @PostConstruct
    public void postConstruct() {
        this.retryConfiguration.setOrder(Ordered.LOWEST_PRECEDENCE - 1);
    }
}

[philippthiele]

In case others are still having this issue, we ran into a problem using a @Backoff annotation in a @Retryable @Transactional-annotated method. The @Backoff annotation includes an @Import(RetryConfiguration.class) which leads to double-registering retry AOP Advice (one for the class extending RetryConfiguration, and one for the imported RetryConfiguration.)

After some mucking around with Spring's configuration loading we decided on manually setting the RetryConfiguration order in a @PostConstruct which needs to be executed PRIOR to instantiating any advised beans. (Once a bean is advised the advice order is locked.)

@Configuration
@Order(Ordered.HIGHEST_PRECEDENCE)
@EnableRetry
public class OrderRetryConfiguration {

    @Autowired
    public RetryConfiguration retryConfiguration;

    @PostConstruct
    public void postConstruct() {
        this.retryConfiguration.setOrder(Ordered.LOWEST_PRECEDENCE - 1);
    }
}

@wtritch
You seem to be correct, using backoff breaks @retryable in combination with @transactional. The Configuration you linked above does not fix that for me though.

[flozano]

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.

[quaff]

@garyrussell Could you take a look at this?