Spring声明式事务配置管理方法

http://www.cnblogs.com/rushoooooo/archive/2011/08/28/2155960.html
附一、Spring事务类型详解
<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop><prop key="store*">PROPAGATION_REQUIRED</prop>

估计有好多朋友还没有弄清楚里面的值的意思，仔细看完下面应该知道自己什么情况下面应该使用什么样的声明。^_^

Spring中常用事务类型：

PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。

PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。

PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。

PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。

PROPAGATION_NESTED--如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。



附二、对spring事务类型详解的一点补充（关于嵌套事务）
· PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

· PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。

· PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。

· PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。

· PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

· PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。


       可能大家对PROPAGATION_NESTED还不怎么了解，觉得有必要再补充一下^_^！
PROPAGATION_NESTED: 嵌套事务类型，是相对上面提到的六种情况（上面的六种应该称为平面事务类型），打个比方我现在有一个事务主要有一下几部分：
      1，从A用户帐户里面减去100元钱
      2，往B用户帐户里面添加100元钱
       这样看和以前不同的事务可能没有什么区别，那我现在有点特殊的要求就是，A用户有3个帐户，B用户有2个帐户，现在我的要求就是只要再A用户的3个帐户里面任意一个减去100元，往B用户的两个帐户中任意一个里面增加100元就可以了！
       一旦你有这样的要求那嵌套事务类型就非常适合你！我们可以这样理解，
       一：将“从A用户帐户里面减去100元钱” 和 “往B用户帐户里面增加100元钱”我们暂时认为是一级事务操作
       二：将从A用户的3个帐户的任意一个帐户里面减钱看做是“从A用户帐户里面减去100元钱”这个一级事务的子事务（二级事务），同样把后面存钱的看成是另一个的二级事务。
      问题一：当二级事务被rollback一级事务会不会被rollback？
      答案是不会的，二级事务的rollback只针对自己。
      问题二：什么时候这个一级事务会commit，什么时候会被rollback呢？
      我们主要看二级里面出现的情况，当所有的二级事务被commit了并且一级事务没有失败的操作，那整个事务就算是一个成功的事务，这种情况整个事务会被commit。
当任意一个二级事务没有被commit那整个事务就是失败的，整个事务会被roolback。
还是拿上面的例子来说明吧！如果我在a的三个帐户里面减钱的操作都被二级事务给rollback了，也就是3个帐户里面都没有减钱成功，整个事务就失败了就会被rollback。如果A用户帐户三个帐户里面有一个可以扣钱而且B用户的两个帐户里面也有一个帐户可以增加钱，那整个事务就算成功的，会被 commit。
看了一下觉得上面的例子好像不是很深刻，看这个情况（A用户的3个帐户都是有信用额度的，也就是说可以超支，但是超支有金额限制）。不过原理是一样的，简单点也好说明一点，祝你好运！^_^



附三、Transaction后缀给声明式事务管理带来的好处
        良好的面向对象的程序，一般都使用接口和实现分离的模式。我在《事务管理最佳实践全面解析》一文中提出，用*Transaction和*Dao后缀这样的形式，区分方法的不同用途。

这样，可以提醒接口的实现者和方法的使用者注意到它们对于数据库连接和事务的依赖。

实际上，使用*Transaction后缀这样的命名方式，对于声明式事务管理也是很有用处的。如，Spring的事务管理中，我们一般使用方法名的匹配来应用声明式事务。

一、请看下面的Spring配置：

<bean id="txProxyTemplate" abstract="true" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="transactionManager"/>
<property name="transactionAttributes">
<props>
    <prop key="*">readOnly</prop>
    <prop key="add*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="save*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="modify*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="update*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="delete*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="remove*">PROPAGATION_REQUIRED,-Exception</prop>
    <prop key="query*">PROPAGATION_REQUIRED, readOnly,-Exception</prop>
    <prop key="load*">PROPAGATION_REQUIRED, -Exception</prop>
</props>
</property>
</bean>
这是来自于真实项目中的Spring声明式事务配置。我们对每一个业务层的实现类都应用了这样的事务配置。

我们对所有业务服务Service方法使用了只读事务。对以add,save,modify,update,delete,remove,load开头的方法都使用了事务。

但是，实际上，虽然我们开发的软件一个“信息管理系统”，是围绕数据库开发的。但是，在Service层，我们还是有很多不操作数据库的方法。

如，单纯根据业务逻辑进行计算的，适用缓存进行计算的，执行email发送，文件上传等等任务的方法，在这种配置下都不分青红皂白的应用了事务。

SpringAOP生成的代理对象代理了我们的服务实现类，所有的方法执行前后都被拦截，用来得到和关闭数据库连接，设置、提交和回滚事务。而不管这个方法是否用到了这个数据库。

如果遵照我提出的这个方法，使用*Transaction后缀来标识需要处理事务的方法，那么我们使用Spring声明式事务时，就可以非常精确、有效的应用事务了！

二、请看下面的Spring事务配置：

<!-- UninstallWcmsJbpmProcessDefinition -->
<bean id="uninstallWcmsJbpmProcessDefinition" parent="txProxyTemplate">
    <property name="target">
       <ref bean="uninstallWcmsJbpmProcessDefinitionTarget"/>
    </property>
<property name="transactionAttributes">
<props>
      <prop key="uninstall*Wcms*Transaction">PROPAGATION_REQUIRED,-Exception</prop>
</props>
</property>
</bean>
我们对这个类中以uninstall开头，中间包含Wcms，最后以Transaction结尾，这样的规则命名的方法，应用了事务。

三、部分源代码：

（一）2个应用了Spring声明式事务的方法：