Spring @Retryable With @Transactional

1. Overview

A key requirement for a reliable retry mechanism is ensuring that each individual retry runs in its own database transaction. If all attempts share a single transaction, we risk having the entire operation rolled back at the end — especially if an early attempt marks the transaction as rollback-only.

In this tutorial, we’ll look at different strategies for retrying a transactional method.

Specifically, we’ll explore two approaches that avoid this issue by guaranteeing a new transaction for every retry. First, we’ll use Aspect-Oriented Programming (AOP) with annotations such as @Transactional and @Retryable. After that, we’ll examine the programmatic alternative using Spring’s TransactionTemplate and RetryTemplate.

2. @Transactional and @Retryable

For the code samples, we assume a backend service for a blogging platform like Baeldung.

Let’s focus on a straightforward operation sequence such as retrieving a draft article, updating it, and saving the changes — all performed within a single database transaction:

@Component
class Blog {

    private final ArticleRepository articles;
    private final ArticleSlugGenerator slugGenerator;

    // constructor

    @Transactional
    public Article publishArticle(Long draftId) {
        Article article = articles.findById(draftId)
          .orElseThrow();

        article.setStatus(Article.Status.PUBLISHED);
        article.setSlug(slugGenerator.randomSlug());

        return articles.save(article);
    }

}

Due to circumstances such as network issues or race conditions, the logic above might fail, and we could lose the whole update. A simple way to improve resilience is to add a few extra retries.

Instead of building a custom retry mechanism from scratch, we can rely on spring-retry. So, let’s add the dependency to the pom.xml:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

Now, we can simply annotate the publishArticle() method with @Retryable. By default, this annotation retries the function two additional times, but we can override this behavior using the maxAttempts property:

@Transactional
@Retryable(maxAttempts = 5)
public Article publishArticle(Long draftId) {
    // ...
}

As discussed, we need to ensure that the retry aspect is invoked before the transactional one. To guarantee this, we override the order of Spring Retry and set it to LOWEST_PRECEDENCE. In particular, we do this directly inside the @EnableRetry annotation:

@EnableRetry(order = Ordered.LOWEST_PRECEDENCE)
@SpringBootApplication
public class RetryableTransactionalApplication {

    public static void main(String[] args) {
        SpringApplication.run(RetryableTransactionalApplication.class, args);
    }
}

Thus, the combination of @Transactional and @Retryable gives us a declarative yet powerful way to add resilience to database operations.

3. TransactionTemplate and RetryTemplate

If relying on the order in which aspects are invoked feels risky, we can use a programmatic alternative. Instead of using AOP, we can use the TransactionTemplate and RetryTemplate APIs. These templates give us full control over transaction boundaries and retry logic, making the execution behavior explicit.
Furthermore, we can either inject the beans directly or use the builder pattern to customize their behavior:

@Component
class Blog {

    private final ArticleRepository articles;
    private final ArticleSlugGenerator slugGenerator;
    private final TransactionTemplate transactionTemplate;
    private final RetryTemplate retryTemplate = new RetryTemplateBuilder()
      .maxAttempts(5)
      .fixedBackoff(Duration.ofMillis(100))
      .build();

    // constructor

    // ...

}

The way they work is fairly straightforward:

• The TransactionTemplate wraps a function and executes it within a new transaction every time. This ensures that each attempt runs in a completely fresh transaction, so failures in one attempt don’t affect the next.
• The RetryTemplate wraps a function and executes it according to the configured retry policy. In this example, the function is retried up to five (5) times with a fixed backoff of 100 milliseconds between attempts. If an attempt fails, the template automatically retries, invoking the function again.

By combining them, we can ensure that each retry runs in its own transaction and that retries follow the desired backoff strategy, all without relying on the order of AOP proxies:

public Article publishArticle_v2(Long draftId) {
    return retryTemplate.execute(retryCtx ->
        transactionTemplate.execute(txCtx -> {
     
            Article article = articles.findById(draftId)
              .orElseThrow();

            article.setStatus(Article.Status.PUBLISHED);
            article.setSlug(slugGenerator.randomSlug());

            return articles.save(article);
        })
    );
}

This way, we increase robustness without adding unnecessary complexity.

4. Conclusion

In this short article, we explored different ways to implement a retry policy when working with database transactions. The key takeaway is that each individual retry should run within its own database transaction to ensure consistency and avoid unwanted rollbacks.

To demonstrate, we used hands-on examples and leveraged the @Transactional and @Retryable annotations for a better understanding of the AOP approach. Finally, we looked at a programmatic alternative where TransactionTemplate and RetryTemplate enable us to explicitly define the scope and lifecycle of transactional and retryable code blocks, giving full control over retries and transactions.