Spring事务传播

Spring的事务传播是指使用Spring声明式事务，并且在事务方法相互调用过程中，事务的嵌套、传播和管理行为。如果是直接使用JDBC API，事务通过代码实现，则事务的行为自行控制和管理，无所谓传播。

Spring的事务传播行为类型有以下几种：

事务传播行为类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类 似的操作。

这里需要解释一下的是PROPAGATION_NESTED方式：

（上图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应该可以在之上做相应的支持。这点有待进一步研究！

如果想理解上面PROPAGATION_NESTED的介绍，如果不掌握JDBC的savepoint机制，是不深刻的。关于Savepoint的介绍可以查看这篇文章：http://blog.csdn.net/abc86319253/article/details/51612490。

上文是整理所得，无意掠夺成果。参考自：

http://sharajava.iteye.com/blog/78270