Spring 5.3中Repository的数据库异常处理方案探讨

一、避免UnexpectedRollbackException的具体方案 #

Spring抛出这个异常的核心原因是：你在Repository内部捕获了异常，但Hibernate已经把当前事务标记为需要回滚，Spring事务管理器在关闭事务时发现这个标记，就会抛出异常。要解决这个问题，得从事务规则配置入手，而不是在方法内部吞异常：

1. 精准配置事务不回滚的异常类型 #

给你的hasData方法添加@Transactional注解，指定noRollbackFor属性，把连接相关的异常排除在回滚触发条件外。比如针对数据库连接关闭的 transient 异常（比如SQLTransientConnectionException）：

@Repository
public class YourDataRepository {

    @Transactional(noRollbackFor = SQLTransientConnectionException.class)
    public Collection<?> hasData() {
        try {
            // 你的查询逻辑
            return executeQuery();
        } catch (SQLTransientConnectionException e) {
            // 连接异常时返回空集合
            return Collections.emptyList();
        }
    }
}

这里的关键是告诉Spring：当出现这类连接异常时，不要把事务标记为需要回滚，这样事务关闭时就不会触发UnexpectedRollbackException。

2. 让方法运行在独立事务中 #

如果这个方法是被其他事务方法调用的，默认会加入现有事务，即使你配置了noRollbackFor，外部事务的状态还是可能被影响。这时候可以指定事务传播行为为REQUIRES_NEW，让该方法在独立的小事务中执行：

@Transactional(propagation = Propagation.REQUIRES_NEW, noRollbackFor = SQLTransientConnectionException.class)
public Collection<?> hasData() {
    try {
        return executeQuery();
    } catch (SQLTransientConnectionException e) {
        return Collections.emptyList();
    }
}

这样，这个方法的事务和外部事务完全隔离，连接异常只会影响当前小事务，不会污染外部事务的状态。

3. 全局统一处理Hibernate连接异常（进阶） #

如果你的系统中有很多类似的场景，可以自定义Hibernate的SQLExceptionConverter，统一将连接类异常标记为不需要回滚：

public class ConnectionExceptionConverter extends StandardSQLExceptionConverter {
    @Override
    public JDBCException convert(SQLException sqlException, String message, String sql) {
        JDBCException jdbcEx = super.convert(sqlException, message, sql);
        // 根据数据库驱动的错误码判断是否为连接关闭异常（比如MySQL的1040、SQLState 08001）
        if ("08001".equals(sqlException.getSQLState()) || sqlException.getErrorCode() == 1040) {
            return new JDBCException(message, sql, sqlException) {
                @Override
                public boolean isRollback() {
                    return false; // 标记为不需要回滚
                }
            };
        }
        return jdbcEx;
    }
}

然后在Hibernate配置中注册这个转换器，这样所有连接关闭异常都会被Spring识别为不需要回滚的异常，从根源上避免UnexpectedRollbackException。

二、可接受数据库失败的处理模式 #

当数据库失败属于业务可接受的状态时，适合采用以下几种容错模式：

1. 优雅降级 #

就是你需求中的逻辑：数据库不可用时返回空集合，让业务流程继续执行，不中断用户操作。核心是优先保证系统可用性，牺牲非关键的数据准确性（业务可接受）。

2. 重试机制 #

连接不可靠很多时候是临时问题（比如网络波动、数据库临时重启），可以给方法添加重试逻辑，用Spring Retry快速实现：

@Retryable(value = SQLTransientConnectionException.class, maxAttempts = 3, backoff = @Backoff(delay = 100))
@Transactional(noRollbackFor = SQLTransientConnectionException.class)
public Collection<?> hasData() {
    return executeQuery();
}

// 重试失败后的兜底逻辑
@Recover
public Collection<?> recoverConnectionException(SQLTransientConnectionException e) {
    return Collections.emptyList();
}

重试3次后还是失败，再返回空集合，既能提升成功率，又保证容错。

3. 缓存兜底 #

因为hasData被频繁调用，可以用Spring Cache把查询结果缓存起来，数据库正常时更新缓存，异常时直接返回缓存数据（或空集合）：

@Cacheable(value = "hasDataCache", key = "#root.methodName")
@Transactional(noRollbackFor = SQLTransientConnectionException.class)
public Collection<?> hasData() {
    try {
        return executeQuery();
    } catch (SQLTransientConnectionException e) {
        return Collections.emptyList();
    }
}

这样可以大幅减少对数据库的依赖，同时提升接口响应速度。

三、为什么不能在Repository内部直接吞异常？ #

Spring的事务管理是基于AOP切面实现的，事务状态由切面维护。你在Repository内部捕获RuntimeException后，Hibernate已经把当前连接对应的事务标记为需要回滚，但Spring切面看到方法正常返回，就会认为事务应该提交，这时候就会出现“预期提交但实际需要回滚”的矛盾，抛出UnexpectedRollbackException。所以必须通过事务注解配置让切面感知到你的异常处理策略，而不是在方法内部吞掉异常。

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