Spring Retry with Transactional

Found the answer here:https://docs.spring.io/spring/docs/5.0.6.BUILD-SNAPSHOT/spring-framework-reference/data-access.html#transaction-declarative-annotationsTable 2 indicates that the advice for the Transactional annotation has an order of Ordered.LOWEST_PRECEDENCE, which means that it is safe to combine Retryable with Transactional as long as you aren't overriding the order of the advice for either of those annotations. In other words, you can safely use this form:

@Retryable(StaleStateException.class)@Transactionalpublic void performDatabaseActions() {    //Database updates here that may cause an optimistic locking failure     //when the transaction closes}

If you want to test it independenty and be sure how it behaves then you may have @Transactional @Service, then another service that uses transaction one and just adds retries.

In this case, no matter how much you test you are relying on undocumented behaviour (how exactly annotations processing is ordered). This may change between minor releases, based on order in which independent Spring beans are created, etc etc. In short, you are asking for problems when you mix @Transactional and @Retry on same method.

edit: There is similar answered question https://stackoverflow.com/a/45514794/1849837 with code

@Retryable(StaleStateException.class)@Transactionalpublic void doSomethingWithFoo(Long fooId){    // read your entity again before changes!    Foo foo = fooRepository.findOne(fooId);    foo.setStatus(REJECTED)  // <- sample foo modification} // commit on method end

In that case it seems to be fine, because no matter what order is (retry then transaction, or transaction or retry) observable behaviour will be the same.

By default Spring Retry builds advice with the same LOWEST_PRECEDENCE order - take a look at the RetryConfiguration.However, there is a pretty simple way to override this order:

@Configurationpublic class MyRetryConfiguration extends RetryConfiguration {   @Override   public int getOrder() {      return Ordered.HIGHEST_PRECEDENCE;   }}

Make sure to omit the @EnableRetry annotation to avoid default RetryConfiguration be taken into account.