导读：一段被try-catch包裹后的代码在产线稳定运行了200天后忽然发生了异常，而这个异常竟然导致了产线事务回滚。这期间究竟发生了什么？日常在项目过程中该如何避免事务异常？...02 我们来看一下这段导致了产线事务回滚的代码，类似于下面这样的： @Transactional public void main() { // 假设有多个user的操作，需要事务控制...可能有的人和我的第一反应一样，是不是最后的userOtherProcess方法执行异常造成了methodA的事务回滚？...也安排到了这个房间，methodB虽然发生了异常且被try-catch包裹，但逃不过监事的火眼金睛，于是他按下了事务回滚的按钮。...MANDATORY：支持当前事务，如果当前没有事务，就抛出异常。 NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
上周，我们通过这篇文章《为什么catch了异常，但事务还是回滚了？》...但还是收到了很多没有理解的反馈，主要是根据前文给出的线索去跟踪，是获得到了回滚的标示和异常，而让大家不理解的是，javax.validation.ConstraintViolationException...异常不是最后也向外抛出了，那么为什么test4里catch没有能够捕获到呢？...其实这个问题并不难解释，下面就通过这篇文章，做个小实验，帮助大家进一步理解catch不到异常的原因！ 如果你还不了解这篇文章在讨论什么，建议先看之前的两篇： 《我来出个题：这个事务会不会回滚？》...所以，前文中我们跟踪的事务回滚所抛出的异常，其实是在test4中的try-catch块执行完之后才抛出的，所以内部的这个catch是无法捕获异常的，这里完全就是catch了个寂寞。
)，如果类加了这个注解，那么这个类里面的方法抛出异常，就会回滚，数据库里面的数据也会回滚。...Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。...如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。...加入在try catch中没有throw e 抛出异常，只是简单的打印异常，则异常被捕获未抛出异常去终止程序，在trycatch中的操作数据库语句插入失败，在trycatch上面和下面的数据库相关插入语句成功...，也就是程序成功跑完，数据库不会发生回滚。
在Spring Boot中，如果需要在唯一性判断不满足时进行事务回滚，可以通过以下方式实现： 首先，确保你的方法添加了@Transactional注解，这会使得该方法在一个数据库事务中执行，如果方法中出现任何异常...（如唯一性约束违反导致的ConstraintViolationException等），Spring会自动回滚事务。...由于这个方法被@Transactional注解修饰，所以当这个异常被抛出时，Spring会自动回滚当前事务中的所有数据库操作。...在Spring Boot中，如果你使用了@Transactional注解，并且在事务方法中抛出了异常，Spring框架会默认进行回滚。...如果你捕获了异常，并且不重新抛出一个RuntimeException或Error，事务将不会回滚。
---- @Transactional 注解属性propagation设置错误 这种失效是由于事务传播方式配置错误，若是错误的配置以下三种 propagation，事务将不会发生回滚。...---- @Transactional 注解属性rollbackFor设置错误 rollbackFor可以指定能够触发事务回滚的异常类型。...Spring默认抛出了未检查unchecked异常（继承自 RuntimeException的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。...如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。...如果抛出runtime exception 并在你的业务方法中没有catch到的话，事务会回滚。
NESTED： 如果一个活动的事务存在,则运行在一个嵌套的事务中.如果没有活动的事务,则按REQUIRED属性执行.它使用了一个单独的事务, 这个事务拥有多个可以回滚的保证点.内部事务回滚不会对外部事务造成影响...spring事务回滚规则 指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。...默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚...可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。...("注释");)不会回滚，即遇到受检查的异常（就是非运行时抛出的异常，编译器会检查到的异常叫受检查异常或说受检查异常）时，需我们指定方式来让事务回滚 要想所有异常都回滚，要加上 @Transactional
异常 首先了解一下异常的组成： RuntimeException() 例如：数组越界异常、空指针异常、(我们在编写之后不会提示让 try catch的异常、代码编写错误导致，可避免) 非RuntimeException...() 例如： IO异常、(会提示try catch的异常，不是代码编写错误导致的，只能抛出) unchecked异常：RuntimeException + Error checked异常：非RuntimeException...() Spring的事务机制 Spring通过异常进行事务回滚的机制： Spring 的默认事务机制，当出现unchecked异常时候回滚，checked异常的时候不会回滚； 我们有时为了打印日志...为了事务的正常生效：当有try catch后捕获了异常，事务不会回滚， 如果不得不在service层写try catch 需要catch后 throw new RuntimeException 让事务回滚...所以我们service层在添加了try catch日志打印后，抛出的runtime类异常需要在controller层进行捕获，捕获之后，在catch中编写操作失败后返回值的信息。
： public class BizException extends Exception { // 自定义异常 } 上面代码中的声明式事务在出现异常的时候，事务是不会回滚的。...在代码中我虽然捕获了异常，但是同时我也抛出了异常，为什么事务未回滚呢？猜测是异常类型不对，于是开始查询原因，翻看了Spring的官方文档，找到了答案。下面是翻译自Spring官网。...在Spring FrameWork 的事务框架中推荐的事务回滚方法是，在当前执行的事务上下文中抛出一个异常。...如果异常未被处理，当抛出异常调用堆栈的时候，Spring FrameWork 的事务框架代码将捕获任何未处理的异常，然后并决定是否将此事务标记为回滚。...在默认配置中，Spring FrameWork 的事务框架代码只会将出现runtime, unchecked 异常的事务标记为回滚；也就是说事务中抛出的异常时RuntimeException或者是其子类
前言 今天介绍一下Spring事物不生效的场景，事物是我们在项目中经常使用的，如果是Java的话，基本上都使用Spring的事物，不过Spring的事物如果使用不当，那么就会导致事物失效或者不回滚，最终导致数据不一致...如果异常使用不当，那么事物也不会生效，这里的异常有两种，一种是我们抛出的异常，一种是@Transactional注解所接受的异常。...1.如果我们在程序代码中自己捕获了异常导致Spring事物捕获不到异常，那么事物也不会生效，如下，exceptionMethod方法捕获了异常并打印异常信息，那么异常并不会被Spring事物捕获到，所以事物并不会回滚...@Transactional注解有一个属性rollbackFor，它代表回滚的异常，也就是说只有捕获到这种异常事物才会回滚，它默认的是RunTimeException。...RunTimeException，所以事物不能回滚，如果我们需要事物回滚，需要让rollbackFor指定的异常是抛出异常的父类或者和自己一样才行，如下所示。
因此，“只读事务”仅仅是一个性能优化的推荐配置而已，并非强制你要这样做不可 spring事务回滚规则 指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。...spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。...默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚...可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。...不会导致事务回滚的异常类数组 noRollbackForClassName 类名数组，必须继承自Throwable 不会导致事务回滚的异常类名字数组 用法 @Transactional
但根据之前的分析我们知道，实际上在调用saveB方法时，是直接调用的目标类中的saveB方法，在saveB方法前后并不会有事务的开启或者提交、回滚等操作，实际的流程是下面这样的 ?...❝Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务，已经执行的SQL会提交掉。...如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。 ❞ 对应代码其实我们上篇文章也分析过了，如下： ?...抛出异常 最后在这里抛出了这个异常。...显示回滚 最大的区别在于处理回滚时第二个参数传入的是false,这意味着回滚是回滚是预期之中的，所以在处理完回滚后并不会抛出异常。
a方法抛出异常后，b方法并没有进行回滚，因为Propagation.REQUIRES_NEW会暂停 a方法的事务 ) Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务...Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。...如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定 rollbackFor属性。...若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务同样会回滚。...如果抛出runtime exception 并在你的业务方法中没有catch到的话，事务会回滚。
事务超时 所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。...在 TransactionDefinition 中以 int 的值来表示超时时间，其单位是秒。...spring事务回滚规则 指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。...默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚...可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。
新建的事务将和被挂起的事务没有任何关系，是两个独立的事务，外层事务失败回滚之后，不能回滚内层事务执行的结果，内层事务失败抛出异常，外层事务捕获，也可以不处理回滚操作 PROPAGATION_SUPPORTS...a、b、e回不回滚主要看是否抛出异常。 spring 什么情况下进行事务回滚？...Spring、EJB的声明式事务默认情况下都是在抛出unchecked exception后才会触发事务的回滚 unchecked异常,即运行时异常runntimeException 回滚事务; checked...异常,即Exception可try{}捕获的不会回滚.当然也可配置spring参数让其回滚....如果抛出runtime exception 并在你的业务方法中没有catch到的话，事务会回滚。
❝ Spring 默认抛出了未检查 unchecked 异常（继承自 RuntimeException 的异常）或者 Error 才回滚事务；其他异常不会触发回滚事务，已经执行的 SQL 会提交掉。...如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定 rollbackFor 属性。...在处理回滚时又有下面这段代码 抛出异常 最后在这里抛出了这个异常。...」，所以即使我们在外部事务中 catch 了抛出的异常，整个事务仍然无法正常提交，并且如果你希望正常提交，Spring 还会抛出一个异常。...这样当提交事务时会进入下面这段代码 显示回滚 最大的区别在于处理回滚时第二个参数传入的是 false, 这意味着回滚是回滚是预期之中的，所以在处理完回滚后并不会抛出异常。
当指定rollbackFor 或者rollbackForClassName 之后，方法执行逻辑中只有抛出指定的异常类型，才会触发事务回滚 其中，rollbackFor支持指定单个或者多个异常类型，只要抛出指定类型的异常...，则该取值等价于REQUIRED 事务的传播行为，将会影响到事务控制的结果，比如最终是在同一事务中，一旦遇到异常，所有操作都会被回滚掉，而如果是在多个事务中，则某一个事务的回滚，不影响已提交的其余事务的回滚...// catch了可能的异常，导致DB操作失败的时候事务不会触发回滚 @Transactional public void insertUser() { try { UserEntity...，这样不会触发事务回滚机制 } } 在业务处理逻辑中，如果确实需要知晓并捕获相关处理的异常进行一些额外的业务逻辑处理，如果要保证事务回滚机制生效，最后需要往外抛出 RuntimeException...如下： // catch了指定异常，对外抛出对应类型的异常,可触发事务回滚 @Transactional(rollbackFor = DemoException.class) public void insertUser
例：一个方法报异常，另一个方法不会回滚 try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (...，因为没有任何异常会从业务方法中抛出，全被捕获并“吞掉”，导致spring异常抛出触发事务回滚策略失效。...如果在catch代码块中采用页面硬编码的方式使用spring api对事务做显式的回滚，这样写也是可以的。...Error是一种unchecked Exception，编译器不会检查Error是否被处理，在程序中不用捕获Error类型的异常。一般情况下，在程序中也不应该抛出Error类型的异常。...RuntimeException 是一种Unchecked Exception，即表示编译器不会检查程序是否对RuntimeException作了处理，在程序中不必捕获RuntimException类型的异常
事务的坑：Spring实现机制引起的 ---- 1、抛出受检异常Exception无法回滚 默认情况下，只有非受检异常RuntimeException、Error发生时，事务才会回滚。...受检异常Exception发生时不会回滚。...#completeTransactionAfterThrowing 默认情况下，非受检异常会回滚： 我们可以设置回滚Exception异常类型，来解决受检异常不回滚的问题： @Transactional...3、方法内try catch异常，不再抛给事务框架，不会回滚事务 自己吞掉了异常，Spring框架不会探测到异常。...4、事务多个业务有异步执行，异常不抛出，事务不会回滚 事务的实现涉及到java的ThreadLocal特性，如果异步执行，事务信息丢失或异常丢失，导致事务执行或回滚。
这样会导致两个方法不在一个线程中。获取的数据库连接也就不一致，从而是两个不同的事务。如果doOtherThing()方法中抛出了异常，add()方法是不可能回滚的。...，那么Spring事务是不会回滚的，因为开发者自己捕获了异常，同时没有手动抛出，欢聚还说就是自己把异常吞掉了。...3.手动抛出了别的异常 即使开发者在编写过程中，没有手动抛出异常；但是如果出现的异常不正确，Spring事务也不会回滚。...，又手动抛出了异常：Exception，事务同样不会回滚。...因为Spring事务，默认情况下只会回滚RunTimeException，和Error(错误)，对于普通的Exception(非运行时异常)，它是不会回滚的。
因此当 methodB 发生异常回滚时，methodA 中的内容就不会被回滚。用如下的代码就可以验证我们所说的。...但父方法需要注意子方法抛出的异常，避免因子方法抛出异常，而导致父方法回滚。 为了验证 REQUIRES_NEW 事务传播类型的特点，我们来做几个测试。...这正符合我们刚刚所说的：父子事务是独立的，并不会相互影响。 这其实就是我们上面所说的：父方法需要注意子方法抛出的异常，避免因子方法抛出异常，而导致父方法回滚。...此时父子方法的事务时独立的，它们都不会相互影响。但父方法需要注意子方法抛出的异常，避免因子方法抛出异常，而导致父方法回滚。 NESTED 当前方法存在事务时，子方法加入在嵌套事务执行。...彩蛋 Spring 事务执行过程中，如果抛出非 RuntimeException 和非 Error 错误的其他异常，那么是不会回滚的哦。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
