{"id":82017,"date":"2026-09-08T12:03:39","date_gmt":"2026-09-08T06:33:39","guid":{"rendered":"https:\/\/tothenewone.online\/blog\/?p=82017"},"modified":"2026-10-27T23:14:59","modified_gmt":"2026-10-27T17:44:59","slug":"how-hibernate-turned-a-preview-into-a-write","status":"publish","type":"post","link":"https:\/\/tothenewone.online\/blog\/how-hibernate-turned-a-preview-into-a-write\/","title":{"rendered":"How Hibernate Turned a Preview into a Write"},"content":{"rendered":"

The bug that shouldn’t have existed<\/h1>\n

The report read like a riddle: edit a record, preview the impact (to confirm\/or not confirm), click Cancel, refresh \u2014 and the changes are still there. No error.<\/em><\/p>\n

Cancel is the one button whose entire job is to not do things \u2014 and yet the changes had been saved anyway.<\/p>\n

The app in question manages versioned plans<\/strong>: before a user approves a new plan version, we show a preview \u2014 “if you approve this, here’s what it will affect.<\/em>”\u00a0 That preview is where the trouble hid.<\/p>\n

\u00a0(The scenario below is anonymised, but the bug, cause and fix are exactly as they happened.)<\/em><\/p>\n

The Reproduction<\/h2>\n

Change a version’s dates, open the preview, hit Cancel<\/strong>, refresh \u2014 and the version shows the new dates and an APPROVED status, as if I’d saved.<\/p>\n

Here’s the twist that took me longest to see: the write never came from Cancel. Cancel is pure UI \u2014 it discards the form and never calls the server. The change\u00a0 was persisted one step earlier, when the preview asked the backend “what would this affect?” By the time I clicked Cancel, it was already committed, so Cancel had nothing left to undo.<\/p>\n

(And a preview should call the backend \u2014 only the database knows what’s related. The sin wasn’t the call; it was that a read had a write hiding inside it.)<\/p>\n

The SQL gave it away<\/h2>\n

No exception, no error page \u2014 so I stopped guessing and turned on the one witness that never lies:
\n\u00a0 logging.level.org.hibernate.SQL=DEBUG<\/code>
\nAnd there it sat, in the middle of a read<\/strong>:
\n\u00a0 update plan_version set start_date=?, status=? where id=?<\/code>
\nAn UPDATE I never wrote, fired during a preview. The reads were writing.<\/p>\n

What Hibernate was doing under the hood<\/h2>\n

When you load an entity inside a transaction, Hibernate keeps a snapshot of it and watches for changes \u2014 this is dirty checking<\/strong>. Change a field and the entity is\u00a0 dirty<\/em>. With FlushMode.AUTO (the default), Hibernate may flush pending changes before executing a query when it determines that the query could be affected by\u00a0 those changes \u2014 and it always flushes at commit. The intent is friendly: keep your query results consistent with what you’ve already changed in memory.<\/p>\n

So the sequence that bit me was:<\/p>\n

1.\u00a0\u00a0\u00a0\u00a0 The preview mutates managed entities in memory (APPROVED status, new dates, etc).<\/p>\n

2.\u00a0\u00a0\u00a0\u00a0 It runs a look-up to build the impact list.<\/p>\n

3.\u00a0\u00a0\u00a0\u00a0 Hibernate decides that query could be affected by the dirty entities, so it flushes them \u2014 writing the pretend changes for real.<\/p>\n

4.\u00a0\u00a0\u00a0\u00a0 The read-write transaction commits at the end of the request, sealing them.<\/p>\n

And this isn’t a Grails quirk (could be assumed from the given example in Grails). The persistence context, dirty checking and FlushMode.AUTO all live in\u00a0 Hibernate\u00a0 \u2014 Grails and Spring merely delegate to the same session. The identical bug reproduces in plain Spring + Hibernate or Spring Data JPA: a read-write\u00a0 @Transactional method that loads an entity, mutates it, then runs a query will flush that mutation just the same. (The one Grails-specific footnote is that its services are transactional by default, so you can be sitting in a read-write transaction without ever having asked for one.)<\/p>\n

Why save() wasn’t required<\/h2>\n

Here’s the offending method, boiled down. It’s Groovy, from a Grails service \u2014 and remember, Grails services run in a read-write transaction by default. Its job is display-only: take the plan the user is editing, simulate the proposed approval in memory, then query what that change would affect so the UI can render a preview.\u00a0 Notice there is no save(), no persist(), no flush() anywhere \u2014 which is exactly why the write is so surprising.<\/p>\n

\/\/ The snippets are Groovy, from a Grails service using GORM (Grails' data-access layer, which \r\n\/\/ runs on Hibernate underneath) \u2014 and Grails services run in a read-write transaction by default. \r\n\/\/ The behaviour is identical on any Grails\/Hibernate or Spring\/Hibernate stack.\r\n\r\n@Transactional                           \/\/ read-write \u2192 Hibernate flush mode AUTO\r\nclass PlanVersionService {\r\n\r\n    Preview buildPreview(Command command) {\r\n        \/\/ 1. Load managed entities \u2014 Hibernate's session now tracks them for changes.\r\n        def plan = planRepository.findById(command.planId)\r\n\r\n        \/\/ 2. \"Simulate\" the proposed change by mutating those managed entities in memory.\r\n        \/\/ We never call save() \u2014 in our heads this is just a harmless what-if.\r\n        def simulated = plan.versions.collect { version ->\r\n            if (version.id == command.versionId) {\r\n                version.startDate = command.startDate\r\n                version.status    = APPROVED       \/\/ \u2190 entity is now DIRTY (in memory only\u2026 we hope)\r\n            }\r\n            version\r\n        }.toSet()\r\n\r\n        \/\/ 3. Run a query to work out the impact.\r\n        \/\/ Because the transaction is read-write, AUTO flush fires BEFORE this SELECT \u2014\r\n        \/\/ Hibernate pushes the dirty entities from step 2 to the DB as a real UPDATE.\r\n        def affected = customRepository.findAffected(simulated, command)\r\n\r\n        \/\/ 4. Method returns \u2192 the read-write transaction commits \u2192 that UPDATE is now permanent.\r\n        return new Preview(affected)               \/\/ user hasn't confirmed anything yet\r\n    }\r\n}\r\n<\/pre>\n
The entities mutated in step 2 are managed<\/strong> \u2014 loaded inside the transaction and tracked by Hibernate’s persistence context. When step 3 runs a query, Hibernate\u00a0 may flush those pending changes first so the query sees a consistent picture, and “flush” means a real UPDATE. The transaction then commits it. save() was\u00a0 never required because the query did the writing for us.<\/p>\n
The one-line fix<\/h2>\n
The preview is display-only, so it should never have been in a read-write transaction in the first place. One annotation says so:<\/p>\n
@Transactional(readOnly = true)\r\nMap buildApprovalImpactPreview(...) {\r\n    \/\/ simulate, query, preview \u2014 but never persist\r\n}\r\n<\/pre>\n
With the Spring\/Hibernate configuration used here, @Transactional(readOnly = true) switches the session to a read-only transaction mode that prevents the dirty\u00a0 changes from being automatically flushed. The mutations from the simulation remain in the persistence context, are never written, and are discarded when the\u00a0 persistence context ends. (The class had a bare, read-write @Transactional at the top, which is why every method defaulted to auto-flush until told otherwise.)<\/p>\n
The deeper design smell<\/h2>\n
Because the real smell isn’t the missing annotation \u2014 it’s using live, managed entities as a scratchpad<\/strong>. Safer options:<\/p>\n
    \n
  • Project into DTOs \/ read models \u2014<\/strong> Hibernate can’t flush what it isn’t tracking.<\/li>\n
  • Detach or clone before mutating \u2014<\/strong> session.evict(entity) (or a defensive copy) lets you change a throwaway, not the tracked entity.<\/li>\n
  • Keep genuinely read-only work in a read-only transaction \u2014<\/strong> belt and braces on top of the design fix.<\/li>\n<\/ul>\n
    What I learned<\/h2>\n
    If I could hand my past self a checklist, it would be this.<\/p>\n
    For preview \/ simulation code<\/p>\n
      \n
    • Don’t mutate managed entities.<\/li>\n
    • Prefer DTOs\/projections for simulations.<\/li>\n
    • Use @Transactional(readOnly = true) for genuinely read-only operations.<\/li>\n
    • Don’t assume “no save() = no database write.”<\/li>\n
    • Enable Hibernate SQL logging when investigating unexpected persistence.<\/li>\n
    • Understand the persistence context and dirty checking before debugging the service layer.<\/li>\n<\/ul>\n
      The fix was a single annotation but it made me stop treating the ORM as a black box and start understanding the machinery underneath: the persistence context, dirty checking, flush modes, and the well-meaning reflex that turns a preview into a commit.<\/p>\n
       <\/p>\n","protected":false},"excerpt":{"rendered":"
      The bug that shouldn’t have existed The report read like a riddle: edit a record, preview the impact (to confirm\/or not confirm), click Cancel, refresh \u2014 and the changes are still there. No error. Cancel is the one button whose entire job is to not do things \u2014 and yet the changes had been saved […]<\/p>\n","protected":false},"author":2278,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[446],"tags":[29,4840,265,4844,5902,4841],"class_list":["post-82017","post","type-post","status-publish","format-standard","hentry","category-java","tag-gorm","tag-grails","tag-hibernate","tag-java","tag-jpa","tag-spring"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t