emmm应该是有manager的 因为指定了@Primary 不然容器启动的时候创建sessionFactory就因为多个DataSource异常了，后面会滚的时候manager为null也会有运行时异常，因为@Primary autoconfig 的@ConditionalOnSingleCandidate是生效的，应该是用primary构造的manager，跟到后面DruidPooledConnection也是用mysql的jdbc实现去做rollback,后面倒是有这样一个check：

但是最后应该会抛sqlException异常才是，我用shardingConnection测试的时候这里是可以放过的。要看下DriudPooledConnection是构造过程是怎样的，
DriudPooledConnection是通过DruidDataSource.getConnection构造的最后跟到这里：

我调的的时候拿到的connection确实是true的，拿到connection之后 sharding调用了这个方法：
org.apache.shardingsphere.shardingjdbc.jdbc.adapter.WrapperAdapter#replayMethodsInvocation

这里刚好有个Method对象setAutoCommit(false)

jdbcMethodInvocations的初始化有多很多场景 其中有个场景是针对autocommit的

一层层堆栈跟过去：
org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin：
org.apache.shardingsphere.shardingjdbc.jdbc.core.connection.ShardingConnection#setAutoCommit
org.apache.shardingsphere.shardingjdbc.jdbc.adapter.AbstractConnectionAdapter#setAutoCommit
所以DataSourceTransactionManager在事务开始的时候是有调用conn.setAutoCommit(false)，具体的实现留给了conn的实现类。
这个conn的引用是怎么获得的呢？
通过manager的内部类得到org.springframework.jdbc.datasource.ConnectionHolder，而ConnectionHolder是在
org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin
通过datasource.getConnection得到：

所以问题回到datasource.getConnection