Spring transaction事务 roll back各种回滚

 Spring的AOP事务管理默认是针对unchecked exception回滚。

也就是默认对RuntimeException()异常极其子类进行事务回滚。

Exception作为基类,下面还分checked exception和unchecked exception。如果客户端可以通过其他的方法恢复异常,那么这种异

常就是checked exception;如果客户端对出现的这种异常无能为力,那么这种异常就是Unchecked exception;简单来说,继承于

RuntimeException的都是unchecked exception。

Error:
1.总是不可控制的(unchecked)
2.经常用来用于表示系统错误或低层资源的错误
3.如何可能的话,应该在系统级被捕捉

Exception:
1.可以是可被控制(checked) 或不可控制的(unchecked)
2.表示一个由程序员导致的错误
3.应该在应用程序级被处理

Java 中定义了两类异常:
1) Checked exception: 这类异常都是Exception的子类。异常的向上抛出机制进行处理,假如子类可能产生A异常,那么在父类中

也必须throws A异常。可能导致的问题:代码效率低,耦合度过高。
2) Unchecked exception: 这类异常都是RuntimeException的子类,虽然RuntimeException同样也是Exception的子类,但是它们是

非凡的,它们不能通过client code来试图解决,所以称为Unchecked exception 。

解决办法:

1.在针对事务的类中抛出RuntimeException异常,而不是抛出Exception。

2.在txAdive中增加rollback-for,里面写自己的exception,例如自己写的exception为

com.cn.untils.exception.***Exception

<tx:advice id="txAdvice" transaction-manager="transactionManager">
  <tx:attributes>
    <tx:method name="*" rollback-for="com.cn.untils.exception.***Exception"/>
  </tx:attributes>
</tx:advice>

或者

定义不会滚的异常

<tx:advice id="txAdvice">
   <tx:attributes>
      <tx:method name="update*" no-rollback-for="IOException"/>
      <tx:method name="*"/>
   </tx:attributes>
</tx:advice>

spring事务回滚.默认情况,unchecked异常,即运行时异常runntimeException回滚事务;checked异常,即Exception可try{}捕获的不会回滚.当然也可配置spring参数让其回滚.




试验方法:

         写一个单元测试,调用一个service层方法(发生对数据库进行写操作的方法--insert、update、delete)即可.

 

 

试验过程:

         定义一个service方法如下:

         public SMSTiming createSMSTiming(SMSTiming smsTiming){

                   SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

                   return s;

         }

 

         定义二个异常(先默认配置TestException为Spring事务回滚异常):

            publicclass MyTestException extends Exception

            publicclass TestException extends Exception

 

         注意看下:每次这个方法的不同处(抛出的异常不同)。

 

测试1

public SMSTiming createSMSTiming(SMSTiming smsTiming){

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       int i = 4/0; //人为产生异常(实际这里抛出了ArithmeticException运行异常)

       return s;

    }

测试1结果:会事务回滚----数据库中未插入新数据。

 

 

测试2

        public SMSTiming createSMSTiming(SMSTiming smsTiming) throws Exception{//受检异常(非运行异常)必须抛出

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       try{

           int i = 4/0; //人为产生异常

       }catch(Exception e){

           thrownew Exception ("");//抛出Exception异常

       }

       return s;

    }

测试2结果:不会事务回滚----数据库中插入新数据。

 

        

测试3

            public SMSTiming createSMSTiming(SMSTiming smsTiming) throws RuntimeException{//运行异常(非受检异常)可以不抛出

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       try{

           int i = 4/0; //人为产生异常

       }catch(Exception e){

           thrownewRuntimeException("");//抛出RuntimeException异常

       }

       return s;

    }

测试3结果:会事务回滚----数据库中未插入新数据

 

测试4

        public SMSTiming createSMSTiming(SMSTiming smsTiming) throws TestException{//受检异常(非运行异常)必须抛出

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       try{

           int i = 4/0; //人为产生异常

       }catch(Exception e){

           thrownewTestException("");//抛出TestException异常

       }

       return s;

    }

测试4结果:会事务回滚----数据库中未插入新数据。

 

测试5

    public SMSTiming createSMSTiming(SMSTiming smsTiming) throws MyTestException{//受检异常(非运行异常)必须抛出

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       try{

           int i = 4/0; //人为产生异常

       }catch(Exception e){

           thrownewMyTestException("");//抛出MyTestException异常

       }

       return s;

    }

 测试5结果:不会事务回滚----数据库中插入新数据。

 

测试6

    public SMSTiming createSMSTiming(SMSTiming smsTiming) throws MyTestException{//受检异常(非运行异常)必须抛出 (注意:此时spring指定配置此异常回滚)

       SMSTiming s= this.getSmsTimingDAO().createSMSTiming(smsTiming);

       try{

           int i = 4/0; //人为产生异常

       }catch(Exception e){

           thrownewMyTestException("");//抛出MyTestException异常

       }

       return s;

    }

 测试6结果:会事务回滚----数据库中未插入新数据。

 

 

试验总结:

测试1、测试3、测试4、测试6会进行事务回滚;测试2、测试5不会进行事务回滚。

 

为什么会这样?因为是异常的类型(受检异常、运行时异常)不同或使用了Springrollback-for配置

 

测试1和测试3是因为抛出了运行时异常,会事务回滚。

 

测试4和测试5、测试6分别抛出受检异常TestException、MyTestException,那为什么测试4和测试6会事务回滚呢?

因为是我们在Spring事务配置中指定了此异常(指定rollback-for)。

 

 

