Spring-事务管理
2016-05-28 15:02
513 查看
前段时间,小编在研究spring源码,这部分的时候,顺便看看了ssm框架的搭建,中间正好涉及到事务管理的配置和应用,所以就来写一写自己对spring事务的了解,这里就不研究事务的源码了,只是应用层的研究,会用即可的程度。
一、事务分析
大家也许对事务的概念不默认,最经典的例子就是我去银行取钱,害怕钱没到手,但是卡中的余额扣除了,相信有了事务的存在,再也不会出现这样的问题了。
在 Spring 中,事务是通过 TransactionDefinition 接口来定义的。该接口包含与事务属性有关的方法。
代码如下:
大家发现接口中只有属性,没有方法的存在,因为所有相关属性的方法都是我们自己定义的,都是由程序员来控制的。Spring 进行事务操作的时候,通过调用以上接口提供的方法必须能够返回事务相关的属性取值。
下面就具体来看一下:
事务隔离级别IsolationLevel:
隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量:
TransactionDefinition.ISOLATION_DEFAULT:这是默认值,表示使用底层数据库的默认隔离级别。对大部分数据库而言,通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED:该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读,因此很少使用该隔离级别。
TransactionDefinition.ISOLATION_READ_COMMITTED:该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读,这也是大多数情况下的推荐值。
TransactionDefinition.ISOLATION_REPEATABLE_READ:该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询,并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询,这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。
TransactionDefinition.ISOLATION_SERIALIZABLE:所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。
事务传播行为:
所谓事务的传播行为是指,如果在开始当前事务之前,一个事务上下文已经存在,此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量:
TransactionDefinition.PROPAGATION_REQUIRED:如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。
TransactionDefinition.PROPAGATION_REQUIRES_NEW:创建一个新的事务,如果当前存在事务,则把当前事务挂起。
TransactionDefinition.PROPAGATION_SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。
TransactionDefinition.PROPAGATION_MANDATORY:如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。
TransactionDefinition.PROPAGATION_NESTED:如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。
这里需要指出的是,前面的六种事务传播行为是 Spring 从 EJB 中引入的,他们共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 启动的事务内嵌于外部事务中(如果存在外部事务的话),此时,内嵌事务并不是一个独立的事务,它依赖于外部事务的存在,只有通过外部的事务提交,才能引起内部事务的提交,嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点(SavePoint)的概念,那嵌套事务就很容易理解了,其实嵌套的子事务就是保存点的一个应用,一个事务中可以包括多个保存点,每一个嵌套子事务。另外,外部事务的回滚也会导致嵌套子事务的回滚。
事务超时Timeout:
顾名思义,当一个事务执行的时间超过限制时间时,事务没有完成,则自动回滚。
事务的只读属性isReadOnly
事务的只读属性是指,对事务性资源进行只读操作或者是读写操作。所谓事务性资源就是指那些被事务管理的资源,比如数据源、 JMS 资源,以及自定义的事务性资源等等。如果确定只对事务性资源进行只读操作,那么我们可以将事务标志为只读的,以提高事务处理的性能。在 TransactionDefinition 中以 boolean 类型来表示该事务是否只读。
二、事务应用
Spring 框架中,涉及到事务管理的 API 大约有100个左右,其中最重要的有三个:TransactionDefinition、PlatformTransactionManager、TransactionStatus。所谓事务管理,其实就是“按照给定的事务规则来执行提交或者回滚操作”。“给定的事务规则”就是用 TransactionDefinition 表示的,“按照……来执行提交或者回滚操作”便是用 PlatformTransactionManager 来表示,而 TransactionStatus 用于表示一个运行着的事务的状态。打一个不恰当的比喻,TransactionDefinition 与 TransactionStatus 的关系就像程序和进程的关系。在解读源码的过程中都会看到这些内容。
1、编程式事务管理
我记得自己在铁科院工作的时候,事务是作为参数写到方法块中,我们需要在调用过程中写beginTransaction()、commit()、rollback()等事务管理相关的方法,后来才知道学名叫做编程式事务管理。通过Spring提供的事务管理API,我们可以在代理中灵活控制事务的执行,在底层,Spring仍然将事务操作委托给底层的持久化框架来执行的。
但是编程式事务在实际当中使用的不是很多,尤其是在java方面,所以Spring引入了声明式事务管理。
2、声明式事务管理
关于声明式事务,是建立在Spring AOP基础上的,其本质是对方法前后进行拦截,然后在目标方法开始之前创建或者加入一个事务,在执行完目标方法之后根据执行情况提交或者回滚。
声明式最大的优点就是不需要通过编程来管理事务,不需要任何事务代码,只需要在配置文件中进行事务规则声明,便可以将事务规则应用到业务逻辑中。由于事务本身就是一个典型的横切逻辑,正是AOP的用武之地,这样事务和AOP结合起来使用,更加灵活。
通常情况下,小编建议使用声明式事务,不仅简单,而且不会污染业务代码,方便日后维护。
和编程式事务相比,声明式事务唯一不足地方是,后者的最细粒度只能作用到方法级别,无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求,也存在很多变通的方法,比如,可以将需要进行事务管理的代码块独立为方法等等。
我们来具体看看声明式事务的发展吧!
1)基于 TransactionInterceptor 的事务管理示例配置文件
配置好了 TransactionInterceptor,我们还需要配置一个 ProxyFactoryBean 来组装 target 和advice。这也是典型的 Spring AOP 的做法。通过 ProxyFactoryBean 生成的代理类就是织入了事务管理逻辑后的目标类。至此,声明式事务管理就算是实现了。我们没有对业务代码进行任何操作,所有设置均在配置文件中完成,这就是声明式事务的最大优点。
2)基于 TransactionProxyFactoryBean 的事务管理示例配置文件
通过对比,配置文件与先前相比简化了很多。我们把这种配置方式称为 Spring 经典的声明式事务管理。在早期使用 Spring 的开发人员对这种配置声明式事务的方式非常熟悉。但是,显式为每一个业务类配置一个 TransactionProxyFactoryBean 的做法将使得代码显得过于刻板,为此我们可以使用自动创建代理的方式来将其简化,使用自动创建代理是纯 AOP 知识,请读者参考相关文档,不在此赘述。
3)基于 的事务管理示例配置文件
上面这种方式在小编自己在搭建ssm框架时,使用的声明式事务。使用了切点表达式,不需要针对每一个业务类创建一个代理对象了,另外,如果配置了事务管理器Bean的名字取值为“transactionManager”,则我们可以省略 的 transaction-manager 属性,因为该属性的默认值即为“transactionManager”。
4)基于 @Transactional 的事务管理示例配置文件
除了基于命名空间的事务配置方式,Spring 2.x 还引入了基于 Annotation 的方式,具体主要涉及@Transactional 标注。@Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时,该类的所有 public 方法将都具有该类型的事务属性,同时,我们也可以在方法级别使用该标注来覆盖类级别的定义。Spring 使用 BeanPostProcessor 来处理 Bean 中的标注,因此我们需要在配置文件中作如下声明来激活该后处理 Bean。
综上四种配置方法,我们最常使用的是第三种和第四种方式,前两种有助于我们研究事务源码时来学习。
通过学习,才知道长城不是一天垒成的,Spring公司真的是花费了千辛万苦走到今天,而事务仅仅是一小部分而已。
一、事务分析
大家也许对事务的概念不默认,最经典的例子就是我去银行取钱,害怕钱没到手,但是卡中的余额扣除了,相信有了事务的存在,再也不会出现这样的问题了。
在 Spring 中,事务是通过 TransactionDefinition 接口来定义的。该接口包含与事务属性有关的方法。
代码如下:
public interface TransactionDefinition{ int getIsolationLevel(); int getPropagationBehavior(); int getTimeout(); boolean isReadOnly(); }
大家发现接口中只有属性,没有方法的存在,因为所有相关属性的方法都是我们自己定义的,都是由程序员来控制的。Spring 进行事务操作的时候,通过调用以上接口提供的方法必须能够返回事务相关的属性取值。
下面就具体来看一下:
事务隔离级别IsolationLevel:
隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量:
TransactionDefinition.ISOLATION_DEFAULT:这是默认值,表示使用底层数据库的默认隔离级别。对大部分数据库而言,通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
TransactionDefinition.ISOLATION_READ_UNCOMMITTED:该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读,因此很少使用该隔离级别。
TransactionDefinition.ISOLATION_READ_COMMITTED:该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读,这也是大多数情况下的推荐值。
TransactionDefinition.ISOLATION_REPEATABLE_READ:该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询,并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询,这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。
TransactionDefinition.ISOLATION_SERIALIZABLE:所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。
事务传播行为:
所谓事务的传播行为是指,如果在开始当前事务之前,一个事务上下文已经存在,此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量:
TransactionDefinition.PROPAGATION_REQUIRED:如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。
TransactionDefinition.PROPAGATION_REQUIRES_NEW:创建一个新的事务,如果当前存在事务,则把当前事务挂起。
TransactionDefinition.PROPAGATION_SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。
TransactionDefinition.PROPAGATION_MANDATORY:如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。
TransactionDefinition.PROPAGATION_NESTED:如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。
这里需要指出的是,前面的六种事务传播行为是 Spring 从 EJB 中引入的,他们共享相同的概念。而 PROPAGATION_NESTED是 Spring 所特有的。以 PROPAGATION_NESTED 启动的事务内嵌于外部事务中(如果存在外部事务的话),此时,内嵌事务并不是一个独立的事务,它依赖于外部事务的存在,只有通过外部的事务提交,才能引起内部事务的提交,嵌套的子事务不能单独提交。如果熟悉 JDBC 中的保存点(SavePoint)的概念,那嵌套事务就很容易理解了,其实嵌套的子事务就是保存点的一个应用,一个事务中可以包括多个保存点,每一个嵌套子事务。另外,外部事务的回滚也会导致嵌套子事务的回滚。
事务超时Timeout:
顾名思义,当一个事务执行的时间超过限制时间时,事务没有完成,则自动回滚。
事务的只读属性isReadOnly
事务的只读属性是指,对事务性资源进行只读操作或者是读写操作。所谓事务性资源就是指那些被事务管理的资源,比如数据源、 JMS 资源,以及自定义的事务性资源等等。如果确定只对事务性资源进行只读操作,那么我们可以将事务标志为只读的,以提高事务处理的性能。在 TransactionDefinition 中以 boolean 类型来表示该事务是否只读。
二、事务应用
Spring 框架中,涉及到事务管理的 API 大约有100个左右,其中最重要的有三个:TransactionDefinition、PlatformTransactionManager、TransactionStatus。所谓事务管理,其实就是“按照给定的事务规则来执行提交或者回滚操作”。“给定的事务规则”就是用 TransactionDefinition 表示的,“按照……来执行提交或者回滚操作”便是用 PlatformTransactionManager 来表示,而 TransactionStatus 用于表示一个运行着的事务的状态。打一个不恰当的比喻,TransactionDefinition 与 TransactionStatus 的关系就像程序和进程的关系。在解读源码的过程中都会看到这些内容。
1、编程式事务管理
我记得自己在铁科院工作的时候,事务是作为参数写到方法块中,我们需要在调用过程中写beginTransaction()、commit()、rollback()等事务管理相关的方法,后来才知道学名叫做编程式事务管理。通过Spring提供的事务管理API,我们可以在代理中灵活控制事务的执行,在底层,Spring仍然将事务操作委托给底层的持久化框架来执行的。
但是编程式事务在实际当中使用的不是很多,尤其是在java方面,所以Spring引入了声明式事务管理。
2、声明式事务管理
关于声明式事务,是建立在Spring AOP基础上的,其本质是对方法前后进行拦截,然后在目标方法开始之前创建或者加入一个事务,在执行完目标方法之后根据执行情况提交或者回滚。
声明式最大的优点就是不需要通过编程来管理事务,不需要任何事务代码,只需要在配置文件中进行事务规则声明,便可以将事务规则应用到业务逻辑中。由于事务本身就是一个典型的横切逻辑,正是AOP的用武之地,这样事务和AOP结合起来使用,更加灵活。
通常情况下,小编建议使用声明式事务,不仅简单,而且不会污染业务代码,方便日后维护。
和编程式事务相比,声明式事务唯一不足地方是,后者的最细粒度只能作用到方法级别,无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求,也存在很多变通的方法,比如,可以将需要进行事务管理的代码块独立为方法等等。
我们来具体看看声明式事务的发展吧!
1)基于 TransactionInterceptor 的事务管理示例配置文件
<bean id="transactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor"> <property name="transactionManager" ref="transactionManager" /> <property name="transactionAttributes"> <props> <prop key="delete">PROPAGATION_REQUIRED</prop> </props> </property> </bean> <bean id="bankService" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="target" ref="bankServiceTarget" /> <property name="interceptorNames"> <list> <idref bean="transactionInterceptor" /> </list> </property> </bean>
配置好了 TransactionInterceptor,我们还需要配置一个 ProxyFactoryBean 来组装 target 和advice。这也是典型的 Spring AOP 的做法。通过 ProxyFactoryBean 生成的代理类就是织入了事务管理逻辑后的目标类。至此,声明式事务管理就算是实现了。我们没有对业务代码进行任何操作,所有设置均在配置文件中完成,这就是声明式事务的最大优点。
2)基于 TransactionProxyFactoryBean 的事务管理示例配置文件
<bean id="bankService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="target" ref="bankServiceTarget"/> <property name="transactionManager" ref="transactionManager"/> <property name="transactionAttributes"> <props> <prop key="transfer">PROPAGATION_REQUIRED</prop> </props> </property> </bean>
通过对比,配置文件与先前相比简化了很多。我们把这种配置方式称为 Spring 经典的声明式事务管理。在早期使用 Spring 的开发人员对这种配置声明式事务的方式非常熟悉。但是,显式为每一个业务类配置一个 TransactionProxyFactoryBean 的做法将使得代码显得过于刻板,为此我们可以使用自动创建代理的方式来将其简化,使用自动创建代理是纯 AOP 知识,请读者参考相关文档,不在此赘述。
3)基于 的事务管理示例配置文件
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <!-- 数据源 --> <property name="dataSource" ref="dataSource" /> </bean> <!-- 通知 --> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <!-- REQUIRED 如果存在事务,则加入该事务,没有事务,则创建一个新的事务 --> <!-- SUPPORTS 如果存在事务,则加入该事务,如果没有事务,则以非事务的方式继续运行 --> <tx:method name="save*" propagation="REQUIRED" /> <tx:method name="delete*" propagation="REQUIRED" /> <tx:method name="insert*" propagation="REQUIRED" /> <tx:method name="update*" propagation="REQUIRED" /> <tx:method name="find*" propagation="SUPPORTS" read-only="true" /> <tx:method name="get*" propagation="SUPPORTS" read-only="true" /> <tx:method name="select*" propagation="SUPPORTS" read-only="true" /> </tx:attributes> </tx:advice> <!-- aop 事务控制 --> <aop:config> <aop:advisor advice-ref="txAdvice" pointcut="execution(* cn.tgb.ssm.service.impl.*.*(..))" /> </aop:config>
上面这种方式在小编自己在搭建ssm框架时,使用的声明式事务。使用了切点表达式,不需要针对每一个业务类创建一个代理对象了,另外,如果配置了事务管理器Bean的名字取值为“transactionManager”,则我们可以省略 的 transaction-manager 属性,因为该属性的默认值即为“transactionManager”。
4)基于 @Transactional 的事务管理示例配置文件
除了基于命名空间的事务配置方式,Spring 2.x 还引入了基于 Annotation 的方式,具体主要涉及@Transactional 标注。@Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时,该类的所有 public 方法将都具有该类型的事务属性,同时,我们也可以在方法级别使用该标注来覆盖类级别的定义。Spring 使用 BeanPostProcessor 来处理 Bean 中的标注,因此我们需要在配置文件中作如下声明来激活该后处理 Bean。
<tx:annotation-driven transaction-manager="transactionManager"/>
综上四种配置方法,我们最常使用的是第三种和第四种方式,前两种有助于我们研究事务源码时来学习。
通过学习,才知道长城不是一天垒成的,Spring公司真的是花费了千辛万苦走到今天,而事务仅仅是一小部分而已。
相关文章推荐
- 一个jar包里的网站
- 一个jar包里的网站之文件上传
- 一个jar包里的网站之返回对媒体类型
- Spring和ThreadLocal
- Spring Boot 开发微服务
- Spring整合Quartz(JobDetailBean方式)
- Spring整合Quartz(JobDetailBean方式)
- SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行
- 浅析SQL Server中包含事务的存储过程
- Mysql中的事务是什么如何使用
- MySql的事务使用与示例详解
- C#分布式事务的超时处理实例分析
- C#中的事务用法实例分析
- SQL Server的事务操作隔离模式介绍
- MySQL中事务概念的简洁学习教程
- C#处理Access中事务的方法
- 在ASP.NET 2.0中操作数据之六十一:在事务里对数据库修改进行封装
- oracle 合并查询 事务 sql函数小知识学习
- 模拟Spring的简单实现