A practical guide to Spring transactions and concurrency control. It covers common @Transactional mistakes, the Lost Update problem, the difference between optimistic locking (@Version) and pessimistic locking (FOR UPDATE), and how to prevent deadlocks.
While we were adding an audit log, one login showed up under the wrong name: B logged in, but the record said A. This postmortem traces the ghost to a SecurityContext left behind in ThreadLocal by a filter that never called clearContext() on reused Tomcat threads.
Deleting certain spaces kept failing, yet the code was innocent. A WITH RECURSIVE query swept a tree of unknown depth, found a six-year-old legacy row that broke the delete logic’s assumption, and closed the case with zero deploys.
In this inventory system, the most important number, remaining stock, isn’t stored in any table. Here’s a dissection of the SQL that computes it on every read, and the store-versus-compute trade-off behind that design.
A list API took 15 seconds, and the debug log showed thousands of SQL statements. The JPA N+1 problem was only part of the bill: a bag restriction, Cartesian products, and an unpaged full load came with it.
An AI proposed unifying our data access layer on JPA before we could add an audit log. A few lines of grep showed the premise was wrong: every write already went through JPA. The same investigation showed I could no longer read our SQL, so I started relearning it.