Hibernate搭配SQL Server事务读锁阻塞脏读配置失效问题问询

现有基于Spring Data JPA + Microsoft SQL Server实现的高负载业务逻辑，核心代码如下：

@Transactional(rollbackFor = Exception.class)
public void executeAllFlows() {

    RandomTableObject a = randomTableObjectRepository.findById(1L);
    executeFlow1();
    executeFlow2();
    executeFlow3();
    executeFlow4();
    
    a.setSomeAttribute(true);
    randomTableObjectRepository.save(a);

}

@Transactional(rollbackFor = Exception.class)
private void executeFlow1() {
//read items from tempTable 1 and persist them in other 2 tables after performing logic
}

@Transactional(rollbackFor = Exception.class)
private void executeFlow2() {
//read items from tempTable 2 and persist them in other 2 tables after performing logic
}

@Transactional(rollbackFor = Exception.class)
private void executeFlow3() {
//read items from tempTable 3 and persist them in other 2 tables after performing logic
}

@Transactional(rollbackFor = Exception.class)
private void executeFlow4() {
//read items from tempTable 4 and persist them in other 2 tables after performing logic
}

该流程单次要处理数千条记录，最长执行耗时可达2分钟，执行异常时所有关联表操作全部回滚，符合业务预期。

现存问题 #

流程运行期间需要支持其他请求对表数据的脏读，但实际表现为：流程启动初期可以正常读取RandomTableObject表数据，数秒后读请求会被直接阻塞，直到整个2分钟的流程执行完成才返回结果。

已尝试的排查&操作 #

• 初步排查发现Hibernate查询该表并进入修改流程时似乎持有读锁，但Hibernate默认不会主动施加读锁，因此初步怀疑问题源于MS SQL Server的事务隔离级别配置。
• 参考SQL Server官方隔离级别说明，Read uncommitted隔离级别允许脏读，因此尝试在每个事务方法上添加如下配置：

@Transactional(rollbackFor = Exception.class , isolation = Isolation.READ_UNCOMMITTED)

上述注解导入自org.springframework.transaction.annotation包，但配置后阻塞问题并未解决。

配置不生效、读请求被阻塞是两个独立问题叠加导致的：

1. @Transactional注解加在private方法上完全无效
   Spring声明式事务基于AOP动态代理实现，只有通过Spring代理对象调用的public方法上的事务注解才会被解析生效。你代码里的executeFlow1~executeFlow4都是private方法，且是在同类内部直接调用，上面加的任何事务配置都不会生效，整个长事务的配置完全由最外层executeAllFlows方法的注解决定。
2. 锁阻塞的核心逻辑理解错误
   SQL Server默认隔离级别为READ COMMITTED，该级别下写操作会对修改中的数据加排他锁，直到事务提交才释放。写事务的隔离级别决定写操作的持锁行为，读请求自身的隔离级别才决定读请求会不会被排他锁阻塞。你只修改写事务的隔离级别，不调整读请求的配置，读请求还是会按照READ COMMITTED的规则，等待写操作释放锁后才能读取数据，自然会被阻塞。
   另外你的代码逻辑本身放大了锁冲突：事务一开始就查询id=1的RandomTableObject记录，跑完2分钟的业务逻辑后才更新这条记录，结合Hibernate的脏检查、实体管理机制，很容易导致这条记录的锁被持有整个事务周期，锁持有时间长达2分钟。

可落地修复步骤 #

按优先级从高到低操作：

• 第一步：修正事务配置的无效问题
  删掉所有private方法上的@Transactional注解，直接在最外层executeAllFlows方法上统一配置事务属性。如果确实需要拆分内部方法的事务逻辑，把方法改为public，通过注入的当前类代理对象调用，保证AOP能拦截到方法调用。
• 第二步：缩短锁持有时间，从根源减少冲突
  把RandomTableObject的查询、更新操作挪到4个flow业务逻辑全部执行完成之后再做，不要在事务启动时就查询这条记录，将该记录的锁持有时间从2分钟压缩到毫秒级，绝大多数场景下这一步就能解决读请求阻塞问题。
• 第三步：针对必须在长事务运行期间执行的读请求，选择以下任意一种方案实现无阻塞读：
  • 方案1：给读请求对应的事务方法配置isolation = Isolation.READ_UNCOMMITTED，同样需要保证注解在public方法上、通过Spring代理调用才会生效，该配置下读请求不会等待写锁释放，直接读取未提交的数据（即脏读）。
  • 方案2：针对RandomTableObject的读查询，显式加SQL Server的NOLOCK表提示，这是SQL Server生态下最常用的脏读实现方式，不受事务配置生效问题影响，JPA中写法示例：

    @Query(value = "SELECT * FROM random_table_object WITH (NOLOCK) WHERE id = :id", nativeQuery = true)
    RandomTableObject findByIdNoLock(Long id);
    

  • 方案3（无脏读风险，优先推荐）：如果使用SQL Server 2005及以上版本，执行如下命令开启数据库级别的读提交快照隔离：

    ALTER DATABASE 你的业务库名 SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
    

    开启后READ COMMITTED级别下的读操作不会申请共享锁，也不会被写操作的排他锁阻塞，读请求会自动读取数据修改前的快照版本，既不会阻塞，也不会读到未提交的脏数据，不需要修改任何业务代码。

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