事务的七种传播行为(以代码为例,做个笔记)
PROPAGATION_REQUIRED:支持当前事务，如果不存在，则创建一个新事务。类似于同名的EJB事务属性。这是事务注释的默认设置。
PROPAGATION_SUPPORTS:支持当前事务，如果不存在则以非事务方式执行。同名EJB事务属性。
注意：对于具有事务同步的事务管理器，PROPAGATION_SUPPORTS与没有事务略有不同，因为它定义了同步将应用的事务范围。因此，对于整个指定的范围,将共享相同的资源（JDBC连接，Hibernate会话等)。 请注意，这取决于事务管理器的实际同步配置。
PROPAGATION_MANDATORY:支持当前事务，如果不存在则抛出异常。同名EJB事务属性。
PROPAGATION_REQUIRES_NEW:创建一个新事务，并挂起当前事务（如果存在）。同名EJB事务属性。注意：实际的事务暂停将无法在所有事务管理器中运行。 这特别适用于org.springframework.transaction.jta.JtaTransactionManager，它需要javax.transaction.TransactionManager使其可用（在标准Java EE中是特定于服务器的）。
PROPAGATION_NOT_SUPPORTED:执行非事务性操作，暂停当前事务（如果存在）。同名EJB事务属性。
注意：实际的事务暂停将无法在所有事务管理器中运行.这特别适用于org.springframework.transaction.jta.JtaTransactionManager，它需要javax.transaction.TransactionManager使其可用（在标准Java EE中是特定于服务器的）。
PROPAGATION_NEVER:执行非事务性操作，如果事务存在，则抛出异常。类似于同名的EJB事务属性。
PROPAGATION_NESTED:如果当前事务存在，则在嵌套事务中执行，其行为类似于PROPAGATION_REQUIRED 。 EJB中没有类似的功能。
注意：实际创建嵌套事务仅适用于特定事务管理器。 开箱即用，这仅适用于处理JDBC 3.0驱动程序时的JDBCDataSourceTransactionManager。一些JTA提供程序也可能支持嵌套事务。
下面是我自己的一些代码例子:
1.PROPAGATION_REQUIRED
未加事务,两条数据正常插入.
加上事务
运行报错,identifier of an instance of com.example.demo.entity.BankAccount was altered from 7 to 8,很简单,因为jpa中Persistent状态下的实体不允许修改id,表明这看似是两个事务,实际上合并成一个事务了,看数据库,未插入数据,表明被回滚了,是bankaccountservice2抛出的异常,两个插入都回滚了,真的变成一个事务了;
数据回滚了,再一次证明了,PROPAGATION_REQUIRED是事务合并成一个事务了
2.Propagation.SUPPORTS
若是bankaccountservice1有事务,那么和PROPAGATION_REQUIRED没区别,若是没有事务,两个service,一个都不会回滚
3.PROPAGATION_MANDATORY ,与Propagation.SUPPORTS的区别在于,一旦BankAccountService1没有事务,就会报错
4.Propagation.REQUIRES_NEW
两个都回滚了
只有一个数据回滚,表明bankaccountservice1的异常不会干扰到bankaccountservice2
还是两个都回滚了
还是只有一条数据,service2成功插入,而1回滚了,这就表明Propagation.REQUIRES_NEW,它的上一层,还是会捕捉到自己的产生异常,从而回滚,但是它的上一层产生的异常是不会对自己产生影响的
5.Propagation.NOT_SUPPORTED
service1没有插入数据,而service2插入数据,表明,无论service2有没有事务,但是异常仍然会被service1捕捉到以至回滚
6.PROPAGATION_NEVER
与Propagation.NOT_SUPPORTED区别就在于,如果service1有事务,service2会抛异常
7.PROPAGATION_NESTED
会一起回滚
也回滚了;
和required区别在于,一旦service2try catch了异常,service1不会回滚,但是required无论你在哪发生异常,都会回滚,这就是我为什么说required行为下,都是一个事务的原因
