JPA @PostUpdate回调在不同场景下事务提交异常原因排查

核心背景回顾 #

应用包含三个实体：Building、Stage、Project，其中Stage/Project的type字段依赖Building的endDate；CustomType存储在另一数据库schema中。通过@PrePersist/@PostUpdate/@PostPersist回调更新Stage/Project参数：

• JSON API保存实体时，所有实体的CustomType修改均能正确持久化
• 自定义RestController执行软删除（调用Repository的save()）时，@PostUpdate仅更新Building，Stage/Project虽经EntityManager.contains()确认处于托管状态，但变更未持久化

行为差异的关键原因 #

1. 事务上下文与脏检查触发范围不同 #

• JSON API场景：Spring Data REST等JSON API实现通常会在同一个事务内完成实体加载、修改、回调执行。Hibernate的脏检查机制会扫描整个持久化上下文内的所有托管实体，回调中对Stage/Project的修改会被检测到，事务提交时同步到数据库。
• 软删除场景：调用save()仅针对Building实体触发变更，Hibernate默认仅对**触发生命周期事件的主体实体（Building）**执行脏检查。回调中对Stage/Project的修改属于事务内的“额外变更”，未被纳入当前save()操作的脏检查触发队列，因此不会自动持久化。

2. 生命周期回调中的脏数据标记逻辑 #

Hibernate在@PostUpdate等生命周期回调内，不会自动将回调中修改的关联实体标记为脏数据。只有当实体的变更通过Hibernate的常规实体操作（如事务内调用setter）触发时，才会被标记为脏。在软删除场景的回调中，即使Stage/Project处于托管状态，修改后的状态未被Hibernate标记为脏，后续的flush/提交操作不会同步这些变更。

3. 实体关联的加载时机与状态追踪 #

• JSON API场景下，可能通过急加载或请求触发的懒加载，Stage/Project已被完整加载到持久化上下文，Hibernate对其状态变更的追踪是完整的。
• 软删除场景下，若Building关联的Stage/Project是懒加载的，即使在回调中获取到托管实体，Hibernate对这类“延迟加载后修改”的实体，脏检查逻辑可能未被激活，导致变更未被捕获。

4. 事务提交与flush的时机差异 #

软删除操作的save()可能会立即触发flush（视Hibernate的flushMode配置而定），此时回调中对Stage/Project的修改还未被标记为脏，flush仅同步Building的变更到数据库；而JSON API场景下，flush通常在事务提交前执行，此时所有托管实体的脏变更已被标记，因此能全部同步。

内容的提问来源于stack exchange，提问作者Zavyalov_Artem