The library / Relational databases

A transaction is a boundary, not a magic shield

Separate atomicity from isolation and learn why two individually correct transactions can still surprise each other.

Two different questions

Atomicity asks whether a group of changes commits together. Isolation asks what concurrent transactions may observe and how their operations interact.

A transaction can be atomic without providing the strongest isolation behavior.

Consider a limited resource

Suppose a workshop has one remaining seat. Two sessions each read the availability, see one seat, and decide to reserve it.

Wrapping both sessions in transactions does not automatically make an application-level check safe. The outcome depends on the statements, locks, constraints, and isolation behavior.

Put the condition into the write

One useful pattern is a conditional update:

UPDATE workshops
SET seats_remaining = seats_remaining - 1
WHERE id = 42
  AND seats_remaining > 0;

Check the affected-row count. A result of one means this statement reserved a seat; zero means it did not. If you also insert a reservation record, place the update and insert in the same transaction and roll back when the conditional update fails.

This example assumes a workshops table and does not replace a complete reservation design, including idempotency and cancellation handling.

Test with two sessions

A useful isolation experiment needs genuinely overlapping work. Open two database sessions, write down the expected sequence, and deliberately pause between steps.

Observe whether a statement blocks, reads a snapshot, detects a conflict, or succeeds. Record the database engine and isolation level; names and defaults should not be assumed identical across products.

Design retries explicitly

Deadlocks and serialization failures can happen in a correct application. Retry the entire transaction when the engine and error type call for it, with a bounded policy.

Do not perform an irreversible external side effect inside a transaction that might be retried without an idempotency strategy.

What to remember

Use constraints for invariants where possible, make critical conditions part of writes, and test concurrency rather than reasoning only from a single-session script.

Keep exploring

Go deeper with the original documentation.

Official documentation
D
DBMinutes Editorial

Practical explanations of database systems, cloud services, and the engineering decisions between them.

AI-assisted content · Our editorial process

Keep the curiosity going.

Back to the library
A little learning goes a long way

Make room for a few good minutes.

Join the list for practical guides, thoughtful comparisons,
and ideas worth bringing to your next project.

Find your next answer

Search concepts, tools, and practical guides.