How does Spring Retry integrate with Spring's @Transactional?

The interaction between @Retryable and @Transactional depends critically on the order of proxy application. If a method is annotated with both, the retry proxy must wrap the transaction proxy — not the other way around. This ensures that when a failure occurs, the transaction is fully rolled back before the next retry attempt begins in a fresh transaction.

Correct ordering (retry wraps transaction):

@Retryable(retryFor = TransientDataAccessException.class, maxAttempts = 3)
@Transactional
public void saveOrder(Order order) {
    orderRepository.save(order);
    inventoryService.deduct(order.getItemId());
}

When a TransientDataAccessException is thrown inside the transaction, the transaction rolls back, control returns to the retry proxy, which waits (per backoff policy) and re-invokes the method — starting a new transaction from scratch. This is correct behavior.

Wrong ordering (transaction wraps retry): If the transaction is the outer proxy and retry is inner, a failure inside the transaction puts it into a rollback-only state. The retry then re-invokes the inner method still inside the same poisoned transaction, which will fail again even if the underlying cause is resolved.

To ensure correct ordering, set @EnableRetry before @EnableTransactionManagement or explicitly set @EnableTransactionManagement(order = Ordered.LOWEST_PRECEDENCE) and rely on default retry advisor ordering.