Spring事务方法内findById查询外部插入记录返回null原因

出现这个问题的根源是@Transactional注解带来的事务隔离级别快照读机制：

1. 你在方法上加了@Transactional，Spring会在方法进入时自动开启事务。如果你用的是MySQL InnoDB引擎（绝大多数Spring业务场景的默认选型），默认隔离级别是可重复读（REPEATABLE READ），事务开启的瞬间会生成一个全局一致性读视图，事务执行全程的普通查询都基于这个快照读取数据，不会读取到事务开启后其他事务提交的新数据。
2. 你的代码执行流程是：开启当前事务 → 调用外部API → 外部服务在独立事务中插入MyObject记录并提交 → 你在当前未提交的事务里执行查询。由于当前事务的快照是在外部服务插入数据之前生成的，快照里根本没有这条新记录，所以就算数据库里已经持久化了这条数据，当前事务的普通查询也会返回null。
3. 如果你用的ORM框架是JPA/Hibernate，一级缓存不会导致这个问题——一级缓存只会缓存当前事务内已经查询过的实体，你查询的是外部服务新生成的ID，之前从来没在当前事务里查过，不会命中一级缓存。

根据你的业务场景选一个即可：

• 把查询新记录的逻辑放到独立事务中执行：给myObjectService.findById方法加上事务注解@Transactional(propagation = Propagation.REQUIRES_NEW)，调用这个方法时会暂时挂起外层的旧事务，新开一个独立事务执行查询，新事务会生成最新的读视图，就能读到外部服务已经提交的记录。注意这个方法必须写在独立的Service类中，不能和processRequest方法放在同一个类里，否则Spring AOP会失效，事务配置不生效。
• 调整查询为当前读：如果你的DAO层用MyBatis，就在查询SQL上加FOR UPDATE；如果用JPA，就给查询加LockModeType.PESSIMISTIC_READ锁，当前读会直接读取数据库最新的已提交数据，不受旧事务快照影响。
• 重构逻辑避免事务内做远程调用：这是最推荐的实践，本身在数据库事务内执行远程调用就是不合理的设计，会拉长事务持有连接的时间，容易引发连接耗尽、死锁等问题。你可以把逻辑拆成三步：先开短事务完成request查询、校验等本地操作 → 提交事务后调用外部API → 再开新事务查询生成的MyObject记录做后续处理。
• 调整事务隔离级别：如果业务允许，可以把当前方法的事务隔离级别改成读已提交（READ_COMMITTED），这个级别下每次执行查询都会生成新的读视图，能读到其他事务已经提交的数据，但要提前评估调整隔离级别会不会对业务逻辑的一致性造成影响。

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