1. 背景

在上周遇到一个spring bug的问题，将其记录一下。简化的代码如下：

public void insert() {
    try {
        Person person = new Person();
        person.setId(3581L);// 这个是主键，拥有唯一索引**
        personDao.insert(person);
    } catch (DuplicateKeyException e) {
        log.error("DuplicateKeyException e = {}", e.getMessage(), e);
        // DuplicateKeyException 其他逻辑处理
    } catch (DataIntegrityViolationException e) {
        log.error("DataIntegrityViolationException e = {}", e.getMessage(), e);
        // DataIntegrityViolationException 其他逻辑处理
    } catch (Exception e) {
        log.error("Exception e = {}", e.getMessage(), e);
    }
}

然而同一份代码，部署在不同机器（数据库只有一个, 不存在分库分表情况），遇到的情况不一样。

A机器：如果主键冲突，则抛出DuplicateKeyException异常，进入第7行的逻辑

B机器：如果主键冲突，则抛出
DataIntegrityViolationException异常，进入第11行的逻辑

甚至我将B机器重启，如果主键冲突，则抛出DuplicateKeyException异常，进入第7行的逻辑

非常的奇怪，我们一一细说

2. 数据库异常分析

2.1 spring对java标准异常的包装

从表格中我们可以明显看出，
SQLIntegrityConstraintViolationException是属于Java体系的标准异常，当主键冲突，外键约束，非空等情况正常都会抛出这个异常

然后spring框架对这个异常进行了一个封装，比如违反唯一索引会抛出DuplicateKeyException异常，其他的情况会抛出
DataIntegrityViolationException异常。

2.2 spring代码包装

在spring中会有一个SQLErrorCodesFactory类，会加载下面路径下的资源。也就是说，每个数据库厂商对于不同异常返回的错误码不同，spring进行了一个包装

public static final String SQL_ERROR_CODE_DEFAULT_PATH 
    =  "org/springframework/jdbc/support/sql-error-codes.xml";

2.3 问题产生的原因

在spring异常处理中，有一个非常核心的类
SQLErrorCodeSQLExceptionTranslator，但遇到主键冲突，非空约束等异常的时候，spring会使用这个类进行转化。

if (Arrays.binarySearch(this.sqlErrorCodes.getBadSqlGrammarCodes(), errorCode) >= 0) {
    logTranslation(task, sql, sqlEx, false);
    return new BadSqlGrammarException(task, (sql != null ? sql : ""), sqlEx);
}
else if (Arrays.binarySearch(this.sqlErrorCodes.getInvalidResultSetAccessCodes(), errorCode) >= 0) {
    logTranslation(task, sql, sqlEx, false);
    return new InvalidResultSetAccessException(task, (sql != null ? sql : ""), sqlEx);
}
else if (Arrays.binarySearch( this .sqlErrorCodes.getDuplicateKeyCodes(), errorCode) >= 0) {
    logTranslation(task, sql, sqlEx, false);
    return new DuplicateKeyException(buildMessage(task, sql, sqlEx), sqlEx);
}
else if (Arrays.binarySearch(this.sqlErrorCodes.getDataIntegrityViolationCodes(), errorCode) >= 0) {
    logTranslation(task, sql, sqlEx, false);
    return new DataIntegrityViolationException(buildMessage(task, sql, sqlEx), sqlEx);
}
else if // xxx 省略

我们可以从上面代码中可以看到，他其中是从sqlErrorCodes中，进行二分查找，是否存在相应的code码，然后返回给上游不同的错误，那么sqlErrorCodes是从哪里获取的呢。

try {
    String name = JdbcUtils.extractDatabaseMetaData(dataSource, "getDatabaseProductName");
    if (StringUtils.hasLength(name)) {
       return registerDatabase(dataSource, name);
    }
}
catch (MetaDataAccessException ex) {
    logger.warn("Error while extracting database name - falling back to empty error codes", ex);
}
// Fallback is to return an empty SQLErrorCodes instance.
return new SQLErrorCodes();

从上面代码我们可以看出，会通过
JdbcUtils.extractDatabaseMetaData方法来获取sqlErrorCodes，是哪个厂商，并且获取到Connection进行连接，然后返回相应的sqlErrorCodes码

但是在第7行，如果此时Connection数据库链接有异常，则会报错，然后返回11行一个空的sqlErrorCodes，那么问题就出在这里了！！！

