The @Version field that guarded nothing: JPA counters, bulk UPDATEs and quietly missing clicks

A writeup published on dev.to describes roughly two weeks of debugging that began with someone noticing a referrer's click count looked low, and ended at a pattern most Spring Data codebases file under performance: a `@Modifying @Query` that increments a denormalized `total_clicks` column at the SQL level, on an entity that also carries a `@Version` field ^[1][3]. According to the author, that combination is a lost-update bug with the safety mechanism switched off, and because a counter only ever moves up, the corruption is always an understatement rather than an obvious error ^[1][1].

The reason for the bulk UPDATE is the ordinary one. A load-modify-save round trip per click is slow under fan-out, so the increment is pushed into a single statement that is atomic at the database level ^[2].

Then the timeline the author lays out. Hibernate has the row in memory with `totalClicks=42` and `version=7`. Two clicks arrive and are applied by the SQL increment. An unrelated service sets `payoutEmail` on the loaded entity and calls `save()`, and Hibernate writes back every column it tracks, the counter included ^[4][7]. The optimistic-lock check passes, because the version in memory still matches the version in the row: the increment query never touched `version` ^[4]. What goes to the database is `UPDATE referrer SET total_clicks = 42, payout_email = '...', version = 8 WHERE id = ? AND version = 7`, and the two clicks in between are gone ^[5]. The annotation on the increment already specified `clearAutomatically = true`, which did not prevent it ^[16][2].

The failure scales with traffic. The author reports that quiet weeks look correct and viral campaigns are wildly under-counted, because the hotter the counter, the more increments fall inside somebody's read-modify-write window ^[6].

The first fix is to stop Hibernate writing a column it has no business writing: `updatable = false` on `total_clicks` and `total_conversions`, so the only path that writes them is the explicit SQL update ^[9]. The team now applies that to any column mutated exclusively by a `@Modifying @Query`, including denormalized stats and queue depths ^[10].

That plugs the data loss and opens a different hole, which is the part worth internalising. With `updatable = false`, a `save()` no longer notices that the row changed underneath it, so a thread that loaded a stale `payoutEmail` before the counter bump will still commit successfully, when for audit purposes it should have taken an `OptimisticLockException` and retried ^[11][12]. The counter increment is a real mutation of the row; hiding it from the version column trades one class of silent overwrite for another.

The second fix is one clause: `r.version = COALESCE(r.version, 0) + 1` in the SET list of every `@Modifying @Query` UPDATE against an entity that has a `@Version` field ^[13]. The author says the audit touched around fifteen queries across `ReferrerRepository`, `TeamRepository`, `UrlVariantRepository` and others ^[14].

Worth watching in your own codebase: the enforcement, not the fix. The team added a guard test that reflectively walks repository methods, finds every `@Modifying @Query` UPDATE and checks the JPQL for a version assignment in the SET clause ^[15]. Without something like it, the invariant lasts exactly until the next repository method someone adds by copying an old one. And if you are auditing today, the tell is not an exception in a log; it is a counter that is plausible, monotonic and low.