粗略的看了一下代码，以下是觉得有疑惑的地方，希望能得到作者的解答：
1、CobarSqlMapClientTemplate.sqlMapClient.dataSource没有被加入MultipleDataSourcesTransactionManager管控中，如果这个数据源不在ICobarDataSourceService内声明（就像参考文档那样配置数据源），当路由到这个默认的数据源，事务还能完整吗？

2、基于HotSwappableTargetSource代理的数据源切换会对事务产生影吗？如一个事务中有两个操作，第一个操作在主库完成后主库挂了，第二个操作被切换到次库上，这样事务会有影响吗？

3、如果在这个基础上扩展一个支持读写分离的DataSourceDescriptor,也用HotSwappableTargetSource代理实现数据源切换,发现实现起来很吃力，还可能会有2中的问题。我也看了一下2.0的代码，shard好像也没支持这一部分。因为我现在正要实现这一步分的功能，作者研究这一块应该挺长时间了，希望能得到一些指点。

4、我觉得路由配置可以做的更简单，路由规则配置应该与sqlmap或namespace分离，sqlmap或namespace只需要绑定那个路由规则就可以了，因为多个sqlmap或namespace可以绑定一个路由规则。就像servlet写义与url-mapping的关系，是不是可以变的简单点？

CobarSqlMapClientTemplate的线程池创建方法createCustomExecutorService中使用了public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
这样一个executors创建方法，按照jdk文档中说明，如果在coreSize的时候，有任务加入，会先放到workQueue中，然后workQueue满了之后，再扩充线程池max大小，但是代码中，我们的workQueue-queueToUse没有设置大小，默认是int的max值，这样会导致coreSize无法扩充，coreSize默认是cpu核数+1,在cpu核数不高的情况下，很容易造成任务堆积，性能低下

cobar client 计划的3.0 支持 mybatis 大概什么时候发布呢？这个项目还在维护吗？

• new Routing and LB strategy and implementation
  • multiple Route DSL with unique Route Abstraction Core
  • will TrieTree be more suitable for route selection?!
• new Parallel Execution Structure
• newest framework support : mybatis + spring3.x
• new configuration abstraction for both local and global configuration strategy
• minimised 3rd dependencies
• split modules

CobarSqlMapClientTemplate.java的batchInsertAfterReordering方法，line 453 这里使用了insert方法
return executor.insert(statementName, paramList);
但是insert方法的第二个入参要求是一个对象，比如map、JavaBean之类的。而我们这里的代码是直接把前面获得的一个List传了进去
final List paramList = entity.getValue();
这样在批量插入时候就会出现对象转型异常。
建议在这里迭代paramList，然后依次调用insert方法

https://travis-ci.org/