前言
本文基本算第19章 Spring事务王国的架构的重新整理。
Spring事务分析(2)–基于声明式的事务管理实现分析对源码的分析也比较好,注意学习其分析源码的方式:通过画UML图来分析,更重要的是,这些UML图位于逻辑主线的关键节点上。
Transaction Management 官方文档不可不看,几张图还是非常精到的。
spring 事务重点就两块:
- 通过 TransactionDefinition、PlatformTransactionManager、TransactionStatus 提供基本抽象
- 通过代理模式将第一点提到的抽象加入到业务代码中,通过注解简化编程式事务代码。代码技巧上小结一下就是:通过注解隐藏代理模式
先从编程式事务说起
public void serviceMethod(){
TransactionDefinition definition = ...;
PlatformTransactionManager transactionManager = ...;
TransactionStatus txStatus = transactionManager.getTransaction(definition);
try {
// dao1.doDataAccess();
// dao2.doDataAccess();
// ...
}catch(DataAccessException e){
transactionManager.rollback(txStatus);
throw e;
}catch(OtherNecessaryException e){
transactionManager.rollback(txStatus);
throw e;
}
transactionManager.commit(txStatus);
}
TransactionDefinition、PlatformTransactionManager、TransactionStatus是spring tx提供的三个基本抽象。
Spring的事务框架设计理念的基本原则是:让事务管理的关注点与数据访问关注点相分离。如上图,try代码块数据还按照原来的方式访问,不管是datasource、hibernate还是其他数据源,亦或是rpc服务,怎么变化,try代码块之外的事务代码可以岿然不动。
通过注解简化编程式事务代码
声明式事务,如何从代码上将事务与数据访问分离?
从常规路线来说,一般从配置解析开始,spring tx将配置存到一些数据类中。
<!-- 声明事务管理器,并支持事务注解 -->
<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<tx:annotation-driven transaction-manager="txManager" />
宏观上,spring aop 一般涉及到ProxyFactoryBean,spring启动时,识别标记有@transactional的方法的类,并将其关联到TransactionProxyFactoryBean。使得 ioc 返回带@Transactional 方法的类的实例时,返回的是代理类实例。
如何识别@transactional?
-
对于spring aop, spring源码分析之——spring aop原理 从代码上看,Spring AOP 实现一个InstantiationAwareBeanPostProcessor接口的bean。在每次bean初始化的时候找到所有advisor(spring ioc启动时,会采集类信息存储在BeanDefinition中),根据pointcut 判断是不是需要为将实例化的bean生成代理,如果需要,就把advice编制在代理对象里面。
而spring tx 在解析
<tx:annotation-driven transaction-manager="txManager" />
会向ioc 注册 advisor 的BeanDefinition。也就是说,使用spring aop,额外支持一个注解时,向ioc注册一个advisor的BeanDefinition即可。当然,自己定义BeanPostProcessor,直接处理自定义注解也是可以的。 -
对于aspectj,定义切点就比较直接了。
public aspect AnnotationTransactionAspect extends AbstractTransactionAspect { private pointcut executionOfTransactionalMethod() :execution(@Transactional * *(..)); }
TransactionProxyFactoryBean 抛开ProxyFactoryBean功能,其功能点转向了其成员TransactionInterceptor,TransactionInterceptor实现了MethodInterceptor。
public interface MethodInterceptor extends Interceptor {
/**
* Implement this method to perform extra treatments before and
* after the invocation.
* /
Object invoke(MethodInvocation invocation) throws Throwable;
}
其invoke方法,在实际方法invocation 执行的前后,做了事务相关的处理。基本套路就是构造一个大杂烩的”能力对象”TransactionInfo,然后在各个场景应用它。逻辑比我们想的复杂,用于实现各种”传播”行为。
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
Object retVal = null;
try {
retVal = invocation.proceedWithInvocation();
}catch (Throwable ex) {
completeTransactionAfterThrowing(txInfo, ex);
throw ex;
}finally {
cleanupTransactionInfo(txInfo);
}
commitTransactionAfterReturning(txInfo);
return retVal;
TransactionAspectSupport==> | PlatformTransactionManager==> | 子类 | 含义 | |
---|---|---|---|---|
涉及到的对象 | TransactionInfo | TransactionStatus、TransactionAttribute | Object | TransactionStatus是一系列状态对象组成的聚合类;到子类时,则不用返回TransactionStatus,只需返回其中一个transaction(Object类型)成员即可 |
方法 | invokeWithinTransaction | TransactionStatus getTransaction(TransactionDefinition definition); | Object doGetTransaction() | 根据配置数据获取当前状态 |
void commit(TransactionStatus status | void doCommit(DefaultTransactionStatus status) | |||
void rollback(TransactionStatus status) | void doRollback(DefaultTransactionStatus status) |
从某种程度上,transactionManager子类方法跟servlet的init、doGet、destroy作用是一样的。
2018.01.07 补充spring 官方图
实现一个简单的PlatformTransactionManager
PlatformTransactionManager是整个事务抽象策略的顶层接口,它就好像我们的战略蓝图,而战略的具体实施则将由相应的PlatformTransactionManager实现类来执行。
以JDBC数据访问方式的局部事务管理为例,统一中原的过程(1),其基本原理是:保证两个dao的数据访问方法使用的是同一个java.sql.Connection,这样PlatformTransactionManager的commit和rollback就可以转化为conn的对应方法。
采用称为connection-passing的方式,org.springframework.jdbc.datasource.DataSourceTransactionManager
在事务开始时,获取一个conneciton,将其挂到当前线程,随后dao层在获取connection时,先尝试从当前线程获取Connection,(无则新建),然后使用Connection进行数据操作。可以看出,Spring的事务管理与它的数据访问框架是紧密结合的。
事务中的一些概念
对于TransactionDefinition的命名,可以联系spring ioc中的BeanDefinition
- 事务的隔离级别,并发事务的相互影响
- 事务的传播行为,直接说,就是一个标记了@Transactional的方法,调用了另一个标记了@Transactional的方法。后一个方法的失败是否会影响前一个方法。
- 事务的超时时间
- 是否为只读事务
事务实现的其它问题
- 事务数据的持久化。mysql 有redo 和undo log。因此mysql的关闭不影响事务,但业务系统因为更新代码等原因,经常要重新启动,若不能在重启启动时恢复或回滚事务,则会对系统的一致性造成比较大的影响。changmingxie/compensable-transaction 中包含的了数据的存储逻辑。
一个@Transactional 失效问题的排查
有一个看到一个@Transactional 失效的问题,并且奇怪的是本地测试生效,测试环境不生效。我们知道@Transactional 的实现原理是
- 对于@Transactional 注解方法的两次jdbc 操作
- 先尝试从ThreadLocal 中获取数据库连接,若有,则使用该数据库连接。若没有,则向数据库连接池申请。以确保两次jdbc 操作均使用同一个数据库连接。
当时实在是没办法了,便将spring-tx 包的日志放开,想看下 数据库连接的申请和释放过程,以确保两次操作用的是同一个数据库连接。但从日志看,事务管理器生效了,但管控的不是jdbc 操作的数据库连接,为何呢?<tx:annotation-driven />
在项目代码中配置了多个,项目用到了两个不同的db,包含在不同的spring jdbc context文件中,且本地环境和测试环境配置文件中spring jdbc context 引入的顺序不同。实际运行时,第一个配置的<tx:annotation-driven />
生效。
小结
通过对spring事务的分析,可以学到:
- 自定义
<tx:annotation-driven transaction-manager="txManager" />
表现,将其转化特定的数据结构TransactionDefinition及其TransactionAttribute - 通过aspectj或spring aop,通过注解的方式与现有代码协作,囊括前置、后置、切面、异常处理等所有可能