Spring事务管理的失效和Proxy类型的DataSource

Spring事务管理的失效和Proxy类型的DataSource

 

       在服务框架中，我们由于需要将DataSource作为第三方服务暴露给其他模块（此处是十分不推荐的，因为如果作为服务那么首先就要求该服务没有状态），因此就采用Jdk的Proxy来实现虚拟DataSource暴露给其他模块以及第三方。

 

环境：

       采用ASF(基于SCA服务框架的应用服务框架)暴露DataSource作为第三方服务，其他模块的Ibatis 的SqlMapClient和Spring的TransactionManager都注入了这个Proxy类型的DataSource。

 

问题：

       发现Spring注入DataSource的Proxy以后，使用是正常的，但是事务却失效了，JDBC事务失效。

 

分析：

       跟踪察看了spring的代码，发现原来spring中的TransactionManager在事务启动和结束的时候，都是首先将DataSource和ConnectionHolder在ThreadLocal中保存，然后在事务过程中获取的都是保存过的Connection，出错也是会滚该Connection。

       但是由于当前使用的是Proxy的DataSource，虽然每一次Call的时候都是调用同一个DataSource，但是在事务开始的时候，获取的是注入到TransactionManager中的DataSource Proxy，在事务进行过程中，使用的是新的Proxy，在ThreadLocal中Map中存在了两份DataSource Proxy的信息也就是有两份ConnectionHolder，这导致在事务开始的时候，将connection的autocommit为false，然后放入到第一个DataSource Proxy作为Key的Entry中，无法被后面事务进行所获取，事务进行的时候默认将会通过DataSource产生一个新的Connection同时autocommit失效，因此产生了事务失效的问题。

 

Spring的事务处理流程图：

图 1 Spring 事务处理流程图

 

解决方法：

       其实只需要让Spring 的TransactionManager能够将DataSource真实实例获得并作为Entry Key保存到ThreadLocal中即可，那么就有两种方式，一种将就是将分开的配置放在一起，那么这里看TransactionManager应该是外部不需要配置的，可以和DataSource配置在一个spring中，那么就不需要用Proxy的方式，另一种不得不用Proxy的方式，例如对于Ibatis的SqlMapClient。处理方法如下：

 

图 2 DataSource 解决方法类图

 

       不再将DataSource作为服务暴露给第三方，而是将内部封装DataSource的IDataSourceHandler来作为服务暴露，同时调用方通过工厂类直接将IDataSourceHandler服务注入，就可以达到在调用方这边获取到的是DataSource的实例，但是需要注意的就是，由于ASF服务框架是动态随机加载各个组件，可能在服务被调用的时候尚未发布，因此需要在注入的时候设置为lazy-init为true。

 

结论：

       Proxy被运用约来广泛，但是也会造成一些再运用Proxy代理的实例作为框架业务逻辑的情况，必须弄清楚情况然后选择如何调用和组装，同时作为服务暴露给第三方，尽量选择无状态的接口服务。