一般来说，在用SSH框架开发项目的时候，一般都是将事务设置在Service层。那么在调用Service层的某个方法的时候，它能够保证这个方法中执行的所有对数据库的更新操作都保持在一个事务中，在事务层里面调用的这些方法要么全部成功，要么全部失败。
那么事务的传播特性也是从这里引出的。
如果在Service层的这个方法中，除了调用了Dao层的方法之外，还调用了本类的其他的Service方法。那么在调用其他的 Service方法的时候，这个事务是怎么规定的呢？规定就是：必须保证在这个方法里调用的那些“本类的其他的Service方法”与我本身的这个方法处在同一个事务中，否则就无法保证事务的一致性。
事务的传播特性就是解决这个问题的。在Spring中有针对事务传播特性的多种配置，大多数情况下只用其中的一种：PROPAGATION_REQUIRED，这个配置项的意思就是，当调用service层的某个方法时已经开启了一个事务(具体调用哪一层的方法开始创建事务，要看具体的AOP配置)，那么在调用那些“本类的其他的Service方法”的时候，如果当前方法产生了事务，就用当前方法产生的事务，否则就创建一个新的事务。这个工作是由Spring来完成。
以前没有Spring来帮助我们完成事务的时候，我们必须自己手动控制事务。例如，当项目中仅仅使用hibernate，而没有集成进 spring的时候，在一个service层中调用其他的业务逻辑方法，为了保证事务一致性，必须要把当前的hibernate session传递到下一个方法中，或者采用ThreadLocal的方法，将session传递给下一个方法，其实都是一个目的。现在这个工作由 spring来帮助我们完成，就可以让我们更加专注于业务逻辑，而不用去关心事务的问题。
默认情况是，当发生RuntimeException时，事务才会回滚。所以要注意一下，如果你在程序发生错误的情况时自定义了异常处理机制，拥有自定义的Exception，那么这个自定义的Exception必须继承RuntimeException类，这样事务才会回滚！
其实，除了上述提到的PROPAGATION_REQUIRED传播机制外，spring总共有6大事务传播机制：
1. Propagation required，如果当前没有事务，就新建一个事务。
2. Propagation supports， 如果当前没有事务，就以非事务方式执行。
3. Propagation mandatory， 如果当前没有事务，就抛出异常。
4. Propagation requires new， 如果当前存在事务，挂起当前事务，新建事务。
5. Propagation not supported,，如果当前存在事务，把当前事务挂起，以非事务方式执行。
6. Propagation never，如果当前存在事务，抛出异常。以非事务方式执行。