Hibernate与PostgreSQL中REPEATABLE_READ搭配@Version能否避免写偏序等异常

结论 #

你的认知基本正确，这套技术组合在你描述的场景下不会出现数据不一致问题，以下是具体的逻辑说明：

PostgreSQL REPEATABLE_READ隔离级别的异常防护能力 #

PostgreSQL的REPEATABLE_READ隔离级别基于快照隔离（SI）实现，防护能力比SQL-92标准定义的REPEATABLE_READ更严格，仅存在写偏序这一种异常可能：

• 已完全规避SQL-92标准定义的三类异常：脏读、不可重复读、幻读
• 已完全规避《ANSI SQL隔离级别批判》中提到的另外三类异常：脏写、读偏序、更新丢失

搭配@Version乐观锁的效果 #

你当前的场景是复制实体图，以SELECT查询旧数据、INSERT插入新复制数据为主，乐观锁的加持可以彻底解决仅剩的写偏序风险：

1. 如果你整个复制流程完全不涉及修改原有实体，仅插入新生成的复制实体，本身就不满足写偏序的触发条件（写偏序需要两个事务同时读取同一批数据后各自修改不同的子集），不存在一致性风险
2. 如果你的复制流程中包含对原有实体的更新操作，@Version乐观锁会自动拦截并发更新冲突：如果其他事务先更新了目标行，你的更新语句会抛出ObjectOptimisticLockingFailureException，不会出现脏写或数据不一致的情况

注意边界情况 #

实际使用时只要规避以下场景即可保证一致性：

• 不要在同一事务内混合原生SQL更新和JPA托管实体更新，原生SQL默认不会自动维护@Version字段值，会导致乐观锁失效
• 如果你业务上已经接受「复制过程中修改原实体图，复制流程仍基于事务启动时的快照正常运行」的表现，那这套方案完全适配你的业务需求，没有额外问题

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