Persistence contextsenior8+ years

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.

Three things combine. The re-query did run (the SQL is in the log), but the account was already managed, and the persistence context always hands back the managed instance for a row it already holds, discarding the fresh values the query read. So the job still has the old balance in memory. At flush, dirty checking sees status changed and writes an UPDATE, and Hibernate's default UPDATE sets every mapped column, including the stale balance, so the other request's committed change is overwritten. Nobody gets an error. With a @Version column, Hibernate adds where version = ? with the version it loaded; the other request's commit already bumped it, the UPDATE matches zero rows, and the job fails with ObjectOptimisticLockingFailureException instead of silently erasing someone else's write.

The lesson behind it →

Previous`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.End of setBack to Spring Data JPA and Hibernate

More on Persistence context

A `@Transactional` service method loads an `Author`, calls `setName(...)`, and returns. There is no `save()` anywhere, yet the log shows `update Author set name=? where id=?`. Where did that UPDATE come from, and is adding `repository.save(author)` "to be safe" a good idea?A service returns an `Order`, and the controller calls `order.getLines()` and gets `LazyInitializationException: could not initialize proxy - no Session`. One teammate suggests making `lines` EAGER; another says just keep `spring.jpa.open-in-view=true`. What is the exception actually telling you, and what is the right fix?