网店版重生系列：多数据源单sqlMapClient导致NullPointerException问题跟踪

从前面的《网店版重生系列：都是Spring配置中自动注入惹的祸》中我们可以看出一些有关datasource、sqlMapClientTemplate、sqlMapClient的相关配置信息；整体而言，采取的方式为：
其一，单实例sqlMapClient，只配置configLocation属性，不配置datasource；
其二，sqlMapClientTemplate中配置动态datasource、sqlMapClient，然后在Dao中注入sqlMapClientTemplate；
其三，由于获取用户与Mysql数据库之间的对应关系是保存在Oracle主库中，所以不适用动态数据源，而是直接通过配置sqlMapClient、JNDI datasource来完成注入；

在这种配置方式下，应用初期偶尔会出现报NullPointerException异常信息，堆栈信息如下：
java.lang.NullPointerException at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.setUserConnection(SqlMapSessionImpl.java:149) at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:179) at com.alisoft.eshop.ddb.dao.support.DdbSqlMapClientTemplate.execute(DdbSqlMapClientTemplate.java:86) at org.springframework.orm.ibatis.SqlMapClientTemplate.delete(SqlMapClientTemplate.java:396) at com.alisoft.eshop.ddb.dao.support.DdbSqlMapClientTemplate.delete(DdbSqlMapClientTemplate.java:53) at com.alisoft.c2c.biz.dal.dao.ibatis.IbatisMigrateDataDao.deleteDBFromMysql(IbatisMigrateDataDao.java:21) at com.alisoft.c2c.biz.manager.impl.MigrationDataImpl.doDeleteFromMysql(MigrationDataImpl.java:170) at com.alisoft.c2c.biz.manager.impl.MigrationDataImpl.migrationDate(MigrationDataImpl.java:69)

开始的时候，我们还以为是Mysql数据库首次连接出现Time Out所致，但细想下不对啊！如果是这样堆栈信息中应该会包括TimeOut相关的信息才对啊，但是没有这个信息，再看看堆栈信息，是从SqlMapSessionImpl.setUserConnection中抛出来的，跟踪下源码，问题很快就被定位了，原因是SqlMapSession被关闭所致；来看看最为关键的这段代码先：
SqlMapSession session = this.sqlMapClient.openSession(); Connection ibatisCon = null; try { if (logger.isDebugEnabled()) { logger.debug("Opened SqlMapSession [" + session + "] for iBATIS operation"); } Connection springCon = null; try { ibatisCon = session.getCurrentConnection(); if (ibatisCon == null) { springCon = DataSourceUtils.getConnection(getDataSource()); session.setUserConnection(springCon); if (logger.isDebugEnabled()) { logger.debug("Obtained JDBC Connection [" + springCon + "] for iBATIS operation"); } } else { if (logger.isDebugEnabled()) { logger.debug("Reusing JDBC Connection [" + ibatisCon + "] for iBATIS operation"); } } return action.doInSqlMapClient(session); } catch (SQLException ex) { throw getExceptionTranslator().translate("SqlMapClient operation", null, ex); } finally { DataSourceUtils.releaseConnection(springCon, getDataSource()); } } finally { // Only close SqlMapSession if we know we've actually opened it // at the present level. if (ibatisCon == null) { session.close(); } }
跟踪代码时发现，其实这段代码被调用了多次，第一次执行时没有任何问题，第二次执行时也没问题，异常信息其实是第三次执行时抛出，直接原因是此时SqlMapSession的实例已被close；根本原因呢还是因为单sqlMapClient实例所致！

在分布式改造过程中，为了避免对用户、Mysql分库信息对应关系的强耦合，没有采取固定的hash取模或者是一致hash算法，而是将用户、Mysql分库信息进行了持久化存储，保存于主库Oracle中，然后再配合Cache优化性能；这样就出现了一种应用场景：
当我们在通过Ibatis在Mysql库中执行SQL语句时，因为要通过datasource获取connection，所以可能需要先访问Oracle主库以便获取当前用户所对应的Mysql数据库信息，而这两者的SQL操作都是通过Ibatis进行的，所以我们上面提到的那段代码就会被多次执行了，而每次SQL执行完毕之后都会到finally部分调用session.close()；session的实例是和当前线程绑定的，所以其实那几次代码段的执行都是使用的同一个session；

问题根源都找到了，解决也很简单：针对JNDI datasource、动态datasource区分不同的sqlMapClient，也即配置两个单独的sqlMapClient实例即可；