spring 七个事务传播行为

在 TransactionDefinition 接口中定义了七个事务传播行为：

PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。 使用 spring 声明式事务， spring 使用 AOP 来支持声明式事务，会根据事务属性，自动在方法调用之前决定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。 单独调用 methodB 方法 相当于 Spring 保证在 methodB 方法中所有的调用都获得到一个相同的连接。在调用 methodB 时，没有一个存在的事务，所以获得一个新的连接，开启了一个新的事务。 单独调用 MethodA 时，在 MethodA 内又会调用 MethodB. 执行效果相当于 调用 MethodA 时，环境中没有事务，所以开启一个新的事务 . 当在 MethodA 中调用MethodB 时，环境中已经有了一个事务，所以 methodB 就加入当前事务。

PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器， PROPAGATION_SUPPORTS 与不使用事务有少许不同。 单纯的调用 methodB 时， methodB 方法是非事务的执行的。 当调用 methdA时 ,methodB 则加入了 methodA 的事务中 , 事务地执行。

PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。 当单独调用 methodB 时，因为当前没有一个活动的事务，则会抛出异常 throw new IllegalTransactionStateException("Transaction propagation ''mandatory'' but no existing transaction found"); 当调用 methodA 时， methodB 则加入到 methodA 的事务中，事务地执行。

PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。 当单独调用 methodB 时，相当于把 methodb 声明为 REQUIRED 。开启一个新的事务，事务地执行。 当调用 methodA 时 情况有些大不一样 . 相当于下面的效果。 在这里，我把 ts1 称为外层事务， ts2 称为内层事务。从上面的代码可以看出， ts2 与ts1 是两个独立的事务，互不相干。 Ts2 是否成功并不依赖于 ts1 。如果 methodA 方法在调用 methodB 方法后的 doSomeThingB 方法失败了，而 methodB 方法所做的结果依然被提交。而除了 methodB 之外的其它代码导致的结果却被回滚了。 使用PROPAGATION_REQUIRES_NEW, 需要使用 JtaTransactionManager 作为事务管理器。

PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。 当单独调用 methodB 时，不启用任何事务机制，非事务地执行。 当调用 methodA 时，相当于下面的效果 使用 PROPAGATION_NOT_SUPPORTED, 也需要使用 JtaTransactionManager 作为事务管理器。

PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常 单独调用methodB ，则非事务的执行。 调用 methodA 则会抛出异常

PROPAGATION_NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中 . 如果没有活动事务 , 则按 TransactionDefinition.PROPAGATION_REQUIRED 属性执行 这是一个嵌套事务 , 使用 JDBC 3.0 驱动时 , 仅仅支持 DataSourceTransactionManager 作为事务管理器。需要 JDBC 驱动的 java.sql.Savepoint 类。有一些 JTA 的事务管理器实现可能也提供了同样的功能。 使用 PROPAGATION_NESTED ，还需要把 PlatformTransactionManager 的nestedTransactionAllowed 属性设为 true; 而 nestedTransactionAllowed 属性值默认为false; 如果单独调用 methodB 方法，则按 REQUIRED 属性执行。 如果调用 methodA 方法，相当于下面的效果 当 methodB 方法调用之前，调用 setSavepoint 方法，保存当前的状态到 savepoint 。如果 methodB 方法调用失败，则恢复到之前保存的状态。但是需要注意的是，这时的事务并没有进行提交，如果后续的代码 (doSomeThingB() 方法 ) 调用失败，则回滚包括 methodB 方法的所有操作。 嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

 

 

 

简单理解Spring中的PROPAGATION_NESTED

 

结合http://www.iteye.com/topic/35907 ，简单总结一下自己的理解：

（上图AD和BC代表两个事务，1，2，3代表事务执行的三个阶段。图简陋了点，有点像“金箍棒”）

使用嵌套事务的场景有两点需求：

 

1. 需要事务BC与事务AD一起commit，即：作为事务AD的子事务，事务BC只有在事务AD成功commit时（阶段3成功）才commit。这个需求简单称之为“联合成功”。这一点PROPAGATION_REQUIRED可以做到。
2. 需要事务BC的rollback不（无条件的）影响事务AD的commit。这个需求简单称之为“隔离失败”。这一点PROPAGATION_REQUIRES_NEW可以做到。

使用PROPAGATION_REQUIRED满足需求1，但子事务BC的rollback会无条件地使父事务AD也rollback，不能满足需求2。

使用PROPAGATION_REQUIRES_NEW满足需求2，但子事务（这时不应该称之为子事务）BC是完全新的事务上下文，父事务（这时也不应该称之为父事务）AD的成功与否完全不影响BC的提交，不能满足需求1。

同时满足上述两条需求就要用到PROPAGATION_NESTED了。PROPAGATION_NESTED在事务AD执行到B点时，设置了savePoint（关键）。

当BC事务成功commit时，PROPAGATION_NESTED的行为与PROPAGATION_REQUIRED一样。只有当 事务AD在D点成功commit时，事务BC才真正commit，如果阶段3执行异常，导致事务AD rollback，事务BC也将一起rollback ，从而满足了“联合成功”。

 当阶段2执行异常，导致BC事务rollback时，因为设置了savePoint，AD事务可以选择与BC一起rollback或继续阶段3的执行并保留阶段1的执行结果，从而满足了“隔离失败”。

当然，要明确一点，事务传播策略的定义是在声明或事务管理范围内的（首先是在EJB CMT规范中定义，Spring事务框架补充了PROPAGATION_NESTED ），编程式的事务管理不存在事务传播的问题。

另外，SavePoint在JDBC3.0中，所以应用嵌套事务必须保证JDK1.4+和驱动对JDBC3.0的支持。

 

强调，补充一点：PROPAGATION_NESTED只是Spring针对JDBC3.0以上版本SavePoint机制的一个事务传播机制的扩 展，J2EE体系中是没有的，所以如果应用中使用JTA作为底层的事务管理机制的话，使用Spring也是不可能支持 PROPAGATION_NESTED。不过JPA的体系中好像是有SavePoint的机制（还没有细研究过），Spring应该可以在之上做相应的支 持。这点有待进一步研究！