Spring框架的事务基础架构代码将默认地  在抛出运行时和unchecked exceptions时才标识事务回滚。 也就是说,当抛出一个RuntimeException 或其子类例的实例时。(Errors 也一样 - 默认地 - 标识事务回滚。)从事务方法中抛出的Checked exceptions将  被标识进行事务回滚

### Spring 框架事务管理源码详解 #### 1. 基本概念 Spring事务管理机制基于 AOP(面向切面编程)。它通过代理模式实现了声明式事务管理和程序化事务管理。在声明式事务中,`@Transactional` 注解是最常见的形式之一。 事务的核心特性包括 ACID 属性[^1]: - **Atomicity (原子性)**:事务中的所有操作要么全部完成,要么全部不完成。 - **Consistency (一致性)**:事务执行前后数据库状态保持一致。 - **Isolation (隔离性)**:并发事务之间互不影响。 - **Durability (持久性)**:一旦事务提交,其结果永久保存。 此外,Spring 提供了多种事务传播行为和隔离级别设置选项[^1]。 --- #### 2. Spring 事务的执行过程 ##### 2.1 事务 AOP 实现原理 Spring 使用 `ProxyFactoryBean` 或 CGLIB 动态代理技术来实现事务拦截功能。当方法被调用时,实际会触发事务拦截器 `TransactionInterceptor` 中的方法逻辑。 以下是核心流程概述: - 方法调用前,判断当前是否存在事务上下文。 - 如果不存在,则尝试创建新事务;如果存在,则根据传播行为决定如何处理现有事务。 - 执行目标方法并捕获异常情况。 - 根据执行结果决定提交还是回滚事务。 ##### 2.2 创建事务的过程 在 `createTransactionIfNecessary()` 方法中完成了事务的实际创建工作。此方法主要依赖于底层平台事务管理器(PlatformTransactionManager)接口的具体实现类。 对于 JDBC 数据库访问场景,默认使用的是 `DataSourceTransactionManager` 类型实例作为事务管理者。它的职责包括开启连接、标记只读标志以及注册同步回调函数等操作[^1]。 ```java // TransactionSynchronizationManager 是线程绑定工具类 TransactionSynchronizationManager.initSynchronization(); ``` ##### 2.3 清理线程本地存储信息 每当一个事务结束之后都需要清理掉与之关联的各种资源对象以便释放内存空间。这部分由 `doCleanupAfterCompletion()` 完成[^1]: ```java if (synchronizationsActive && !isExistingTransaction) { TransactionSynchronizationUtils.triggerBeforeCommit(syncList, readOnly); } ``` ##### 2.4 提交事务 正常情况下,在业务逻辑成功完成后将调用 commit() 来正式确认更改内容已写入磁盘文件系统或者远程服务端点之中去。 ```java try { transaction.commit(status); // 调用具体实现者的commit方法 } catch (RuntimeException ex) { throw new TransactionSystemException( "Could not roll back JPA transaction", ex); } ``` ##### 2.5 处理异常 如果发生未被捕获的运行期错误则自动触发 rollback 流程以撤销之前所做的修改动作从而保护数据完整性不受破坏。 --- #### 3. 配置方式对比 ###### XML 方式的配置 传统项目可能仍然采用 XML 文件定义 Bean 和事务规则的方式来进行初始化加载等工作流控制活动[^2]: ```xml <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="*" propagation="REQUIRED"/> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut expression="execution(* com.example.service.*Service.*(..))" id="serviceOperation"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="serviceOperation"/> </aop:config> ``` 同时还需要引入 context 名字空间及其对应的 XSD 地址链接地址才能正常使用某些高级特性和扩展插件等功能模块[^4]. ###### Java Config 的方式 现代开发更倾向于利用纯注解的方式来简化繁琐复杂的 XML 编辑任务量,并且能够获得更好的 IDE 支持效果体验感更强一些[^2]: ```java @Configuration @EnableTransactionManagement public class AppConfig { @Bean public DataSource dataSource() { EmbeddedDatabaseBuilder builder = new EmbeddedDatabaseBuilder(); return builder.setType(EmbeddedDatabaseType.HSQL).build(); } @Bean public PlatformTransactionManager transactionManager() { return new DataSourceTransactionManager(dataSource()); } } ``` --- #### 4. 特殊场景下的事务管理 当应用程序涉及到跨多个不同类型的资源(如关系型数据库 + NoSQL 存储引擎组合方案设计架构下),单纯依靠单一的数据源无法满足需求时就需要借助分布式全局协调者角色——即 JTA 技术标准协议栈解决方案[^3] : ```xml <bean id="jtaTxMgr" class="org.springframework.transaction.jta.JtaTransactionManager"/> <!-- Or using properties --> @Bean public JtaTransactionManager jtaTransactionManager(){ UserTransaction userTransaction = ...; TransactionManager tm = ...; JtaTransactionManager manager = new JtaTransactionManager(userTransaction,tm); return manager ; } ``` 这种做法虽然强大但也增加了复杂度因此仅适用于特定场合才考虑实施部署上线运营维护管理工作当中去实践探索前行道路方向图景蓝图构想规划构思创意灵感源泉动力支撑保障体系结构框架模型理论依据参考资料文献出处来源背景介绍说明解释阐述论证分析研究探讨交流分享学习进步成长发展提升优化改进完善健全成熟稳定可靠安全高效便捷快速及时准确无误正确有效果显著成果明显优势突出特点鲜明特色独具风格独树一帜独一无
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值