Spring Data JPA isolationLevel配置对SQLServer查询不生效问题咨询

1. 事务传播行为默认规则导致隔离级别被覆盖 #

Spring @Transactional 默认传播行为是 Propagation.REQUIRED，规则是：如果当前线程已经存在一个活跃事务，就直接加入该事务，沿用外层事务的所有配置（包括隔离级别、超时、只读属性等）。
你业务逻辑层 BaseProductionPartsUsageService 中调用该查询方法的外层方法已经标注了 @Transactional，默认使用数据库默认隔离级别（SQL Server 默认为 READ_COMMITTED），内层查询方法的 isolation = Isolation.READ_UNCOMMITTED 配置会直接被外层事务的配置覆盖，不会生效。

2. 其他可能原因 #

• 错误使用了Jakarta EE的@Transactional注解而非Spring自带的org.springframework.transaction.annotation.Transactional，后者才支持isolation属性配置；
• 部分ORM框架/数据库驱动的特殊适配逻辑，导致隔离级别配置没有正确传递到数据库连接。

方案1：调整查询方法的事务传播行为 #

给查询方法的@Transactional注解新增传播行为配置：

@Transactional(isolation = Isolation.READ_UNCOMMITTED, propagation = Propagation.REQUIRES_NEW, readOnly = true)
public Iterable<mStorage> getByLocatorAndStockAlert(long locatorId, StockAlert stockAlert) {
    // 原有逻辑
}

Propagation.REQUIRES_NEW会强制新开一个独立事务，完全使用当前方法配置的隔离级别，不会受外层事务影响。查询方法为只读逻辑，独立事务提交/回滚不会影响外层业务事务的一致性。

方案2：直接在SQL层面加读未提交提示 #

如果不想调整事务传播逻辑，可以直接在查询语句中添加SQL Server专属的无锁查询提示，不需要依赖事务隔离级别配置：

@Query("SELECT s FROM mStorage s WHERE s.locator.id = ?1 AND s.stockAlert = ?2 order by s.datelastinventory WITH (NOLOCK)")
Iterable<mStorage> getByLocatorAndStockAlert(long mLocatorId, String stockAlert);

WITH (NOLOCK) 等价于READ_UNCOMMITTED隔离级别，会直接生效，不受外层事务影响。

方案3：拆分外层事务边界 #

如果业务逻辑允许，把不需要事务的查询逻辑移到外层事务之外执行，自然会使用查询方法自身的事务配置。

内容的提问来源于stack exchange，提问作者István Scheer