迁移Wildfly至YugabyteDB：使用READ COMMITTED隔离级别是否合适？

在从标准PostgreSQL迁移Wildfly J2EE代码到YugabyteDB时遇到事务冲突问题：

• 存在Manager Bean：
  • methodX()带有@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)注解，执行非数据库逻辑后调用methodY()
  • methodY()无注解，执行数据库UPDATE操作
  • methodZ()无注解，对同一条记录执行DELETE操作
• 无注解的Client Bean的clientMethod()流程：先调用Manager.methodX()，再调用Manager.methodZ()
• 报错信息：

  com.yugabyte.util.PSQLException: ERROR: Operation failed. Try again
  

• 日志分析：clientMethod()启动事务T1，调用methodX()时挂起T1，methodY()启动新事务T2；调用methodZ()时恢复使用T1。该场景在标准PostgreSQL中正常，但YugabyteDB默认配置下报错。

排查后发现：

• PostgreSQL默认隔离级别为READ COMMITTED，YugabyteDB默认是Snapshot（等价于PostgreSQL的REPEATABLE READ），且默认将READ COMMITTED映射为Snapshot
• 开启yb_enable_read_committed_isolation=true并设置ysql_default_transaction_isolation='READ COMMITTED'后，场景恢复正常

核心疑问：在YugabyteDB中使用READ COMMITTED隔离级别是否不妥？若不妥，原因是什么？

1. 默认隔离级别下报错的原因 #

YugabyteDB默认的Snapshot（可重复读）隔离级别中，事务T1启动时会获取一个全局快照，后续所有读取都基于该快照。当T2提交了对目标记录的更新后，T1再尝试删除该记录时，会发现记录的版本与自己快照中的版本不一致，触发乐观并发控制冲突，从而抛出Operation failed. Try again错误。

而标准PostgreSQL的READ COMMITTED隔离级别中，每个语句都会获取新的快照，T1执行DELETE时会看到T2提交的最新版本，因此可以正常执行。

2. 在YugabyteDB中使用READ COMMITTED是否妥当？ #

适用场景 #

如果你的业务逻辑依赖READ COMMITTED的特性（比如需要语句级快照、容忍不可重复读），且能接受该级别带来的一致性 trade-off，那么使用READ COMMITTED是完全可行的：

• YugabyteDB从v2.10版本开始正式支持原生READ COMMITTED隔离级别，开启yb_enable_read_committed_isolation=true后可以稳定使用
• 对于迁移自PostgreSQL的应用，使用该级别可以减少代码修改，快速适配YugabyteDB

需要注意的风险 #

YugabyteDB默认选择Snapshot作为默认级别，主要因为分布式场景下READ COMMITTED存在以下局限性：

• 分布式事务一致性风险：在跨节点的分布式事务中，READ COMMITTED的语句级快照可能导致读取到部分提交的数据，出现符合SQL标准但不符合分布式业务预期的一致性问题
• 性能开销：原生READ COMMITTED需要在每个语句执行时获取新的全局快照，相比Snapshot的一次性快照，会增加一定的协调开销，在高并发场景下可能影响吞吐量
• 业务扩展成本：如果后续业务扩展依赖Snapshot级别的一致性保证（比如避免不可重复读、幻读），切换回Snapshot需要修改业务逻辑，增加迁移成本

3. 替代方案（无需切换隔离级别） #

如果不想使用READ COMMITTED，可以调整事务注解来避免冲突：

• 将methodZ()的事务属性改为REQUIRES_NEW，让其在新事务中执行，避免与T1的快照冲突
• 或者调整clientMethod()的事务边界，确保T1在调用methodX()前不启动，减少长事务的快照持有时间

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