首先 在上一文java Spring5 搭建操作数据库事务环境中 我们搭建了一个事务的业务场景 然后 打开项目
我们继续

先看到数据库表 看好两个人的余额

然后 来到senvice层下的transfAccoSenvice
将里面的 transferAccounts方法 更改如下

//转账方法
public void transferAccounts(int sponsorId, int recipientId, double money){Boolean paym = pay(money,sponsorId);if(paym){int i = 10/0;income(money,recipientId);System.out.println("交易完成");}
}

拿 0 作为 /除数 自然是要异常的 我们就是要造一个 第一段sql执行成功 然后异常导致第二段sql执行不了的情况
我们再次运行测试类 运行结果如下

可以看到 很明显 第一个sql已经执行完了 但后面就因为 0 为除数 抛出了异常

我们到数据库中 刷新表 然后重新打开

我们可以明显看到 张三的钱因为第二段sql没有执行 并没有加到 但李四的余额却是因为第一段sql的执行 实打实的被扣了

这里 是我手工模仿的异常 但实际情况中 也会有不可抗力的元素导致异常 这种事 出个一两次 这个程序也就不用做了

这时我们就需要事务 按事务的逻辑就是 要么 李四的钱扣了 那么张三的钱 他就应该加上 要么 张三的钱没加到 那么 李四的钱 他就也不应该扣

然后我们要用事务 就需要考虑在三层架构的哪一层？
我想很多人会想 dao 其实我一开始也这样认为 甚至 到现在为止 我还是依旧认为放dao层合理
但没办法 我们可以看senvice中的代码

因为 整个的业务聚焦点在 senvice的业务逻辑层中 在这里 才能把握整个逻辑点

所以 我一直认为 当性能和需求冲突时 牺牲性能 我最讨厌那种一天到晚 规范规范的人 我说实话 我打心底看不起那些 以牺牲功能质量 甚至 增加使用者操作步骤来保证性能的人 我还是觉得 用户的方便 才是第一前提

所以 事务一般会添加在 三层架构中的 senvice 业务逻辑层中

在Spring中 事务有两种方式

1 编程式事务管理
2 声明式事务管理

而在开发过程中 一般都会选择声明式

所谓编程式 就是 到可能异常的地方 先捕获异常 然后 开启事务 执行成功的话 提交事务 如果被异常捕获 则回滚事务 这个的话 每个地方用一下 代码就会显得很笨重

而声明式事务 也有两种 实现方式 在我们学习Spring5 过程中 也是老朋友了 注解/xml 方式

而声明式底层管理中使用了我们前段时间认识的朋友 AOP 我喜欢大家不是渣男 用完之后还是要记得人家的啊
而在面试时 别人问你在Spring开发中 什么地方用到了aop 你可以说 声明式事务管理 用到了面向切面的原理

Spring事务操作 需要PlatformTransactionManager接口中的API PlatformTransactionManager接口 为不同操作数据库框架准备了不同的实现类