也就是说，如果在第一次获取sqlErrorCodes，如果出了问题，那么这个字段就会为空，上面代码的转化异常逻辑就会判断错误。就会走到else兜底退避的策略。

具体退避的策略在

SQLExceptionSubclassTranslator类中，所以当走到了退避策略，所有

SQLIntegrityConstraintViolationException异常都会返回
DataIntegrityViolationException异常

if (ex instanceof SQLNonTransientConnectionException) {
    return new DataAccessResourceFailureException(buildMessage(task, sql, ex), ex);
}
else if (ex instanceof SQLDataException) {
    return new DataIntegrityViolationException(buildMessage(task, sql, ex), ex);
}
else if (ex instanceof SQLIntegrityConstraintViolationException) {
    return new DataIntegrityViolationException(buildMessage(task, sql, ex), ex);
}
else if // 省略

3. 问题复现

3.1 错误复现

我们从2.3分析中，可以清楚的知道，根因是
SQLErrorCodeSQLExceptionTranslator类中sqlErrorCodes字段为空导致主键冲突退避返回了
DataIntegrityViolationException异常。

那么我们就可以模拟链接异常，比如连接被关闭了，导致首次初始化的时候导致sqlErrorCodes失败，代码如下 (

注意这块代码必须在项目启动 首先第一次执行)

@Transactional
public void testConnect() {
    try {
        Connection connection = DataSourceUtils.getConnection(dataSource);
        connection.close(); // 强制关闭连接，破坏事务一致性

        personDao.selectById(1L);
    } catch (DuplicateKeyException e) {
        log.error("DuplicateKeyException e = {}", e.getMessage(), e);
    } catch (DataIntegrityViolationException e) {
        log.error("DataIntegrityViolationException e = {}", e.getMessage(), e);
    } catch (Exception e) {
        log.error("Exception e = {}", e.getMessage(), e);
    }
}

在上面代码中，我们获取了链接，并且强制关闭了，那么就会导致初始化的时候走2.3那块代码就会报错，此时sqlErrorCodes就会为空。

如果后面sql遇到了唯一索引，返回如下：

3.2 正确复现

将上面代码connection.close()去掉，那么第一次缓存就正常了。再次执行，如果遇到了唯一索引，返回如下：

4. 解决办法

在github上面已经有人提出此问题，并且标记为了bug，链接如下：

https://github.com/spring-projects/spring-framework/issues/25681

并且修复pull request如下 （此代码已合并到v5.2.9.RELEASE分支）

https://github.com/spring-projects/spring-framework/commit/670b9fd60b3b5ada69b060424d697270eeee01c2#diff-e2f38c7b7d44c3679cd585e5c81e76b3ca32313bf870caa6435cd36bfe4d9600

4.1 办法1

升级spring版本到5.2.9.release+，可以彻底解决此问题

4.2 办法2

第一步在项目启动的时候，获取SQLErrorCodes，如果为空，则打印error日志并且告警。让开发同学知道有这么一个问题 (可重启也可不重启)

public class DatabaseMetadataPreloader  {
    @PostConstruct
    public void init() {
       try {
          SQLErrorCodes errorCodes = errorCodesFactory.getErrorCodes(dataSource);
          log.info("Database metadata preloaded successfully errorCodes = {}", GsonUtils.toJson(errorCodes));

          String[] duplicateKeyCodes = errorCodes.getDuplicateKeyCodes();
          if (ArrayUtils.isEmpty(duplicateKeyCodes)) {
             log.error("No duplicate key codes found in database metadata 请重启服务");
          }
       } catch (Exception e) {
          log.error("Failed to preload database metadata", e);
       }
    }
}

第二步重新查询一遍数据库

如果有数据则表明是索引冲突，如果没有数据，则可能是其他异常引起的，走原有的老逻辑

catch (DuplicateKeyException e) {
    log.error("DuplicateKeyException e = {}", e.getMessage(), e);
}

catch (DataIntegrityViolationException e) {
    log.error("DataIntegrityViolationException e = {}", e.getMessage(), e);
    // 重新查一遍数据库，如果有数据，说明是唯一索引冲突
    Person p = select(xxxx)
    if (p != null) {
        // 唯一索引冲突
    } else {
        // 其他异常引起的
    }
}