事务范围数据库读写分离失败
- 背景：
xxx系统在账单生成环节和对账环节采用了spring线程池技术。
系统在第一次执行账单生成可以顺利通过，但是当第二次再执行生成账单时，报出没有数据库写入权限。
事务范围内，主从数据源切换失效，只能获取到主库数据源。
- 配置：
为了方便说明问题，配置线程池默认活动线程1个，最大线程1个。如下：
<bean id="threadPool" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor"> <!-- 核心线程数 --> <property name="corePoolSize" value="1" /> <!-- 最大线程数 --> <property name="maxPoolSize" value="1" /> <!-- 队列最大长度 >=mainExecutor.maxSize --> <property name="queueCapacity" value="10" /> <!-- 线程池维护线程所允许的空闲时间 --> <property name="keepAliveSeconds" value="300" /> <!-- 线程池对拒绝任务(无线程可用)的处理策略 --> <property name="rejectedExecutionHandler"> <bean class="java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy" /> </property> </bean>
- 问题分析：
首先分析为什么事务范围只能拿到主库的数据源。目前事务的声明采用注解的方式，如下：
@Transactional(rollbackFor=Exception.class)
public void genBillB(){}
然后我们分析下程序的执行流程：
1、spring解析Transactional并开启事务
通过阅读spring源码，我们发现事务真正开始的地方为：
org.springframework.jdbc.datasource.DataSourceTransactionManager类的方法：doBegin(Object, TransactionDefinition).在该方法中会获取当前数据源对应的connection并绑定到
当前事务中。代码如下：
DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction; Connection con = null; try { if (txObject.getConnectionHolder() == null || txObject.getConnectionHolder().isSynchronizedWithTransaction()) { Connection newCon = this.dataSource.getConnection(); if (logger.isDebugEnabled()) { logger.debug("Acquired Connection [" + newCon + "] for JDBC transaction"); } txObject.setConnectionHolder(new ConnectionHolder(newCon), true); } txObject.getConnectionHolder().setSynchronizedWithTransaction(true); con = txObject.getConnectionHolder().getConnection(); Integer previousIsolationLevel = DataSourceUtils.prepareConnectionForTransaction(con, definition); txObject.setPreviousIsolationLevel(previousIsolationLevel); // Switch to manual commit if necessary. This is very expensive in some JDBC drivers, // so we don't want to do it unnecessarily (for example if we've explicitly // configured the connection pool to set it already). if (con.getAutoCommit()) { txObject.setMustRestoreAutoCommit(true); if (logger.isDebugEnabled()) { logger.debug("Switching JDBC Connection [" + con + "] to manual commit"); } con.setAutoCommit(false); } txObject.getConnectionHolder().setTransactionActive(true); int timeout = determineTimeout(definition); if (timeout != TransactionDefinition.TIMEOUT_DEFAULT) { txObject.getConnectionHolder().setTimeoutInSeconds(timeout); } // Bind the session holder to the thread. if (txObject.isNewConnectionHolder()) { TransactionSynchronizationManager.bindResource(getDataSource(), txObject.getConnectionHolder()); } } catch (Exception ex) { DataSourceUtils.releaseConnection(con, this.dataSource); throw new CannotCreateTransactionException("Could not open JDBC Connection for transaction", ex); }
大家可能会问，当前数据源是哪个？请大家回忆上一篇博文的序列图，如果当前事务中没有绑定数据源或者没有开启事务的时候，会直接调用
AbstractRoutingDataSource.getConnection。该方法调用DynamicDataSource.determineCurrentLookupKey()从ThreadLodal变量DynamicDataSource.local中获取
当前数据源路由key，根据key获取当前的数据源，让后调用当前数据源的getConnection方法得到数据库连接。
那么当第一次调用时很明显DynamicDataSource.local中为空，参看DynamicDataSource中的方法determineCurrentLookupKey,此时返回的一定是master数据源。也就是说当前数据源为master数据源。
@Override
protected Object determineCurrentLookupKey() {
String dString = local.get() == null ? MASTER : local.get();
setRoute(DynamicDataSource.MASTER);
return dString;
}
获取到当前数据源，参看上面源码，spring会设置txObject.getConnectionHolder().setSynchronizedWithTransaction(true);同时将数据源绑定到当前事务
TransactionSynchronizationManager.bindResource(getDataSource(), txObject.getConnectionHolder());
到此事务就开启完毕了。
2、事务开启后，开始进入具体的业务逻辑代码
在业务逻辑代码中，有查询和更新。查询我们期望每次使用的是从库，更新期望每次都是主库。但是结合上一篇博文分析，如果在事务范围内，每次的数据库连接是通过
调用ConnectionHolder.getConnection得到，而该ConnectionHolder在第一步的时候也说明已经绑定到当前事务并且数据源为master。所以即便是我们显示的声明要获取从库连接也不会生效。
代码如下：this.getJdbcTemplate(DynamicDataSource.SLAVE).query()也会使用master数据源而不会使用slave。
下面分析线程池中，系统在第一次执行账单生成可以顺利通过，但是当第二次再执行生成账单时，报出没有数据库写入权限。
1、什么是线程池
维护一定数量的线程，减少在创建和销毁线程上所花的时间以及系统资源的开销。
2、第二次执行
了解了线程池的概念后我们知道，第二次执行获取到的是上一次执行创建的线程。由于上一个线程的ThreadLocal变量，在程序执行的最后环境被设置为slave，
因此其存放的是slave数据源，那么根据第一个问题分析，事务在开启的时候就会从threadlocal变量中找到当前的数据源并绑定，由于当前线程的theadlocal变量中key为slave
那么获取到的数据源为slave，这样当进行写入操作时就会提示拒绝操作。
- 结论：
应该尽量将查询放到事务外部处理
线程池中使用时，保证线程执行完毕后清理threadlocal变量。
