Transactionssenior8+ years

`placeOrder()` is `@Transactional` (REQUIRED) and calls `audit.logAttempt()` on another bean, which is `@Transactional(propagation = REQUIRES_NEW)` so the audit row survives a failed order. Under load, with a pool of 10 connections, requests start hanging for 30 seconds and then failing with a connection-timeout error, while the database is nearly idle. Walk through what REQUIRES_NEW actually does and why this happens.

REQUIRES_NEW does not share the caller's connection. It suspends the outer transaction, which means parking its EntityManager and connection (still open, not returned to the pool, because returning it would mean ending a transaction nobody asked to end), and then takes a second connection from the pool for the inner transaction. Each request therefore needs two connections at the moment it reaches logAttempt(). With ten requests in flight, all ten can each hold their outer connection and each wait for a second one that can only come from another request's outer connection, which none of them will release until they get their second. Nobody progresses; each waits for the pool's connection timeout (30 seconds by default in HikariCP) and fails. The database is idle because the deadlock is in the pool, not in the database.

The lesson behind it →

PreviousA migration `V5__add_index_on_orders.sql` has already run in production. A follow-up PR notices the index is on the wrong column and fixes the column name inside `V5`. The next deploy fails before the application starts. What exactly did Flyway check, and what should the PR have done instead? When is `flyway repair` the right tool?Next A long-running `@Transactional` job loads an `Account`, does some work, then re-runs a JPQL query for the same account "to get the latest balance" — the SQL shows in the log — and changes its `status`. Meanwhile another request committed a new balance. After the job commits, that other request's balance change is gone. Explain every step, and how `@Version` changes the outcome.