A concurrent update makes a flush fail with jakarta.persistence.OptimisticLockException. Describe a retry strategy that is actually correct — what state you must discard, what you must re-read, and when retrying is the wrong answer.

## Why the retry cannot be local The optimistic check runs at flush, which under the default flush mode usually means **at commit**. By then your service method has already returned, so the failure is not attached to a particular `setter` or `save` call — it fails the entire unit of work. Two consequences: - A `try/catch` around a repository call typically catches nothing. - Retrying "the update" is meaningless; you retry **the transaction**. ## Step 1 — throw the context away After any `PersistenceException`, JPA declares the persistence context's state undefined and the transaction rollback-only. Concretely: the identity map still holds the entity with a version Hibernate now knows is stale, the snapshots are wrong, and further flushes on that context are undefined behaviour. So you must roll back and **close** the `EntityManager` (or let the framework close it) before the next attempt. Reusing it is the single most common bug in hand-written retry code — it produces either an immediate second failure or, worse, an inconsistent write. ## Step 2 — re-read and re-apply *intent* The distinction that separates a correct retry from a silent data loss: ```java // WRONG: reinstates the value computed from stale data fresh.setBalance(staleComputedBalance); // RIGHT: re-run the operation against the fresh state fresh.withdraw(amount); ``` Optimistic locking exists to stop you overwriting someone else's change. If the retry writes the value you computed before, you have defeated it manually. Express the operation as a function of current state — a delta, a state transition, a recomputation — and re-run it on the freshly loaded entity. If the operation cannot be expressed that way, it probably should not be retried automatically at all. The re-read must also **re-validate**: the fresh state may now violate a precondition (the order was cancelled, the balance is insufficient), in which case the correct outcome is a business error, not another attempt. ## Step 3 — bound and space the attempts - **Cap attempts** (3–5). Every retry is a full transaction: connection, queries, work. - **Randomised backoff.** Without jitter, contending threads resynchronise and collide again; a few milliseconds of randomness measurably improves throughput. - **Observe it.** Count retries and failures-after-retry per operation. A rising retry rate is an early warning that a row has become a hotspot; a flat 0 tells you the mechanism is untested. - **Fail visibly.** After the cap, return a conflict to the caller (in an HTTP API, `409`) rather than pretending success. A practical detail: the retry must wrap the transactional call from **outside**, so the framework starts a genuinely new transaction and context. Calling a transactional method from within the same object or within the failed transaction reuses the doomed one. ## Step 4 — side effects The body of the failed attempt ran. If it sent an email, charged a card, or published an event outside the transaction, the retry duplicates it. Options: move side effects to after-commit hooks, make them idempotent with a key, or record intent transactionally (outbox) and let a separate process perform it. This is not optional detail — it is the difference between a retry and double-charging a customer. ## When retrying is the wrong answer - **Human-authored conflicts.** Two people edited the same record in a form. Re-running "set these fields" would overwrite the other person's edits by definition; the right response is to tell the user, ideally showing what changed. - **Non-recomputable operations.** If the new value depends on data the user saw, redoing it silently makes a decision on their behalf. - **Chronically hot rows.** If a single row is contended constantly — a global counter, an aggregate total — retries do not fix the design; they burn resources at increasing rates. Replace with an atomic `update ... set n = n + ?`, a per-partition row, or an append-and-aggregate model. - **Long transactions.** The longer the unit of work, the higher the chance of losing again; shorten the transaction before adding retries. ## Sketch ```java for (int attempt = 1; ; attempt++) { try { return tx.execute(() -> { // new EM + tx each time Account a = em.find(Account.class, id); a.withdraw(amount); // re-applied intent return a.getBalance(); }); } catch (OptimisticLockException e) { if (attempt == MAX) throw new ConflictException(id, e); sleep(backoffWithJitter(attempt)); } } ``` The important parts are that the lambda opens a *new* context, that the operation is re-derived from fresh state, that attempts are capped, and that exhaustion produces a conflict rather than a silent partial result.