JPA Optimistic Lock and the Retry Stampede Trap — 6 Scenarios @Version Cannot Cover Alone

• Why this article
• 1. The setup
• 2. S1 — Read-modify-write without @Version
• 3. S2 — @Version only, no retry
• 4. S3 — Retry stampede
• 5. S4 — Exponential + full jitter
• 6. AOP order — @Retryable outside @Transactional
• 7. S5 — Self Lost Update (DC-4)
  • JDBC stale read anti-pattern
  • JPA first-level cache == guarantee
• 8. Operational rules
• 9. Conclusion
• References
  • Official
  • Vlad Mihalcea
  • External
  • Sister posts

Backoff — wait time between retries

Backoff is the function that decides how long to wait before retrying. It is independent of retry count.

Without a cap (maxDelay), attempt 10 yields 100 × 2^10 ≈ 100s. Spring Retry uses @Backoff(maxDelay=10000) to bound this.

Jitter — spreading retry timestamps in time

Why exponential alone fails: 100 clients with the same backoff formula wait the same duration → retry simultaneously → collide again. The load curve becomes a repeating pulse.

t:    0ms ────── 100ms ────── 200ms ────── 400ms
      │             │              │              │
fail ─→ all wait 100ms → simultaneous retry → collide
        all wait 200ms → simultaneous retry → collide
        ...

Jitter randomizes the wait so retry timestamps spread across the time axis.

Full vs Equal trade-off: Full has shorter average wait but may produce wait=5ms — too short for the server to recover. Equal guarantees base/2 minimum but has half the spread.

Spring Retry’s jitter is NOT AWS Full Jitter

With @Backoff(random=true), Spring uses ExponentialRandomBackOffPolicy:

nextInterval = random_between(currentInterval, currentInterval × multiplier)

• AWS Full Jitter: random(0, base) — minimum 0
• Spring Retry: random(currentInterval, currentInterval × multiplier) — minimum guaranteed

In AWS taxonomy, this is a variant of Equal Jitter. Resilience4j’s IntervalFunction.ofExponentialRandomBackoff(initial, multiplier, randomizationFactor) follows a similar shape, with randomizationFactor (0~1) controlling spread amplitude.

Mapping back to this EXP

• S3 (backoff=0, no jitter): priority=29 — direct stampede
• S4 (exponential + random=true): priority=50 — 1.7× improvement

S4 fell short of 100 because of a combination: workers=100 high contention + maxAttempts=5 + delay=5ms (base too small for attempt-5 spread) + Spring’s Equal-like jitter (less spread than AWS Full). workers=20 or maxAttempts=10 should reach priority=100.

Interview tail questions

• “Why isn’t exponential alone enough?” → Synchronized retry waves.
• “Full vs Equal Jitter?” → Minimum-wait guarantee + spread amplitude.
• “Spring Retry default?” → random=false means no jitter. random=true is Equal-like.
• “What if maxDelay is missing?” → wait grows to minutes; can’t finalize within SLA.
• “10k clients — is jitter alone enough?” → No. You also need retry budget (token bucket) + circuit breaker + load shedding. Jitter only solves synchronization, not total retry load.

One-line summary

Annotations like @Transactional and @Retryable are all proxy-based AOP. They only kick in when the method is called from outside the class. Inside the same class, this.method() calls the raw object directly, bypassing the proxy — so the annotation silently does nothing. That is the self-invocation trap.

The trapping code

@Service
class RuleUpdateService {

    @Retryable(retryFor = OptimisticLockingFailureException.class,
               maxAttempts = 5,
               backoff = @Backoff(delay = 5, multiplier = 2.0, random = true))
    public void wrapper(Long id) {
        this.realLogic(id);   // bypasses the proxy. @Transactional won't fire.
    }

    @Transactional
    public void realLogic(Long id) {
        AutoReplyRule rule = repo.findById(id).orElseThrow();
        rule.incrementPriority();
        // No transaction was started, so there is no PersistenceContext.
        // Dirty checking never runs. UPDATE SQL is never issued.
    }
}

Call flow — where does the proxy actually do its job

When the caller invokes service.wrapper(id):

Caller (e.g. Controller)
   │
   │ service.wrapper(id)
   ▼
[Spring-generated proxy object]   ← @Retryable intercepts here, starts the retry
   │
   │ proxy → target.wrapper(id)
   ▼
[Original RuleUpdateService instance]
   │
   │ inside wrapper(), this.realLogic(id)
   │   ← 'this' refers to the original object, NOT the proxy.
   │     The interceptor chain is bypassed entirely.
   ▼
realLogic() runs without a transaction.

Two facts:

1. External → wrapper goes through the proxy → @Retryable works
2. this.realLogic() inside wrapper skips the proxy → @Transactional does nothing

Why every worker reported success while the balance stayed at 100

An earlier lock-comparison test fell into exactly this shape. 100 workers called the same method — zero OptimisticLockingFailureExceptions, every worker returned normally. But the DB was unchanged. 100% “success”, zero effect.

The mechanism:

1. The entry method went through the proxy, but the actual logic ran via self-invocation, so no transaction was started.
2. No transaction → no PersistenceContext → entity is not managed → dirty checking does not run.
3. No flush → no UPDATE SQL hits the DB.
4. No exception either; the in-memory object’s field is incremented and the method returns.
5. From the caller’s view: normal return → counted as a success.
6. From the DB’s view: only SELECTs landed, never an UPDATE.

[measurement]
totalMs: 549ms
successes: 100   ← 100% "success"
fails: 0
finalBalance: 100   ← but the balance never moved

Four ways to fix it

The measurement code in this EXP went with (a). For the deeper breakdown — TransactionInterceptor.invoke 6 steps, AOP Alliance MethodInvocation, and the 6 other annotations that fall into the same trap — see JPA Spring Mastery #7.