转自：http://blog.csdn.net/edward0830ly/article/details/7569954 （写的不错）spring
事务是逻辑处理原子性的保证手段，经过使用事务控制，能够极大的避免出现逻辑处理失败致使的脏数据等问题。
事务最重要的两个特性，是事务的传播级别和数据隔离级别。传播级别定义的是事务的控制范围，事务隔离级别定义的是事务在数据库读写方面的控制范围。
如下是事务的7种传播级别：
1） PROPAGATION_REQUIRED ，默认的spring事务传播级别，使用该级别的特色是，若是上下文中已经存在事务，那么就加入到事务中执行，若是当前上下文中不存在事务，则新建事务执行。因此这个级别一般能知足处理大多数的业务场景。
2）PROPAGATION_SUPPORTS ，从字面意思就知道，supports，支持，该传播级别的特色是，若是上下文存在事务，则支持事务加入事务，若是没有事务，则使用非事务的方式执行。因此说，并不是全部的包在transactionTemplate.execute中的代码都会有事务支持。这个一般是用来处理那些并不是原子性的非核心业务逻辑操做。应用场景较少。
3）PROPAGATION_MANDATORY ， 该级别的事务要求上下文中必需要存在事务，不然就会抛出异常！配置该方式的传播级别是有效的控制上下文调用代码遗漏添加事务控制的保证手段。好比一段代码不能单独被调用执行，可是一旦被调用，就必须有事务包含的状况，就可使用这个传播级别。
4）PROPAGATION_REQUIRES_NEW ，从字面便可知道，new，每次都要一个新事务，该传播级别的特色是，每次都会新建一个事务，而且同时将上下文中的事务挂起，执行当前新建事务完成之后，上下文事务恢复再执行。
这是一个颇有用的传播级别，举一个应用场景：如今有一个发送100个红包的操做，在发送以前，要作一些系统的初始化、验证、数据记录操做，而后发送100封红包，而后再记录发送日志，发送日志要求100%的准确，若是日志不许确，那么整个父事务逻辑须要回滚。
怎么处理整个业务需求呢？就是经过这个PROPAGATION_REQUIRES_NEW 级别的事务传播控制就能够完成。发送红包的子事务不会直接影响到父事务的提交和回滚。
5）PROPAGATION_NOT_SUPPORTED ，这个也能够从字面得知，not supported ，不支持，当前级别的特色就是上下文中存在事务，则挂起事务，执行当前逻辑，结束后恢复上下文的事务。
这个级别有什么好处？能够帮助你将事务很可能的缩小。咱们知道一个事务越大，它存在的风险也就越多。因此在处理事务的过程当中，要保证尽量的缩小范围。好比一段代码，是每次逻辑操做都必须调用的，好比循环1000次的某个非核心业务逻辑操做。这样的代码若是包在事务中，势必形成事务太大，致使出现一些难以考虑周全的异常状况。因此这个事务这个级别的传播级别就派上用场了。用当前级别的事务模板抱起来就能够了。
6）PROPAGATION_NEVER ，该事务更严格，上面一个事务传播级别只是不支持而已，有事务就挂起，而PROPAGATION_NEVER传播级别要求上下文中不能存在事务，一旦有事务，就抛出runtime异常，强制中止执行！这个级别上辈子跟事务有仇。
7）PROPAGATION_NESTED ，字面也可知道，nested，嵌套级别事务。该传播级别特征是，若是上下文中存在事务，则嵌套事务执行，若是不存在事务，则新建事务。
那么什么是嵌套事务呢？不少人都不理解，我看过一些博客，都是有些理解误差。
嵌套是子事务套在父事务中执行，子事务是父事务的一部分，在进入子事务以前，父事务创建一个回滚点，叫save point，而后执行子事务，这个子事务的执行也算是父事务的一部分，而后子事务执行结束，父事务继续执行。重点就在于那个save point。看几个问题就明了了：
若是子事务回滚，会发生什么？
父事务会回滚到进入子事务前创建的save point，而后尝试其余的事务或者其余的业务逻辑，父事务以前的操做不会受到影响，更不会自动回滚。
若是父事务回滚，会发生什么？
父事务回滚，子事务也会跟着回滚！为何呢，由于父事务结束以前，子事务是不会提交的，咱们说子事务是父事务的一部分，正是这个道理。那么：
事务的提交，是什么状况？
是父事务先提交，而后子事务提交，仍是子事务先提交，父事务再提交？答案是第二种状况，仍是那句话，子事务是父事务的一部分，由父事务统一提交。
如今你再体会一下这个”嵌套“，是否是有那么点意思？
以上是事务的7个传播级别，在平常应用中，一般能够知足各类业务需求，可是除了传播级别，在读取数据库的过程当中，若是两个事务并发执行，那么彼此之间的数据是如何影响的呢？
这就须要了解一下事务的另外一个特性：数据隔离级别
数据隔离级别分为不一样的四种：
一、Serializable ：最严格的级别，事务串行执行，资源消耗最大；
二、REPEATABLE READ ：保证了一个事务不会修改已经由另外一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的状况，可是带来了更多的性能损失。
三、READ COMMITTED :大多数主流数据库的默认事务等级，保证了一个事务不会读到另外一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
四、Read Uncommitted ：保证了读取过程当中不会读取到非法数据。
上面的解释其实每一个定义都有一些拗口，其中涉及到几个术语：脏读、不可重复读、幻读。
这里解释一下：
脏读 :所谓的脏读，其实就是读到了别的事务回滚前的脏数据。好比事务B执行过程当中修改了数据X，在未提交前，事务A读取了X，而事务B却回滚了，这样事务A就造成了脏读。
不可重复读 ：不可重复读字面含义已经很明了了，好比事务A首先读取了一条数据，而后执行逻辑的时候，事务B将这条数据改变了，而后事务A再次读取的时候，发现数据不匹配了，就是所谓的不可重复读了。
幻读 ：小的时候数手指，第一次数十10个，第二次数是11个，怎么回事？产生幻觉了？
幻读也是这样子，事务A首先根据条件索引获得10条数据，而后事务B改变了数据库一条数据，致使也符合事务A当时的搜索条件，这样事务A再次搜索发现有11条数据了，就产生了幻读。
一个对照关系表：
Dirty reads non-repeatable reads phantom reads
Serializable 不会 不会 不会
REPEATABLE READ 不会 不会 会
READ COMMITTED 不会 会 会
Read Uncommitted 会 会 会
因此最安全的，是Serializable，可是伴随而来也是高昂的性能开销。
另外，事务经常使用的两个属性：readonly和timeout
一个是设置事务为只读以提高性能。
另外一个是设置事务的超时时间，通常用于防止大事务的发生。仍是那句话，事务要尽量的小！
最后引入一个问题：
一个逻辑操做须要检查的条件有20条，可否为了减少事务而将检查性的内容放到事务以外呢？
不少系统都是在DAO的内部开始启动事务，而后进行操做，最后提交或者回滚。这其中涉及到代码设计的问题。小一些的系统能够采用这种方式来作，可是在一些比较大的系统，
逻辑较为复杂的系统中，势必会将过多的业务逻辑嵌入到DAO中，致使DAO的复用性降低。因此这不是一个好的实践。数据库
来回答这个问题：可否为了缩小事务，而将一些业务逻辑检查放到事务外面？答案是：对于核心的业务检查逻辑，不能放到事务以外，并且必需要做为分布式下的并发控制！
一旦在事务以外作检查，那么势必会形成事务A已经检查过的数据被事务B所修改，致使事务A徒劳无功并且出现并发问题，直接致使业务控制失败。
因此，在分布式的高并发环境下，对于核心业务逻辑的检查，要采用加锁机制。
好比事务开启须要读取一条数据进行验证，而后逻辑操做中须要对这条数据进行修改，最后提交。
这样的一个过程，若是读取并验证的代码放到事务以外，那么读取的数据极有可能已经被其余的事务修改，当前事务一旦提交，又会从新覆盖掉其余事务的数据，致使数据异常。
因此在进入当前事务的时候，必需要将这条数据锁住，使用for update就是一个很好的在分布式环境下的控制手段。
一种好的实践方式是使用编程式事务而非生命式，尤为是在较为规模的项目中。对于事务的配置，在代码量很是大的状况下，将是一种折磨，并且人肉的方式，绝对不能避免这种问题。
将DAO保持针对一张表的最基本操做，而后业务逻辑的处理放入manager和service中进行，同时使用编程式事务更精确的控制事务范围。
特别注意的，对于事务内部一些可能抛出异常的状况，捕获要谨慎，不能随便的catch Exception 致使事务的异常被吃掉而不能正常回滚。express
Spring配置声明式事务：
* 配置SessionFactory
* 配置事务管理器
* 事务的传播特性
* 那些类那些方法使用事务编程
编写业务逻辑方法
* 继承HibernateDaoSupport类，使用HibernateTemplate来持久化，HibernateTemplate是
hibernate Session的轻量级封装
* 默认状况下运行期异常才会回滚（包括继承了RuntimeException子类），普通异常是不会滚的
* 编写业务逻辑方法时，最好将异常一直向上抛出，在表示层（struts）处理
* 关于事务边界的设置，一般设置到业务层，不要添加到Dao上安全
<!-- 配置SessionFactory -->
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="configLocation">
<value>classpath:hibernate.cfg.xml</value>
</property>
</bean>
<!-- 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- 事务的传播特性 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="add*" propagation="REQUIRED"/>
<tx:method name="del*" propagation="REQUIRED"/>
<tx:method name="modify*" propagation="REQUIRED"/>
<tx:method name="*" propagation="REQUIRED" read-only="true"/>
</tx:attributes>
</tx:advice>
<!-- 哪些类哪些方法使用事务 -->
<aop:config>
<aop:pointcut expression="execution(* com.service.*.*(..))" id="transactionPC"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="transactionPC"/>
</aop:config>
<!-- 普通IOC注入 -->
<bean id="userManager" class="com.service.UserManagerImpl">
<property name="logManager" ref="logManager"/>
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<bean id="logManager" class="com.service.LogManagerImpl">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>session