For a high-traffic service that reads and writes through an ORM, how do you decide between raising the database isolation level for all transactions, taking explicit locking reads on the contended rows, and enforcing correctness with an application-level version check?

## Frame the decision as scope, not strength The axis that matters is not weak-versus-strong but global-versus-targeted. Raising the isolation level applies to everything; a version check or a locking read applies to the operation that needs it. Since only a small fraction of operations in a typical service have a real concurrency invariant, targeted mechanisms let the rest run at full speed. ## What raising isolation globally really costs - Every transaction pays, including read-only endpoints that had no anomaly to prevent. - On engines that detect conflicts, transactions abort under load with serialization failures. Retrying is not optional, so every unit of work needs a bounded retry wrapper and idempotent effects. Teams often discover this after deployment, when tail latency spikes and unrelated endpoints start failing. - On engines that prevent anomalies by locking more, contention rises and deadlocks become more likely, which is the same problem in a different costume. - The semantics are vendor-specific. Two engines at the same named level behave differently, so the setting is not portable knowledge. - It is a single knob, so it cannot express "this one operation must not lose an update". That is why raising isolation is defensible mainly as a narrow, deliberate choice for a specific class of transactions — settlement, ledger closing, invariant checks spanning multiple rows — and rarely as a system-wide default. ## What each targeted mechanism is good at Version checks. The write carries a predicate on the version column, so a concurrent modification makes the statement affect zero rows and the ORM raises a conflict. No locks are held between read and write, so throughput and latency are unaffected in the common case. Cost: the loser redoes the work, so conflict rate must stay low and the work must be safely repeatable. Best for interactive edits, long request windows, and anything where holding a lock across user think time is unacceptable. Locking reads. The row is locked at load time and held to commit, so writers queue. Deterministic, no retry storm, and easy to reason about. Cost: lock hold time equals the rest of the request, deadlock risk when several rows are taken in inconsistent order, and a hard ceiling on throughput for that row. Best for short critical sections on genuinely hot rows, especially when a conflict would otherwise be near-certain. Single atomic statements. Removing the read removes the window. Relative updates, state transitions guarded by a predicate, and counters all fit. Cost: it bypasses the persistence context, so loaded entities go stale and must be refreshed, and the logic moves from Java into the statement. Best for the hottest, simplest operations — often the same rows that were driving your contention numbers. ## A decision procedure 1. Identify the invariant. Is it about one row (a balance, a status transition) or across rows (no overlapping bookings, a limit over a set)? Single-row invariants are served by the mechanisms above. Cross-row invariants need either a range lock, a stronger level, or remodelling so the invariant lives in one row or a unique constraint. 2. Estimate conflict probability from real traffic, not intuition. Low probability favours optimistic checks; high probability on few rows favours locking or atomic statements. 3. Estimate conflict cost. Cheap idempotent retries favour optimism; expensive or user-visible redo favours locking. 4. Check the window. If the read-to-write gap includes remote calls or user think time, locking is off the table and optimistic checking is the only honest option. 5. Only if steps 1 to 4 leave a gap should isolation be raised, and then scope it to the transactions that need it, with retry handling written before the change ships. ## Cross-cutting obligations Whichever mechanism you pick, the ORM-side recovery is identical: the failure marks the transaction for rollback and leaves the persistence context inconsistent, so recovery means discarding it, opening a new one, re-reading the current state, reapplying the intent, and retrying a bounded number of times with backoff. Retries must be bounded, because unbounded retries under contention amplify load precisely when the system is already struggling. Instrument the outcome. Count conflicts, lock waits and deadlocks per operation. Those numbers are a design signal: a hot row with a persistent conflict rate is telling you to split it — per-shard counters, an append-only event row summed later, or a queue that serialises the operation deliberately — rather than to keep tuning locks. ## The sentence to lead with Default isolation, targeted mechanisms, bounded retries, and measurement — and treat a persistent contention hotspot as a modelling problem, not a locking problem.