❶ .spring的事务有几种方式谈谈spring事务的隔离级别和传播行为
1、 Propagation
key属性确定代理应该给哪个方法增加事务行为。这样的属性最重要的部份是传播行为。有以下选项可供使用：
PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。
2、 Isolation Level(事务隔离等级):
1、Serializable：最严格的级别，事务串行执行，资源消耗最大；
2、REPEATABLE READ：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
3、READ COMMITTED:大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
4、Read Uncommitted：保证了读取过程中不会读取到非法数据。
隔离级别在于处理多事务的并发问题。我们知道并行可以提高数据库的吞吐量和效率，但是并不是所有的并发事务都可以并发运行，这需要查看数据库教材的可串行化条件判断了。
❷ 事务的几种传播特性及隔离级别
如果没有事务则开启 2. PROPAGATION_SUPPORTS: 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行 3. PROPAGATION_MANDATORY: 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。 4. PROPAGATION_REQUIRES_NEW: 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。 5. PROPAGATION_NOT_SUPPORTED: 总是非事务地执行，并挂起任何存在的事务。 6. PROPAGATION_NEVER: 总是非事务地执行，如果存在一个活动事务，则抛出异常 7. PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行 2、Spring事务的隔离级别 1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别. 另外四个与JDBC的隔离级别相对应 2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。 这种隔离级别会产生脏读，不可重复读和幻像读。 3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据 4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。 它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。 5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。 除了防止脏读，不可重复读外，还避免了幻像读。
❸ spring的事务传播行为，究竟意义何在
其实通常下，spring事务的传播行为和隔离级[transaction behaviorand isolatedlevel]都是互相配合，共同使用才能将spring事务运用到极致，事务的传播行为就是一个个的事务策略而已，具体运用哪一个，根据自己的需求和程序性能平衡去抉择，意义何在？
意义是大大的，由于不能保证系统绝对不出错，所以当出错的时候，应该讲之前所处理的事情全部回退到事件发生之前，包括对数据库这些修改等等，这是最为简单的场景，当然还有事务之间的交互，比如A事务失败了，会不会影响B事务，A事务捕获B事务的异常，这时候应该怎么办，要不要回滚，还有一些其他情况，这些都需要spring事务传播行为的支持。
❹ SpringBoot 数据库事务7种传播行为
如果当前方法的执行上下文中已经打开了事务，那么就使用当前这个事务。
如果当前没有事务，就创建一个新的。
如果多个方法都声明了 REQUIRED ，并且他们嵌套调用，那么他们会共享同一个物理事务。就是 inner 产生了回滚，那么 outer 会跟着回滚。
Outer bean
Inner bean
inner 声明了 REQUIRED ，并抛出了异常，outer 事务将同样回滚，因为他们是同一个事务。
声明 REQUIRES_NEW 的话就会创建一个新的物理事务，内层事务的提交回滚都是独立于外层事务的。外层事务不受内层事务结果的影响，他们运行于独立的物理事务。
Outer bean
Inner bean
inner 的回滚不影响 outer 的事务。当 inner 事务开启后，outer 事务会暂停，当 inner 事务结束后，outer 事务恢复。
NESTED 使嵌套的事务使用相同的物理事务，但是对嵌套调用设置了保存点，所以 inner 事务可以独立于 outer 事务回滚。
支持事务，如果当前存在事务，就沿用当前事务，如果不存在，则继续采用无事务的方式运行。
必须使用事务。如果当前没有事务，则会抛出异常，如果存在当前事务，就沿用当前事务。
不支持事务，当前存在事务时，将挂起事务，运行方法。
不支持事务，如果当前方法存在事务，则抛出异常，否则继续使用无事务机制运行。
参考：
https://www.byteslounge.com/tutorials/spring-transaction-propagation-tutorial
❺ 程序员新人周一优化一行代码，周三被劝退
这周一，公司新来了一个同事，面试的时候表现得非常不错，各种问题对答如流，老板和我都倍感欣慰。
这么优秀的人，绝不能让他浪费一分一秒，于是很快，我就发他了需求文档、源码，让他先在本地熟悉一下业务和开发流程。
结果没想到，周三大家一块 review 代码的时候就发现了问题，新来的同事直接把原来 @Transactional 优化成了这个鬼样子：
就因为这一行代码，老板（当年也是一线互联网大厂的好手）当场就发飙了，马上就要劝退这位新同事，我就赶紧打圆场，毕竟自己面试的人，不看僧面看佛面，是吧？于是老板答应我说再试用一个月看看。
会议结束后，我就赶紧让新同事复习了一遍事务，以下是他自己做的总结，还是非常详细的，分享出来给大家一点点参考和启发。相信大家看完后就明白为什么不能这样优化 @Transactional 注解了，纯属画蛇添足和乱用。
事务在逻辑上是一组操作， 要么执行，要不都不执行 。主要是针对数据库而言的，比如说 Mysql。
只要记住这一点，理解事务就很容易了。在 Java 中，我们通常要在业务里面处理多个事件，比如说编程喵有一个保存文章的方法，它除了要保存文章本身之外，还要保存文章对应的标签，标签和文章不在同一个表里，但会通过在文章表里（posts）保存标签主键（tag_id）来关联标签表（tags）：
那么此时就需要开启事务，保证文章表和标签表中的数据保持同步，要么都执行，要么都不执行。
否则就有可能造成，文章保存成功了，但标签保存失败了，或者文章保存失败了，标签保存成功了——这些场景都不符合我们的预期。
为了保证事务是正确可靠的，在数据库进行写入或者更新操作时，就必须得表现出 ACID 的 4 个重要特性：
其中，事务隔离又分为 4 种不同的级别，包括：
需要格外注意的是： 事务能否生效，取决于数据库引擎是否支持事务，MySQL 的 InnoDB 引擎是支持事务的，但 MyISAM 就不支持 。
1）编程式事务
编程式事务是指将事务管理代码嵌入嵌入到业务代码中，来控制事务的提交和回滚。
你比如说，使用 TransactionTemplate 来管理事务：
再比如说，使用 TransactionManager 来管理事务：
就编程式事务管理而言，Spring 更推荐使用 TransactionTemplate。
在编程式事务中，必须在每个业务操作中包含额外的事务管理代码，就导致代码看起来非常的臃肿，但对理解 Spring 的事务管理模型非常有帮助。
当然了，要想实现事务管理和业务代码的抽离，就必须得用到 Spring 当中最关键最核心的技术之一，AOP，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。
Spring 将事务管理的核心抽象为一个事务管理器（TransactionManager），它的源码只有一个简单的接口定义，属于一个标记接口：
通过 PlatformTransactionManager 这个接口，Spring 为各个平台如 JDBC(DataSourceTransactionManager)、Hibernate(HibernateTransactionManager)、JPA(JpaTransactionManager)等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。
参数 TransactionDefinition 和 @Transactional 注解是对应的，比如说 @Transactional 注解中定义的事务传播行为、隔离级别、事务超时时间、事务是否只读等属性，在 TransactionDefinition 都可以找得到。
返回类型 TransactionStatus 主要用来存储当前事务的一些状态和数据，比如说事务资源（connection）、回滚状态等。
TransactionDefinition.java：
Transactional.java
说到这，我们来详细地说明一下 Spring 事务的传播行为、事务的隔离级别、事务的超时时间、事务的只读属性，以及事务的回滚规则。
当事务方法被另外一个事务方法调用时，必须指定事务应该如何传播 ，例如，方法可能继续在当前事务中执行，也可以开启一个新的事务，在自己的事务中执行。
TransactionDefinition 一共定义了 7 种事务传播行为：
01、 PROPAGATION_REQUIRED
这也是 @Transactional 默认的事务传播行为，指的是如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。更确切地意思是：
这个传播行为也最好理解，aMethod 调用了 bMethod，只要其中一个方法回滚，整个事务均回滚。
02、 PROPAGATION_REQUIRES_NEW
创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法都会开启自己的事务，且开启的事务与外部的事务相互独立，互不干扰。
如果 aMethod()发生异常回滚，bMethod()不会跟着回滚，因为 bMethod()开启了独立的事务。但是，如果 bMethod()抛出了未被捕获的异常并且这个异常满足事务回滚规则的话,aMethod()同样也会回滚。
03、 PROPAGATION_NESTED
如果当前存在事务，就在当前事务内执行；否则，就执行与 PROPAGATION_REQUIRED 类似的操作。
04、 PROPAGATION_MANDATORY
如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
05、 PROPAGATION_SUPPORTS
如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
06、 PROPAGATION_NOT_SUPPORTED
以非事务方式运行，如果当前存在事务，则把当前事务挂起。
07、 PROPAGATION_NEVER
以非事务方式运行，如果当前存在事务，则抛出异常。
3、4、5、6、7 这 5 种事务传播方式不常用，了解即可。
前面我们已经了解了数据库的事务隔离级别，再来理解 Spring 的事务隔离级别就容易多了。
TransactionDefinition 中一共定义了 5 种事务隔离级别：
通常情况下，我们采用默认的隔离级别 ISOLATION_DEFAULT 就可以了，也就是交给数据库来决定，可以通过 SELECT @@transaction_isolation; 命令来查看 MySql 的默认隔离级别，结果为 REPEATABLE-READ，也就是可重复读。
事务超时，也就是指一个事务所允许执行的最长时间，如果在超时时间内还没有完成的话，就自动回滚。
假如事务的执行时间格外的长，由于事务涉及到对数据库的锁定，就会导致长时间运行的事务占用数据库资源。
如果一个事务只是对数据库执行读操作，那么该数据库就可以利用事务的只读属性，采取优化措施，适用于多条数据库查询操作中。
这是因为 MySql（innodb）默认对每一个连接都启用了 autocommit 模式，在该模式下，每一个发送到 MySql 服务器的 SQL 语句都会在一个单独的事务中进行处理，执行结束后会自动提交事务。
那如果我们给方法加上了 @Transactional 注解，那这个方法中所有的 SQL 都会放在一个事务里。否则，每条 SQL 都会单独开启一个事务，中间被其他事务修改了数据，都会实时读取到。
有些情况下，当一次执行多条查询语句时，需要保证数据一致性时，就需要启用事务支持。否则上一条 SQL 查询后，被其他用户改变了数据，那么下一个 SQL 查询可能就会出现不一致的状态。
默认情况下，事务只在出现运行时异常（Runtime Exception）时回滚，以及 Error，出现检查异常（checked exception，需要主动捕获处理或者向上抛出）时不回滚。
如果你想要回滚特定的异常类型的话，可以这样设置：
以前，我们需要通过 XML 配置 Spring 来托管事务，有了 Spring Boot 之后，一切就变得更加简单了，只需要在业务层添加事务注解（ @Transactional ）就可以快速开启事务。
也就是说，我们只需要把焦点放在 @Transactional 注解上就可以了。
虽然 @Transactional 注解源码中定义了很多属性，但大多数时候，我都是采用默认配置，当然了，如果需要自定义的话，前面也都说明过了。
1）要在 public 方法上使用，在类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。
2）避免同一个类中调用 @Transactional 注解的方法，这样会导致事务失效。
在测试之前，我们先把 Spring Boot 默认的日志级别 info 调整为 debug，在 application.yml 文件中 修改：
然后，来看修改之前查到的数据：
开搞。在控制器中添加一个 update 接口，准备修改数据，打算把沉默王二的狗腿子修改为沉默王二的狗腿：
在 Service 中为方法加上 @Transactional 注解并抛出运行时异常：
按照我们的预期，当执行 save 保存数据后，因为出现了异常，所以事务要回滚。所以数据不会被修改。
在浏览器中输入 http://localhost:8080/user/update 进行测试，注意查看日志，可以确认事务起效了。
当我们把事务去掉，同样抛出异常：
再次执行，发现虽然程序报错了，但数据却被更新了。
这也间接地证明，我们的 @Transactional 事务起效了。
看到这，是不是就明白为什么新同事的优化纯属画蛇添足/卵用了吧？
❻ Spring支持的常用数据库事务传播属性和隔离级别
那么不知道你 对于Spring支持的常用数据库事务传播属性和隔离级别 了解得怎么样呢？要不要一起复习复习了:grin:
很喜欢一句话：“八小时内谋生活，八小时外谋发展”
共勉 :woman: :computer:
描述 ：进来先看看风景啦，要相信会有光的哦
对于数据库事务ACID（原子性、一致性、隔离性、持久性）性质我想大家都是知道的，这里就不写了:grin:
我们都知道用事务是为了保证数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
但是如果一个方法嵌套关联着其他方法了，这该怎么算呢？当前方法及关联方法都有事务呢，或者只是其中某几个有事务，该用谁的呢？
事务的传播行为：一个方法运行在一个开启了事务的方法上时，当前方法是使用原来的事务还是开启一个新的事务。
通过 @Transaction 注解中 propagation 来设置事务传播行为。其中
事务传播行为总共有以下七种：
下面写了一个小demo来让理解更加快捷一些哈。
注意：account表中 balance 字段是设置为无符号的（即不能为负数）。
项目就是普通Spring项目
模拟的是买书的一个过程，账户余额不足，但是一次买多本的情况，一起付款。
在其中再测试事务传播行为的不同，来看数据的变化。
初始代码：
mapper层代码
测试一：默认事务传播行为
我们在 void checkout(int userId, List isbns) 和 void purchase(int userId, int isbn) 上都加了 @Transactional
目前账户为 100元，两本书的价格分别为 60和50 ，因为我们的付款过程是 使用循环 购买的，你说我们会买到一本还是一本都买不到呢？
答案当然是一本都买不到，因为 @Transactional 注解 ，默认事务的传播属性是：REQUIRED，即业务方法需要在一个事务中运行。如果方法运行时，已经处在一个事务中，那么加入到该事务，否则为自己创建一个新的事务。所以实际上 void purchase(int userId, int isbn) 其实和调用它的方法用的同一个事务。简单画个图：
测试二：测试 -->REQUIRES_NEW属性
其他代码未改变，仅在 purchase 上的注解上加了点东西 @Transactional(propagation = Propagation.REQUIRES_NEW) .
REQUIRES_NEW: 不管是否存在事务，业务方法总会为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务会被挂起，新的事务会被创建，直到方法执行结束，新事务才算结束，原先的事务才会恢复执行。
你说说答案和上面是一样的么？:grinning:
答案是不一样的， 测试一 我们实际上用的就是checkout上的事务，并没有用到 purchase 的事务，从图上也能看出来。
测试二它的事务传播属性 用 图来讲是这样的啦：
所以是可以买到一本书的。
还有很多，意思都解释过了，没有一一测完了。
假设现在有A和B 两个事务 并发执行。
1）脏读：一个事务读取到另一事务未提交的更新新据
2）不可重复读: 同一事务中，多次读取同一数据返回的结果有所不同(针对的update操作)
3）幻读:一个事务读取到另一事务已提交的insert数据(针对的insert操作)
数据库事务的隔离性: 数据库系统必须具有隔离并发运行各个事务的能力, 使它们不会相互影响, 避免各种并发问题.
一个事务与其他事务隔离的程度称为隔离级别. 数据库规定了多种事务隔离级别, 不同隔离级别对应不同的干扰程度, 隔离级别越高, 数据一致性就越好, 但并发性越弱
在代码中，我们可以通过
数据库提供了4种隔离级别：
注 : 模拟并发情况。
1） 测试一下 mysql 的默认隔离级别：
测试代码特别简单，但因为我是手动模拟，得打断点、debug启动，
当执行完第一个 double bookPrice = bookShopMapper.getBookPriceByIsbn(isbn) 语句时，应该去mysql 修改一下书的价格，这样看一下结果。
这个时候再接着执行。看输出什么。
最后的结果仍然是50、50。因为mysql的默认事务隔级别是可重复读，意思在这同一个事务中，可以重复读。
注 ：因为这是直接修改数据库，其操作行为并不可取，此处只是为了模拟。其结果有时也非一定准确。
❼ 什么是事务的传播特性
就是多个事务方法相互调用时，事务如何在这些方法间传播。
❽ spring mvc 怎么样设置mysql事物隔离级别
先来总体说一下我对这个问题的理解，用一句话概括：
数据库是可以控制事务的传播和隔离级别的，Spring在之上又进一步进行了封装，可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制。
注意：Spring不仅可以控制事务传播行为（PROPAGATION_REQUIRED等），还可以控制事务隔离级别（ISOLATION_READ_UNCOMMITTED等）。
（以下是个人理解，如果有瑕疵请及时指正）
下面我具体解释一下：
为了大家能够更好的理解，先来明确几个知识点：
事务的传播行为：简单来说就是事务是手动提交还是自动提交，事务什么时候开始，什么时候提交。
事务的隔离级别：简单来说，就四个，提交读，提交读，重复读，序列化读。
首先我来描述一下，数据库（mysql）层面上对于事务传播行为和隔离级别的配置和实验方法：
数据库层面（采用命令行）：其实mySql命令行很简单，希望实验操作一下：
//连接数据库，我这里是本地，后面是用户名密码，不要打分号，如果指令不行，配置下环境变量，网上有很多。
1. cmd中执行：mysql -hlocalhost -uroot -pmysql
//查看本地数据库事务传播行为是手动提交（0），还是自动提交（1）。
2.select @@autocommit;
//如果是0，希望设置为手动提交,这里其实是设置本对话的autocommit，因为如果你再开一个cmd，发现还是没改回来，如果想修改全局的，网上有global方法。
3.set @@autocommit=0;
//然后查询本地数据库中的一条记录,我本地数据库为test1;
4.use test1;
5.select * from task where taskid=1;
//同时新开一个窗口cmd，连接数据库，并且修改这条记录，update语句我就不写了，或者直接修改数据库本条记录。
//再次执行select * from task where taskid=1;发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读，因为mysql默认的隔离级别是重复读。
//修改数据库隔离级别
6.set global transaction isolation level read committed;
//查看一下，可能需要重新连接一下
7.select @@tx_isolation;
//这时在执行一下4,5操作，发现值变了，ok。因为已经改变了数据库隔离级别，发生了重复读出不同数据的现象。
（以上操作希望有不明白的上网自学一下，很有用，先把数据库隔离级别弄明白了）
然后再来讲一下，Spring对事务传播行为和隔离级别的二次封装。
因为不同项目可能在一个mysql的不同数据库上，所以可以在项目中配置数据库的传播行为和隔离级别：
关于spring的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等），我《数据库隔离级别（mysql+Spring）与性能分析 》文章中有讲，网上也有很多相关资料，我就不说了。
关于spring的事务隔离级别与数据库的一样，也是那四个，多了一个default，我也不仔细讲了。
下面主要讲一下spring的配置方法：
<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED</prop>
</props>
就以find为例，可以配置这么配置，前面是控制传播行为，后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读，但是还是以这里为准，你会发现在同一个事务中两次查询的结果是不一样的。
最后扫除一个盲区，readonly这个属性，是放在传播行为中的，一般书都这么归类，我也尝试了一下，readonly并不能影响数据库隔离级别，只是配置之后，不允许在事务中对数据库进行修改操作，仅此而已。
❾ spring对循环操作数据库时的事务处理如何配置
事务传播级别设置为requiredNew
循环调用方法，每次调用方法都开启新的事务保存数据
❿ 什么是事务的传播特性
在我们用SSH开发项目的时候，我们一般都是将事务设置在Service层
那么当我们调用Service层的一个方法的时候它能够保证我们的这个方法中执行的所有的对数据库的更新操作保持在一个事务中，在事务层里面调用的这些方法要么全部成功，要么全部失败。那么事务的传播特性也是
从这里说起
的。
如果你在
你的Service层的这个方法中，除了调用了Dao层的方法之外，还调用了本类的其他的Service方法，那么在调用其他的Service方法的时候，这个事务是怎么规定的呢，我必须保证我在我方法里掉用的这个方法与我本身的方法处在同一个事务中，否则如果保证事物的一致性。事务的传播特性就是解决这个问题的，“事务是会传播的”在Spring中有针对传播特性的多种配置我们大多数情况下只用其中的一种:PROPGATION_REQUIRED：这个
配置项
的意思是说当我调用service层的方法的时候开启一个事务(具体调用那一层的方法开始创建事务，要看你的aop的配置),那么在调用这个service层里面的其他的方法的时候,如果当前方法产生了事务就用当前方法产生的事务，否则就创建一个新的事务。这个工作使由Spring来帮助我们完成的。
以前没有Spring帮助我们完成事务的时候我们必须自己手动的控制事务，例如当我们项目中仅仅使用
hibernate
，而没有集成进spring的时候，我们在一个service层中调用其他的
业务逻辑
方法，为了保证事物必须也要把当前的hibernate
session传递到下一个方法中，或者采用
ThreadLocal
的方法，将session传递给下一个方法，其实都是一个目的。现在这个工作由spring来帮助我们完成，就可以让我们更加的专注于我们的业务逻辑。而不用去关心事务的问题。
默认情况下当发生Runtime
Exception
的情况下，事务才会
回滚
，所以要注意一下
如果你在程序发生错误的情况下，有自己的
异常处理
机制定义自己的Exception，必须从RuntimeException类继承
这样事务才会回滚！