Spring @Transactional事务提交与数据可见性延迟问题咨询

核心原因分析 #

1. MySQL默认隔离级别的MVCC机制 #

MySQL默认采用**REPEATABLE READ（可重复读）**隔离级别，基于MVCC（多版本并发控制）实现。每个事务在开启时会生成一个数据库快照，后续所有查询都基于该快照返回数据：

• 你的persist方法使用REQUIRES_NEW传播属性，会启动一个独立事务，写入数据后立即提交，数据已持久化到数据库。
• 但如果读取线程的事务（比如SUPPORTS触发的只读事务）是在写入事务提交之前就已开启，那么该读取事务会一直沿用旧快照，无法看到新写入的数据，直到读取事务结束并执行commit。

2. Spring事务对MySQL自动提交的接管 #

你提到MySQL自动提交已开启，但从提供的SQL日志可以看到：

2023-08-14T21:04:35.329818Z  1028 Query SET autocommit=0

这说明Spring的@Transactional注解会接管事务管理，强制关闭当前连接的自动提交。即使使用SUPPORTS传播属性，当搭配readOnly=true时，Spring仍会为该方法创建一个只读事务，此时查询操作属于这个事务的一部分，必须等事务commit后才会释放旧快照。

3. 连接复用与事务快照的毫秒级延迟 #

如果读取线程复用了连接池中的旧连接，即使Spring事务管理器会重置连接状态，极端情况下仍可能存在毫秒级的快照刷新延迟，导致短暂读不到新数据。

针对不同传播属性的细节说明 #

• SUPPORTS：如果当前没有现成事务，Spring会因readOnly=true自动创建只读事务（如日志所示），此时查询完全受MVCC快照规则限制。
• NEVER：该传播属性禁止事务存在，理论上每个查询都是自动提交的独立操作，应该能立即读到提交后的数据。如果仍出现延迟，大概率是JPA一级缓存（EntityManager缓存）或连接池连接状态未及时刷新导致，可通过调用em.clear()清空缓存或更换连接解决。

验证与解决建议 #

• 确认读取操作的启动时机：确保读取是在写入事务commit之后才执行，而非并发或提前开启。
• 调整隔离级别：若需要实时读取最新数据，可将读取操作的事务隔离级别改为READ COMMITTED，此时事务会读取最新已提交的数据，不再依赖旧快照。
• 绕过JPA缓存：在读取方法中手动调用em.clear()，强制从数据库读取最新数据。

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