READ_COMMITTED隔离级别下的预期行为：读操作是否会阻塞？

首先明确：选项b是SQL标准定义的READ_COMMITTED隔离级别核心预期行为，但不同数据库的具体实现可能出现选项a的表现，这并非bug，而是不同并发控制机制导致的正常差异。

1. SQL标准对READ_COMMITTED的核心要求 #

READ_COMMITTED的核心规则是：

• 事务只能读取其他事务已提交的数据，完全避免脏读（看不到未提交的修改）
• 标准并未强制规定读操作必须阻塞，而是允许数据库通过不同技术手段实现隔离性，只要满足上述核心规则即可。

2. 不同数据库的实现差异 #

导致两种行为的关键是数据库采用的并发控制机制：

• MVCC（多版本并发控制）实现（如PostgreSQL、MySQL InnoDB默认、Oracle）：
  线程2执行findAll（select *）时，会读取目标行的已提交版本快照，不会被线程1持有的行排他锁阻塞，直接返回未被修改的旧数据，完全符合选项b的描述。
• 锁机制实现（如SQL Server未开启READ_COMMITTED_SNAPSHOT时）：
  线程1更新行时会持有排他锁，线程2的select操作会尝试获取共享锁，此时会被阻塞直到线程1提交/回滚事务，对应选项a的表现。但这种实现依然符合READ_COMMITTED的核心要求——线程2最终读取的是已提交的数据，只是过程中出现了阻塞。

3. Wildfly+Hibernate+JTA的角色 #

• Hibernate作为JPA实现，只是将隔离级别配置传递给底层JDBC驱动，不会改变数据库本身的隔离行为。
• JTA负责事务的生命周期管理，但隔离级别的具体表现由数据库和其配置决定，与JTA容器无关。

总结 #

两种行为都符合SQL标准对READ_COMMITTED的定义，不存在数据库bug。如果需要统一的无阻塞读行为，可以调整数据库的配置（例如在SQL Server中开启READ_COMMITTED_SNAPSHOT），切换到MVCC模式。

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