Duplicate writes observed when retrying JPA persist with IDENTITY after rollback

Direct answer

Spring Retry does not provide an optional idempotency-check callback that runs before each retry attempt, and Resilience4j Retry does not expose a built-in idempotency validation hook for manual transaction boundaries. Both are generic retry mechanisms. Ensuring a retried write is safe with JPA IDENTITY is application code responsibility, not framework configuration.

Confirmed facts

• With GenerationType.IDENTITY the primary key is assigned by the database on INSERT flush. After a rollback the in-memory entity instance retains the identifier that was assigned.
• Spring Retry @Retryable and RetryTemplate do not inspect JPA entity state and do not provide a built-in idempotency guard.
• Resilience4j Retry offers retry events and decorator composition, but no standard idempotency check tied to transactions. A pre-retry check can be implemented by user code only.

Likely explanation for the duplicate writes

The retry reuses the same entity instance. The first attempt flushes, the database assigns an id, then a transient exception occurs after the insert but before commit. The transaction rolls back, but the entity still holds the assigned id. On retry the same instance is persisted again, so JPA sees a non-null id and attempts to re-use it, leading to duplicate-key errors or unintended updates.

Safe pattern for IDENTITY retries

1. Move retry outside the transactional boundary. Put @Retryable on a non-transactional facade and let @Transactional start a fresh transaction on each attempt.
2. Never reuse the managed entity across attempts. Rebuild a fresh entity instance from the original input data for each retry, or explicitly null the id and detach/clear the persistence context before retry.
3. Verify proxy ordering. Ensure @Retryable wraps the @Transactional call so a new transaction is created per attempt, not a retry inside one transaction.
4. Add a safety net with a business natural key and a unique constraint so duplicate inserts are rejected by the database even if the application logic slips.

Using SEQUENCE or TABLE generation makes safe retry easier because the id can be allocated before the insert, but with IDENTITY the only reliable approach is a fresh entity and fresh persistence context per attempt.

One diagnostic detail that changes the recommendation

Confirm whether the transient exception occurs after the INSERT has been flushed and the id assigned but before commit. If the failure happens before flush, the id is still null and the current symptom would not occur. Log entity.getId() before persist and after rollback to verify id retention.