How a Missing readOnly Flag Let JPA Silently Corrupt Production Data

A junior developer built a read-only internal API that unexpectedly corrupted production data due to a misunderstood JPA behavior. The developer used the @Transactional annotation while retrieving entities and modifying their fields temporarily to store intermediate processing state, without calling any explicit save or update method. Because the entities remained in a managed state within an active transaction, Hibernate's dirty-checking mechanism detected the field mutations and automatically issued UPDATE statements against the database at commit time. The fix was straightforward: replacing @Transactional with @Transactional(readOnly = true) instructs Hibernate to bypass dirty checking and flushing for that transaction context. The incident highlights how Hibernate's abstraction layer can produce serious side effects when developers lack a deep understanding of its lifecycle and persistence mechanisms.