Spring对事务的解决办法其实分为2种:编程式实现事务,AOP配置声明式解决方案。 Spring提供了许多内置事务管理器实现,常用的有以下几种:
两个不依赖于应用服务器的开源JTA事务实现组件:JOTM和Atomikos Transactions Essentials 具体用法参考http://jinnianshilongnian.iteye.com/blog/1439900 这篇博客讲解了对于JDBC和JTA分别用PlatformTransactionManager实现和使用TransactionTemplate实现编程式事务管理:http://jinnianshilongnian.iteye.com/blog/1441271 编程式实现事务 Spring提供两种编程式事务支持:直接使用PlatformTransactionManager实现和使用TransactionTemplate模板类,用于支持逻辑事务管理。 如果采用编程式事务推荐使用TransactionTemplate模板类。 Spring框架支持事务管理的核心是事务管理器抽象,对于不同的数据访问框架(如Hibernate)通过实现策略接口PlatformTransactionManager,从而能支持各种数据访问框架的事务管理,PlatformTransactionManager接口定义如下:
http://jinnianshilongnian.iteye.com/blog/1439900
Spring声明式事务
<tx:advice/>配置详解
XML形式的事务配置<tx:method >的属性详解
readOnly 事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。如果值为true就会告诉Spring我这个方法里面没有insert或者update,你只需要提供只读的数据库Connection就行了,这种执行效率会比read-write的Connection高,所以这是一个最优化提示。在一些情况下,一些事务策略能够起到显著的最优化效果,例如在使用Object/Relational映射工具(如:Hibernate或TopLink)时避免dirty checking(试图“刷新”)。 timeout 在属性中还有定义“timeout”值的选项,指定事务超时为几秒。一般不会使用这个属性。在JTA中,这将被简单地传递到J2EE服务器的事务协调程序,并据此得到相应的解释。 Isolation Level(事务隔离等级)的5个枚举值 为什么事务要有Isolation Level这个属性?先回顾下数据库事务的知识: 第一类丢失更新(lost update):在完全未隔离事务的情况下,两个事物更新同一条数据资源,某一事物异常终止,回滚造成第一个完成的更新也同时丢失。 第二类丢失更新(second lost updates):是不可重复读的特殊情况,如果两个事务都读取同一行,然后两个都进行写操作,并提交,第一个事务所做的改变就会丢失。 脏读(dirty read):如果第二个事务查询到第一个事务还未提交的更新数据,形成脏读。因为第一个事务你还不知道是否提交,所以数据不一定是正确的。 虚读(phantom read):一个事务执行两次查询,第二次结果集包含第一次中没有或者某些行已被删除,造成两次结果不一致,只是另一个事务在这两次查询中间插入或者删除了数据造成的。 不可重复读(unrepeated read):一个事务两次读取同一行数据,结果得到不同状态结果,如中间正好另一个事务更新了该数据,两次结果相异,不可信任。 具体关于事务机制可以看我以前的博客:http://zhou137520.iteye.com/admin/blogs/1638574 当遇到以上这些情况时我们可以设置isolation下面这些枚举值: DEFAULT:采用数据库默认隔离级别 SERIALIZABLE:最严格的级别,事务串行执行,资源消耗最大; REPEATABLE_READ:保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的数据。避免了“脏读取”和“不可重复读取”的情况,但是带来了更多的性能损失。 READ_COMMITTED:大多数主流数据库的默认事务等级,保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”。该级别适用于大多数系统。 READ_UNCOMMITTED:保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。 关于propagation属性的7个传播行为 REQUIRED:指定当前方法必需在事务环境中运行,如果当前有事务环境就加入当前正在执行的事务环境,如果当前没有事务,就新建一个事务。这是默认值。 SUPPORTS:指定当前方法加入当前事务环境,如果当前没有事务,就以非事务方式执行。 MANDATORY:指定当前方法必须加入当前事务环境,如果当前没有事务,就抛出异常。 REQUIRES_NEW:指定当前方法总是会为自己发起一个新的事务,如果发现当前方法已运行在一个事务中,则原有事务被挂起,我自己创建一个属于自己的事务,直我自己这个方法commit结束,原先的事务才会恢复执行。 NOT_SUPPORTED:指定当前方法以非事务方式执行操作,如果当前存在事务,就把当前事务挂起,等我以非事务的状态运行完,再继续原来的事务。 NEVER:指定当前方法绝对不能在事务范围内执行,如果方法在某个事务范围内执行,容器就抛异常,只有没关联到事务,才正常执行。 NESTED:指定当前方法执行时,如果已经有一个事务存在,则运行在这个嵌套的事务中.如果当前环境没有运行的事务,就新建一个事务,并与父事务相互独立,这个事务拥有多个可以回滚的保证点。就是指我自己内部事务回滚不会对外部事务造成影响,只对DataSourceTransactionManager事务管理器起效。 注解形式@Transactional实现事务管理 注意@Transactional只能被应用到public方法上,对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能。 默认情况下,一个有事务的方法,遇到RuntiomeException时会回滚。遇到受检查的异常是不会回滚的,要想所有异常都回滚,要加上属性rollbackFor={Exception.class}
transaction-manager:指定事务管理器名字,默认为transactionManager,当使用其他名字时需要明确指定; proxy-target-class:默认false表示使用JDK代理,如果为true将使用CGLIB代理 order:定义事务通知顺序,默认Ordered.LOWEST_PRECEDENCE,表示将顺序决定权交给AOP来处理。 建议只在实现类或实现类的方法上使用@Transactional,而不要在接口上使用,这是因为如果使用JDK代理机制是没问题,因为其使用基于接口的代理;而使用使用CGLIB代理机制时就会遇到问题,因为其使用基于类的代理而不是接口,这是因为接口上的@Transactional注解是“不能继承的”。 http://jinnianshilongnian.iteye.com/blog/1508018这篇博客讲解了基于JDK动态代理和CGLIB动态代理的实现Spring注解管理事务(@Trasactional)到底有什么区别。
总结
编程式事务是不推荐的,即使有很少事务操作,Spring发展到现在,没有理由使用编程式事务,只有在为了深入理解Spring事务管理才需要学习编程式事务使用。 推荐使用声明式事务,而且强烈推荐使用<tx:tags>方式的声明式事务,因为其是无侵入代码的,可以配置模板化的事务属性并运用到多个项目中。 而@Transaction注解事务,不过如果一个项目模块太多,service方法太多导致每个方法都要手动去加注解,是不是很麻烦,也容易出错。如果一个项目结构清晰,分层明确,那么标签形式的配置将是最直观和方便的办法。 总之,能保证项目正常工作的事务配置就是最好的。 |
文章转至http://zhou137520.iteye.com/blog/1675199 Spring对事务的解决办法其实分为2种:编程式实现事务,AOP配置声明式解决方案。 http://jinnianshilongnian.iteye.com/blog/1496953Spring提供了许多内置事务管理器实现,常用的有以下几种:
两个不依赖于应用服务器的开源JTA事务实现组件:JOTM和Atomikos Transactions Essentials 具体用法参考http://jinnianshilongnian.iteye.com/blog/1439900 这篇博客讲解了对于JDBC和JTA分别用PlatformTransactionManager实现和使用TransactionTemplate实现编程式事务管理:http://jinnianshilongnian.iteye.com/blog/1441271 编程式实现事务 Spring提供两种编程式事务支持:直接使用PlatformTransactionManager实现和使用TransactionTemplate模板类,用于支持逻辑事务管理。 如果采用编程式事务推荐使用TransactionTemplate模板类。 Spring框架支持事务管理的核心是事务管理器抽象,对于不同的数据访问框架(如Hibernate)通过实现策略接口PlatformTransactionManager,从而能支持各种数据访问框架的事务管理,PlatformTransactionManager接口定义如下:
http://jinnianshilongnian.iteye.com/blog/1439900
Spring声明式事务
<tx:advice/>配置详解
XML形式的事务配置<tx:method >的属性详解
readOnly 事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。如果值为true就会告诉Spring我这个方法里面没有insert或者update,你只需要提供只读的数据库Connection就行了,这种执行效率会比read-write的Connection高,所以这是一个最优化提示。在一些情况下,一些事务策略能够起到显著的最优化效果,例如在使用Object/Relational映射工具(如:Hibernate或TopLink)时避免dirty checking(试图“刷新”)。 timeout 在属性中还有定义“timeout”值的选项,指定事务超时为几秒。一般不会使用这个属性。在JTA中,这将被简单地传递到J2EE服务器的事务协调程序,并据此得到相应的解释。 Isolation Level(事务隔离等级)的5个枚举值 为什么事务要有Isolation Level这个属性?先回顾下数据库事务的知识: 第一类丢失更新(lost update):在完全未隔离事务的情况下,两个事物更新同一条数据资源,某一事物异常终止,回滚造成第一个完成的更新也同时丢失。 第二类丢失更新(second lost updates):是不可重复读的特殊情况,如果两个事务都读取同一行,然后两个都进行写操作,并提交,第一个事务所做的改变就会丢失。 脏读(dirty read):如果第二个事务查询到第一个事务还未提交的更新数据,形成脏读。因为第一个事务你还不知道是否提交,所以数据不一定是正确的。 虚读(phantom read):一个事务执行两次查询,第二次结果集包含第一次中没有或者某些行已被删除,造成两次结果不一致,只是另一个事务在这两次查询中间插入或者删除了数据造成的。 不可重复读(unrepeated read):一个事务两次读取同一行数据,结果得到不同状态结果,如中间正好另一个事务更新了该数据,两次结果相异,不可信任。 具体关于事务机制可以看我以前的博客:http://zhou137520.iteye.com/admin/blogs/1638574 当遇到以上这些情况时我们可以设置isolation下面这些枚举值: DEFAULT:采用数据库默认隔离级别 SERIALIZABLE:最严格的级别,事务串行执行,资源消耗最大; REPEATABLE_READ:保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的数据。避免了“脏读取”和“不可重复读取”的情况,但是带来了更多的性能损失。 READ_COMMITTED:大多数主流数据库的默认事务等级,保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”。该级别适用于大多数系统。 READ_UNCOMMITTED:保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。 关于propagation属性的7个传播行为 REQUIRED:指定当前方法必需在事务环境中运行,如果当前有事务环境就加入当前正在执行的事务环境,如果当前没有事务,就新建一个事务。这是默认值。 SUPPORTS:指定当前方法加入当前事务环境,如果当前没有事务,就以非事务方式执行。 MANDATORY:指定当前方法必须加入当前事务环境,如果当前没有事务,就抛出异常。 REQUIRES_NEW:指定当前方法总是会为自己发起一个新的事务,如果发现当前方法已运行在一个事务中,则原有事务被挂起,我自己创建一个属于自己的事务,直我自己这个方法commit结束,原先的事务才会恢复执行。 NOT_SUPPORTED:指定当前方法以非事务方式执行操作,如果当前存在事务,就把当前事务挂起,等我以非事务的状态运行完,再继续原来的事务。 NEVER:指定当前方法绝对不能在事务范围内执行,如果方法在某个事务范围内执行,容器就抛异常,只有没关联到事务,才正常执行。 NESTED:指定当前方法执行时,如果已经有一个事务存在,则运行在这个嵌套的事务中.如果当前环境没有运行的事务,就新建一个事务,并与父事务相互独立,这个事务拥有多个可以回滚的保证点。就是指我自己内部事务回滚不会对外部事务造成影响,只对DataSourceTransactionManager事务管理器起效。 注解形式@Transactional实现事务管理 注意@Transactional只能被应用到public方法上,对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能。 默认情况下,一个有事务的方法,遇到RuntiomeException时会回滚。遇到受检查的异常是不会回滚的,要想所有异常都回滚,要加上属性rollbackFor={Exception.class}
transaction-manager:指定事务管理器名字,默认为transactionManager,当使用其他名字时需要明确指定; proxy-target-class:默认false表示使用JDK代理,如果为true将使用CGLIB代理 order:定义事务通知顺序,默认Ordered.LOWEST_PRECEDENCE,表示将顺序决定权交给AOP来处理。 建议只在实现类或实现类的方法上使用@Transactional,而不要在接口上使用,这是因为如果使用JDK代理机制是没问题,因为其使用基于接口的代理;而使用使用CGLIB代理机制时就会遇到问题,因为其使用基于类的代理而不是接口,这是因为接口上的@Transactional注解是“不能继承的”。 http://jinnianshilongnian.iteye.com/blog/1508018这篇博客讲解了基于JDK动态代理和CGLIB动态代理的实现Spring注解管理事务(@Trasactional)到底有什么区别。
总结
编程式事务是不推荐的,即使有很少事务操作,Spring发展到现在,没有理由使用编程式事务,只有在为了深入理解Spring事务管理才需要学习编程式事务使用。 推荐使用声明式事务,而且强烈推荐使用<tx:tags>方式的声明式事务,因为其是无侵入代码的,可以配置模板化的事务属性并运用到多个项目中。 而@Transaction注解事务,不过如果一个项目模块太多,service方法太多导致每个方法都要手动去加注解,是不是很麻烦,也容易出错。如果一个项目结构清晰,分层明确,那么标签形式的配置将是最直观和方便的办法。 总之,能保证项目正常工作的事务配置就是最好的。 |