1.认识事务本身：
为了说明“什么是事务”，我觉得先从事务所针对的目的说起，会比较容易切入。
对于一个软件系统来说，需要相应的数据资源(比如，数据库，文件系统等)来保存系统状态，在对系统状态所依托的数据资源进行访问的时候，为了保证系统始终处于一个“正确”的状态[1]， 我们就必须对这些访问操作进行一些必要的限定，以此来保证系统状态的完整性。
事务就是以可控的方式对数据资源进行访问的一组操作，为了保证事务执行前后数据资源所承载的系统状态始终处于“正确”状态，事务本身持有四个限定属性， 即原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)以及持久性(Durability)，也就是常说的事务的ACID属性:
- 事务的原子性(Atomicity)
-
原子性要求事务所包含的全部操作是一个不可分割的整体，这些操作要么全部提交成功，要么只要其中一个操作失败，就全部“成仁”(“一颗老鼠屎搅坏一锅汤”好像形容这种情况比较贴切哦)。 如果把整个事务的操作比做“钢七连”，那我们的口号就得从“不抛弃，不放弃”改成“要么不抛弃，要么就全部放弃”了。
- 事务的一致性(Consistency)
-
一致性要求事务所包含的操作不能违反数据资源的一致性检查，数据资源在事务执行之前处于一个数据的一致性状态，那么，事务执行之后也需要依然保持数 据间的一致性状态。 对于一个证券系统来说，如果顾客银行账户和证券账户资金总和为10万的话(银行账户初始8万，证券账户初始2万)，从银行账户的8万转账5万到证券账户的 事务操作结束之后， 银行账户会剩余3万，证券账户为7万，两个账户的总和依然是10万，如果事务操作结束后，整个数据状态不是这个样子，那么就说系统处于不一致状态，而使用 事务其中一个目的就是为了避免这种不一致性状态的产生。
- 事务的隔离性(Isolation)[2]
-
事务的隔离性主要规定了各个事务之间相互影响的程度。隔离性概念主要面向对数据资源的并发访问(Concurrency)，并兼顾影响事务的一致性。当两个事务或者更多事务同时访问同一数据资源的时候， 不同的隔离级别决定了各个事务对该数据资源访问的不同行为。
不出意外的话，我们可以为事务指定四种类型的隔离级别，隔离程度按照从弱到强分别为“Read Uncommitted”，“Read Committed”，“Repeatable Read”和“Serializable”:
对于数据库来说，通常都有一个默认的隔离级别，大多数情况下都是ReadCommitted，只有Hsqldb使用Read UnCommited作为默认隔离级别。 而且，并非所有的数据库都支持这四种隔离级别，比如Oracle只支持Read Committed和Serializable，如果你指定的隔离级别当前数据库不支持的话， 数据库会采用默认的隔离级别代替你指定的隔离级别。EJB，Spring，JDBC等数据访问方式都允许我们为事务指定以上提到的四种隔离级别，但最终事 务是否以指定的隔离级别执行，则由底层的数据资源来决定。-
Read Uncommitted. 最低的隔离级别，Read Uncommitted最直接的效果就是一个事务可以读取另一个事务并未提交的更新结果。
Read Uncommitted是以较低的隔离度来寻求较高的性能，其本身无法避免以下几个问题：
-
脏读(Dirty Read). 如果一个事务中对数据进行了更新，但事务还没有提交，另一个事务可以“看到”该事务没有提交的更新结果，这样造成的问题就是，如果第一个事务回滚，那么，第二个事务在此之前所“看到”的数据就是一笔脏数据。
-
不可重复读取(Non-Repeatable Read). 不可重复读取是指同一个事务在整个事务过程中对同一笔数据进行读取，每次读取结果都不同。如果事务1在事务2的更新操作之前读取一次数据，在事务2的更新 操作之后再读取同一笔数据一次，两次结果是不同的，所以，Read Uncommitted也无法避免不可重复读取的问题。
-
幻读(Phantom Read)[3]. 幻读是指同样一笔查询在整个事务过程中多次执行后，查询所得的结果集是不一样的。幻读针对的是多笔记录。在Read Uncommitted隔离级别下， 不管事务2的插入操作是否提交，事务1在插入操作之前和之后执行相同的查询，取得的结果集是不同的，所以，Read Uncommitted同样无法避免幻读的问题。
-
-
Read Committed. Read Committed通常是大部分数据库采用的默认隔离级别，它在Read Uncommitted隔离级别基础上所做的限定更进一步， 在该隔离级别下，一个事务的更新操作结果只有在该事务提交之后，另一个事务才可能读取到同一笔数据更新后的结果。 所以，Read Committed可以避免Read Uncommitted隔离级别下存在的脏读问题， 但，无法避免不可重复读取和幻读的问题。
-
Repeatable Read. Repeatable Read隔离级别可以保证在整个事务的过程中，对同一笔数据的读取结果是相同的，不管其他事务是否同时在对同一笔数据进行更新，也不管其他事务对同一笔数 据的更新提交与否。 Repeatable Read隔离级别避免了脏读和不可重复读取的问题，但无法避免幻读。
-
Serializable. 最为严格的隔离级别，所有的事务操作都必须依次顺序执行，可以避免其他隔离级别遇到的所有问题，是最为安全的隔离级别， 但同时也是性能最差的隔离级别，因为所有的事务在该隔离级别下都需要依次顺序执行，所以，并发度下降，吞吐量上不去，性能自然就下来了。 因为该隔离级别极大的影响系统性能，所以，很少场景会使用它。通常情况下，我们会使用其他隔离级别加上相应的并发锁的机制来控制对数据的访问，这样既保证 了系统性能不会损失太大，也能够一定程度上保证数据的一致性。
不同的隔离级别设置会对系统的并发性以及数据一致性造成不同的影响，总的来说，隔离级别与系统并发性成反比，与数据一致性成正比。 也就是说，事务隔离度越高，系统并发性越差，进而造成系统性能就越差，不过，隔离度的增高，却可以更好地保证数据的一致性。隔离程度与并发性和一致性的关 系如下图：
在具体的实践过程中，我们需要根据系统的具体情况来调整隔离度以保证系统性能与数据一致性之间有一个良好的平衡，但总的来说，保证数据的一致性的考虑应该优于对系统性能的考虑。 -
- 事务的持久性(Durability)
-
事务的持久性是指一旦整个事务操作成功提交完成，对数据所做的变更将被记载并不可逆转，多少有点儿“生米煮成熟饭” 的意思。 即使发生某些系统灾难或者什么天灾人祸之类的事情，之前事务所做的变更也可以找回并恢复。纵使海枯石烂，我(数据库等资源管理系统)对你(事务)的真心永 不变！ 通常情况下，数据库等数据资源管理系统会通过冗余存储或者多数据网络备份等方式来保证事务的持久性。
至此，对事务自身的认识就算告一段落了，接着，让我们进一步认识一下与事务有关的“家族成员”吧！
在一个典型的事务处理场景中，有以下几个参与者：
- Resource Manager(RM)
-
ResourceManager简称RM，它负责存储并管理系统数据资源的状态，比如数据库服务器，JMS消息服务器等都是相应的Resource Manager。
- Transaction Processing Monitor(TP Monitor)
-
Transaction Processing Monitor简称TPM或者TP Monitor，它的职责是在分布式事务场景中协调包含多个RM的事务处理。TP Monitor通常对应特定的软件中间件(Middleware)， 随着软件开发技术的进步，TP Monitor的实现也由原来基于过程式的设计与实现转向面向对象的更趋模块化的设计和实现。J2EE规范[4]中的应用服务器(Application Server)通常担当的就是TP Monitor的角色。
- Transaction Manager(TM)
-
Transaction Manager简称为TM，它可以认为是TP Monitor中的核心模块，直接负责多RM之间的事务处理的协调工作，并且提供事务界定(Transaction Demarcation)[5]， 事务上下文传播(transaction context propagation)[6]等功能接口。
- Application
-
以独立形式存在的或者运行于容器中的应用程序，可以认为是事务边界的触发点。
-
全局事务(Global Transaction). 如果整个事务处理过程中有多个Resource Manager的参与，那么就需要引入TP Monitor来协调多个RM之间的事务处理，TP Monitor将采用“两阶段提交(2 Phase Commit)”协议来保证整个事务的ACID属性， 这种场景下的事务我们就称其为全局事务(Global Transaction)或者分布式事务(Distributed Transaction)。全局事务中各个参与者之间的关系如下图所示：
所有应用程序提交的事务请求需要通过TP Monitor的调配之后，直接由TM统一协调，TM将使用“两阶段提交(two-phase commit)”协议来协调处理多RM之间的事务处理。 针对“两阶段提交”的描述，最经典的比喻就是西方婚礼的过程，婚礼的牧师或者主持是TM，他会首先询问两位新人(两个RM)，是否愿意娶对方为妻(嫁给对方)， 如果双方的反馈都是“I do”的时候，牧师将宣布二者结为夫妻(即整个事务提交成功)。如果双方任何一方有疑议，那不好意思，婚礼无法继续进行，整个事务提交失败，双方都要回滚(rollback)到之前的单身状态。 -
局部事务(Local Transaction). 如果当前事务只有一个Resource Manager参与其中的话，我们就可以称当前事务为局部事务(Local Transaction)。 比如，你在当前事务中只对一个数据库进行更新，或者只向一个消息队列中发送消息的情况，都属于局部事务。
因为局部事务只包含一个Resource manager，所以，也就没有必要引入相应的TP Monitor来帮助协调管理多个Resource Manager之间的事务， 应用程序可以直接与RM打交道。通常情况下，相应的RM都有内置的事务支持，所以，在局部事务中，我们更倾向于直接使用RM的内置事务支持， 这样不仅可以极大的减少事务处理的复杂度，也避免了引入TP Monitor来协调多个Resource Manager之间事务的性能负担。
Caution
局部事务与全局事务的主要区分在于“事务”中牵扯多少RM，而不是“系统”中实际有多少RM，这是需要我们注意的地方。 即使你系统中存在多个数据库(即RM)，只要你当前事务只更新一个数据库的数据，那当前事务就依然应该算作局部事务，而不是全局事务(虽然这种情况下，你也可以启用全局事务)。
实际上，针对单一事务资源的事务管理，你可以在局部事务中直接使用RM内置的事务支持来进行，你也可以引入TP Monitor在分布式事务场景中进行，通常情况下， 各TP Monitor在实现的时候会检测参与事务的RM数目，如果只有单一的RM参与，TP Monitor会做一定的优化，避免采用“两阶段提交”协议的负担， 但即使如此，针对单一事务资源参与的事务，直接采用局部事务中RM内置的事务支持，无论是从复杂度，还是从效率上来看，都要更胜一筹。
更具体的事物介绍可查看链接：http://www.cnblogs.com/ysxlin/archive/2008/06/06/1215300.html2.
2.声明式事物和编程式事物的区别：
编程式事务：所谓编程式事务指的是通过编码方式实现事务，即类似于JDBC编程实现事务管理。管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。
声明式事务：管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。
显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。
声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。
3.声明式事物管理配置：
项目使用SSH架构，现在要添加Spring事务管理功能，针对当前环境，只需要添加Spring 2.0 AOP类库即可。添加方法：- 点击项目右键->Build Path->Add librarys:
- 打开Add Libraries对话框，然后选定 MyEclipse Libraries：
- 点击Next，找到Spring 2.0 aop Libraries并勾选上，点击finsh即可。
- 如果在项目里面能看到下面的库文件，说明已经安装成功。
事务配置
- 首先在/WEB-INF/applicationContext.xml添加以下内容：
<!-- 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory"> <ref bean="mySessionFactory"/>
</property>
</bean>
注：这是作为公共使用的事务管理器Bean。这个会是事先配置好的，不需各个模块各自去配。
- 下面就开始配置各个模块所必须的部分，在各自的applicationContext-XXX-beans.xml配置的对于事务管理的详细信息。
<!-- 配置事务传播特性 -->
<tx:advice id="TestAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="save*" propagation="REQUIRED"/>
<tx:method name="del*" propagation="REQUIRED"/>
<tx:method name="update*" propagation="REQUIRED"/>
<tx:method name="add*" propagation="REQUIRED"/>
<tx:method name="find*" propagation="REQUIRED"/>
<tx:method name="get*" propagation="REQUIRED"/>
<tx:method name="apply*" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
<!-- 配置参与事务的类 -->
<aop:config>
<aop:pointcut id="allTestServiceMethod" expression="execution(* com.test.testAda.test.model.service.*.*(..))"/>
<aop:advisor pointcut-ref="allTestServiceMethod" advice-ref="TestAdvice" />
</aop:config>
需要注意的地方: （1） advice（建议）的命名：由于每个模块都会有自己的Advice，所以在命名上需要作出规范，初步的构想就是模块名+Advice（只是一种命名规范）。 （2） tx:attribute标签所配置的是作为事务的方法的命名类型。 如<tx:method name="save*" propagation="REQUIRED"/> 其中*为通配符，即代表以save为开头的所有方法，即表示符合此命名规则的方法作为一个事务。 propagation="REQUIRED"代表支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 （3） aop:pointcut标签配置参与事务的类，由于是在Service中进行数据库业务操作，配的应该是包含那些作为事务的方法的Service类。 首先应该特别注意的是id的命名，同样由于每个模块都有自己事务切面，所以我觉得初步的命名规则因为 all+模块名+ServiceMethod。而且每个模块之间不同之处还在于以下一句： expression="execution(* com.test.testAda.test.model.service.*.*(..))" 其中第一个*代表返回值，第二*代表service下子包，第三个*代表方法名，“（..）”代表方法参数。 （4） aop:advisor标签就是把上面我们所配置的事务管理两部分属性整合起来作为整个事务管理。 图解： 
下面附上配置声明式事务的一些相关的资料，以下资料均来源于互联网： 附一、Spring事务类型详解 附二、对spring事务类型详解的一点补充（关于嵌套事务） 附三、Transaction后缀给声明式事务管理带来的好处 附四、Spring中的四种声明式事务的配置
附一、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声明式事务的方法：
/** *使用SPring的ibatis，主要要配置iBatis的Spring声明式事务。 *@throwsException *<prop key="uninstall*Wcms*Transaction">PROPAGATION_REQUIRED,-Exception</prop> *1，还要删除所有 频道---新闻--工作流表中标记不为1的记录。 */publicvoid uninstallAllWcmsProcessDefinitionsTransaction() throws Exception{ /** * * */this.getWcmsSystemChannelProcessdefinitionDao().deleteAll(); this.getWcmsSystemChannelNewsinfoDao().deleteAllProcessingWcmsSystemChannelNewsinfoModule(); } /** *<prop key="uninstall*Wcms*Transaction">PROPAGATION_REQUIRED,-Exception</prop> *@paramname *@throwsException */publicvoid uninstallWcmsSystemChannelProcessdefinitionTransaction(String name) throws Exception{ this.getWcmsSystemChannelProcessdefinitionDao().deleteByProcessdefinitionName(name); this.getWcmsSystemChannelNewsinfoDao().deleteAllProcessingWcmsSystemChannelNewsinfoModuleByProcessdefinitionName(name); } （二）用到的Dao类，用来实际访问数据库的2个DAO对象。/***SPring管理的ibatis功能*/private IWcmsSystemChannelProcessdefinitionDao wcmsSystemChannelProcessdefinitionDao;private IWcmsSystemChannelNewsinfoDao wcmsSystemChannelNewsinfoDao; |
附四、Spring中的四种声明式事务的配置
让我们言归正传吧。 以下两个bean的配置是下面要用到的。<!-- 定义事务管理器（声明式的事务） -->
<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory">
<ref local="sessionFactory" />
</property>
</bean>
<!-- *******业务逻辑层(是对各个DAO层的正面封装)主要用到<<门面模式>>****** -->
<bean id="fundService"
class="com.jack.fund.service.serviceimpl.FundService">
<property name="operdao">
<ref bean="operatorDAO" />
</property>
<property name="producedao">
<ref bean="fundProduceDAO" />
</property>
<property name="customerdao">
<ref bean="customerDAO" />
</property>
<property name="accountdao">
<ref bean="accountDAO" />
</property>
<property name="fundaccountdao">
<ref bean="fundAccountDAO" />
</property>
<property name="fundtransdao">
<ref bean="fundTransDAO" />
</property>
</bean>
可能还有其他很多模块。<bean id="fundService"/>可能只是其中的模块。 第一种：配置声明式事务的方法如下（使用代理方式）。也是我们最常用的方法了，它适用于你的库表比较少的情况下。
<bean id="fundServiceDAOProxy"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<!-- 配置事务管理器 -->
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<!-- 此属性指定目标类本省是否是代理的对象，如果目标类没有实现任何类，就设为true代表自己 -->
<property name="proxyTargetClass">
<value>false</value>
</property>
<property name="proxyInterfaces">
<value>com.jack.fund.service.IFundService</value>
</property>
<!-- 目标bean -->
<property name="target">
<ref bean="fundService" />
</property>
<!-- 配置事务属性 -->
<property name="transactionAttributes">
<props>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
以下可能还有其他的xxxServiceDAOProxy.大家可以看出针对每一个功能模块配置一个业务代理服务。如果模块多大话，就显得代码有点多了，发现他们只是稍微一点不一样。这时我们就应该想到继承的思想。用第二种方法。 第二种：配置声明式事务的方法如下。这种情况适合相对比较多的模块时使用。
<!-- 利用继承的思想简化配置，要把abstract="true" -->
<bean id="transactionBase"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
lazy-init="true" abstract="true">
<!-- 配置事务管理器 -->
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<!-- 配置事务属性 -->
<property name="transactionAttributes">
<props>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
而具体的模块可以简单的这样配置。只要指明它的parent（父类）就可以了。父类一般把abstract="true"，因为在容器加载的时候不需要初始化，等到用的时候再有它的子类调用的时候，再去初始化。
<bean id="fundServiceDAOProxy" parent="transactionBase" >
<property name="target">
<ref bean="fundService" />
</property>
</bean>
这样配置的话，如果有多个像fundService这样模块时，可以少些很多重复的代码。 第三种：配置声明式事务的方法如下（拦截器方式）。主要利用BeanNameAutoProxyCreator自动创建事务代理
<bean id="transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<!-- 配置事务属性 -->
<property name="transactionAttributes">
<props>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
<bean
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>fundService</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>transactionInterceptor</value>
</list>
</property>
</bean>
这种方法主要利用了拦截器的原理。 前三种方法一般都必需指定具体的模块bean.如果模块过多话，比如一个大型的网站一般有几十个模块。我们就得考虑用第四种的配置方式了。自动创建事务代理的方式了。 第四种：配置声明式事务的方法如下。
<bean id="transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<!-- 自动代理 -->
<bean id="autoproxy"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<!-- 可以是Service或DAO层（最好是针对业务层*Service） -->
<property name="beanNames">
<list>
<value>*Service</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>transactionInterceptor</value>
</list>
</property>
</bean>
自动代理还有一种用法就是结合正规表达式和advice使用。
<bean id="transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
<property name="transactionManager">
<ref bean="transactionManager" />
</property>
<bean id="autoProxyCreator"
class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator" />
<bean id="regexpMethodPointcutAdvisor"
class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice">
<ref bean="transactionInterceptor" />
</property>
<property name="pattern">
<value>.*</value>
</property>
</bean>
这个方法可以针对具体的模块进行拦截并进行事务处理。第五种：采用注解的方式：需要注意的是，使用注解的方式需要在Spring的配置文件中加入一句话：<context:annotation-config />，其作用是开启注解的方式。具体配置如下：
- <!--开启注解方式-->
- <context:annotation-config />
- <!-- 配置sessionFactory -->
- <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
- <property name="configLocation">
- <value>classpath:config/hibernate.cfg.xml</value>
- </property>
- <property name="packagesToScan">
- <list>
- <value>com.entity</value>
- </list>
- </property>
- </bean>
- <!-- 配置事务管理器 -->
- <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
- <property name="sessionFactory" ref="sessionFactory"></property>
- </bean>
- <!-- 第四种配置事务的方式，注解 -->
- <tx:annotation-driven transaction-manager="transactionManager"/>
- package com.dao;
- import org.springframework.orm.hibernate3.HibernateTemplate;
- import org.springframework.transaction.annotation.Propagation;
- import org.springframework.transaction.annotation.Transactional;
- import com.entity.User;
- @Transactional
- public class UserDaoImpl_BAK extends HibernateTemplate {
- @Transactional(propagation=Propagation.REQUIRED,rollbackForClassName="Exception")
- public void addUser(User user) throws Exception {
- this.save(user);
- }
- @Transactional(propagation=Propagation.REQUIRED,rollbackForClassName="Exception")
- public void modifyUser(User user) {
- this.update(user);
- }
- @Transactional(propagation=Propagation.REQUIRED,rollbackForClassName="Exception")
- public void delUser(String username) {
- this.delete(this.load(User.class, username));
- }
- @Transactional(readOnly=true)
- public void selectUser() {
- }
- }
类头的@Transactional为默认事务配置，如方法没有自己的事务类型，则按默认事务，如有自己的配置，则按自己的配置。 以上四种配置方式最常用的还是第一、二种，第三种是比较老旧的方式，而注解的方式不太适合比较大的项目，用于简单的小项目还是很好的，其特点就是简单明了。每种方法都有每种方法的特点跟适用的环境，没有绝对的好与坏，只不过前两种在实际的工作当中用的更多一些。 在你的实际项目中，你可以根据你的情况选用不同的方法。
想了解更多spring事物，可链接：http://www.cnblogs.com/ysxlin/archive/2008/06/06/1215300.html