Transactions Isolation

---
name: transactions-isolation
description: Choose isolation levels by the anomalies they prevent, understand locking versus MVCC, and retry on serialization failures. Use when transactional correctness matters or concurrency bugs appear under load.
---

# Transactions isolation

Isolation levels are a menu of guarantees against concurrency
anomalies, each trading correctness for concurrency. Most bugs come
from running at the default level without knowing which anomalies it
permits, then being surprised when two transactions interleave in a way
the code assumed impossible.

## Method

1. **Know the anomalies each level prevents.** Read
   uncommitted (dirty reads: almost never use). Read
   committed (prevents dirty reads; permits non-repeatable
   reads and phantoms: the common default). Repeatable read
   (prevents non-repeatable reads; MVCC implementations also
   prevent phantoms). Serializable (prevents all anomalies:
   transactions behave as if run one at a time). Pick the
   weakest level that prevents the anomalies your logic
   cannot tolerate, and know what your database's default
   actually permits.
2. **Match the level to the correctness need.** A
   read-modify-write that must not lose updates (increment
   a balance) needs repeatable-read-or-stronger, or
   explicit locking, or an atomic operation: at read
   committed, two transactions read the same value and one
   overwrites the other (the lost update). Financial and
   inventory invariants often need serializable; a
   dashboard read tolerates read committed. Decide per
   transaction.
3. **Understand your engine: locking vs MVCC.** MVCC
   databases (Postgres, Oracle, MySQL/InnoDB) give readers a
   consistent snapshot without blocking writers (readers do
   not block writers, writers do not block readers): the
   model most modern code assumes. Lock-based isolation
   blocks more. This difference changes how contention
   manifests and how you tune it (see deadlock-analysis,
   concurrency-tuning).
4. **Retry on serialization failures.** At serializable (and
   sometimes repeatable read), the database aborts a
   transaction that would violate isolation rather than
   blocking: your code must catch the serialization-failure
   error and retry the whole transaction (see
   timeouts-and-retries's idempotent-retry discipline). Code
   that treats these aborts as fatal errors breaks under
   load at stronger isolation; the retry loop is mandatory,
   not optional.
5. **Keep transactions short and focused.** Long
   transactions hold locks/snapshots longer, increasing
   contention, deadlocks, and (in MVCC) bloat from retained
   old versions. Never do I/O, user waits, or external calls
   inside a transaction (see spring-boot-discipline's same
   rule): open late, commit early, touch only what the unit
   of work needs.
6. **Use explicit locking and atomic ops deliberately.**
   `SELECT ... FOR UPDATE` to lock rows for a
   read-modify-write, `SKIP LOCKED` for work-queue
   patterns (see background-jobs), and atomic
   single-statement updates (`SET balance = balance + ?`)
   to avoid the read-modify-write race entirely. Often the
   cleanest fix is not a higher isolation level but an
   atomic operation.

## Boundaries

- Isolation is single-database; consistency across
  services or shards is a distributed-systems problem
  (see distributed-systems category, saga-pattern), not an
  isolation-level setting.
- Stronger isolation reduces concurrency and throughput;
  the right level is the weakest that is correct, not the
  strongest available (serializable everywhere is a
  performance choice you may not have meant to make).
- Default isolation levels vary by database (read committed
  in Postgres, repeatable read in MySQL); never assume,
  check what yours does, because the same code behaves
  differently across engines.