Spring Data JPA微服务中二次更新先于首次更新执行问题排查

核心问题：事务提交时机滞后 #

你的save方法标注了@Transactional，Spring声明式事务默认会在方法执行完成后才提交事务。应用A的执行流程是：

1. 调用save方法，完成实体映射与repository.save(entity)操作（此时仅将变更写入Hibernate缓存，数据库事务未提交）
2. 立即通过FeignClient调用应用B
3. 应用A的save方法执行完毕，事务才真正提交到数据库

这就导致应用B的查询、修改、保存操作，大概率在应用A的事务提交前就已执行完成，数据库日志自然会显示B的更新早于A。

可调整的配置/代码点 #

• 拆分事务与远程调用：将应用A中save操作和Feign调用拆分到独立事务中，确保A的事务提交后再触发B的调用，示例代码：

  // 应用A的业务处理方法
  public void handleBusiness(DTO dto) {
      // 独立事务执行save，执行完立即提交
      transactionTemplate.execute(status -> {
          myService.save(dto);
          return null;
      });
      // 事务已提交，再调用应用B
      feignClient.invokeB(dto.getId());
  }
  

• 检查事务传播属性：确认@Transactional的传播行为是否为默认的REQUIRED，如果存在外层事务，会导致save的事务与外层事务合并提交，进一步延迟提交时机。

其他排查方向 #

• SQL Server隔离级别验证：检查数据库隔离级别，若为READ UNCOMMITTED可能读取脏数据，但不会影响日志执行顺序；若隔离级别过高导致锁等待，需排查锁竞争情况，但当前日志顺序异常更倾向事务提交时机问题。
• 异步调用排查：确认应用A中FeignClient的调用是否为异步（比如使用@Async注解），异步调用会导致远程请求与事务提交并行，B的操作可能先完成。
• Hibernate flush模式检查：查看Spring Data JPA配置，若设置spring.jpa.properties.hibernate.flushMode=COMMIT，会延迟缓存刷写到事务提交时，加剧提交滞后；可临时改为ALWAYS验证，但不建议长期使用（影响性能）。
• 日志时间戳校验：确认SQL Server日志的时间戳与应用服务器时间是否同步，避免因时间差导致的顺序误判。

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