Spring Retry and @Transactional interaction for idempotent writes

Declarative Retry and Transactional Boundaries

In Spring Boot 3.x, combining @Retryable with @Transactional is often used to recover from transient failures. However, the ordering of these proxies determines whether a transaction is rolled back and restarted or if the retry occurs within the same existing transaction context.

When a service method performs a database write and subsequently fails, a retry attempt may lead to duplicate entries if the initial write was committed or if the idempotency of the operation is not managed by the database schema (e.g., via unique constraints).

There is uncertainty regarding the default proxy ordering when both annotations are present on the same method and how this affects the visibility of partial writes during a retry cycle.

• How does the default AOP proxy order impact the rollback of a transaction before a @Retryable attempt is triggered?
• What is the recommended configuration to ensure a transaction is fully rolled back before the next retry attempt begins?