PROPAGATION_REQUIRED -- 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 
PROPAGATION_SUPPORTS -- 支持当前事务，如果当前没有事务，就以非事务方式执行。 
PROPAGATION_MANDATORY -- 支持当前事务，如果当前没有事务，就抛出异常。 
PROPAGATION_REQUIRES_NEW -- 新建事务，如果当前存在事务，把当前事务挂起。 
PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 
PROPAGATION_NEVER -- 以非事务方式执行，如果当前存在事务，则抛出异常。 
PROPAGATION_NESTED -- 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。 
前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。 
它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager） 

假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下 
/** 
* 事务属性配置为 PROPAGATION_REQUIRED 
*/ 
void methodA() { 
// 调用 ServiceB 的方法 
ServiceB.methodB(); 
} 
那么如果 ServiceB 的 methodB  如果配置了事务, 就必须配置为 PROPAGATION_NESTED 

这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点，PROPAGATION_REQUIRED 已经说得很明白, 
如果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务，就新建一个事务, 所以 ServiceB#methodB() 的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务) 如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么 Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在 Service 还是 Dao 里 ? 

最容易弄混淆的其实是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么这两种方式又有何区别呢? 我简单的翻译一下 Juergen Hoeller 的话 : 
PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行. 

    另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务,  它是已经存在事务的一个真正的子事务. 潜套事务开始执行时,  它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交. 

    由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.

 那么外部事务如何利用嵌套事务的 savepoint 特性呢, 我们用代码来说话

ServiceA {       
    /**  
     * 事务属性配置为 PROPAGATION_REQUIRED  
     */  
    void methodA() {   
        ServiceB.methodB();    }   
 }     
ServiceB {      
    /**  
     * 事务属性配置为 PROPAGATION_REQUIRES_NEW  
     */    
    void methodB() {   
    }         
}   

这种情况下, 因为 ServiceB#methodB 的事务属性为 PROPAGATION_REQUIRES_NEW, 所以两者不会发生任何关系, ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在 ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了 (关于事务挂起的内容已经超出了本文的讨论范围, 有时间我会再写一些挂起的文章) . 

ServiceA {      
    /**  
     * 事务属性配置为 PROPAGATION_REQUIRED  
     */  
    void methodA() {   
        ServiceB.methodB();   
    }   
}     
ServiceB {         
    /**  
     * 事务属性配置为 PROPAGATION_NESTED  
     */    
    void methodB() {   
    }         
} 

ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint(注意, 这是本文中第一次提到它, 潜套事务中最核心的概念), 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式: 
1. 改写 ServiceA 如下 

ServiceA {      
    /**  
     * 事务属性配置为 PROPAGATION_REQUIRED  
     */  
    void methodA() {   
        try {   
            ServiceB.methodB();   
        } catch (SomeException) {   
            // 执行其他业务, 如 ServiceC.methodC();   
        }   
    }    
}  

这种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点. (题外话 : 看到这种代码, 似乎似曾相识, 想起了 prototype.js 中的 Try 函数 ) 

2. 代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此), 外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback (+MyCheckedException). 
上面大致讲述了潜套事务的使用场景, 下面我们来看如何在 spring 中使用 PROPAGATION_NESTED, 首先来看 AbstractPlatformTransactionManager 

JdbcTransactionObjectSupport 告诉我们必须要满足两个条件才能 createSavepoint : 
  
2. java.sql.Savepoint 必须存在, 即 jdk 版本要 1.4+ 
3. Connection.getMetaData().supportsSavepoints() 必须为 true, 即 jdbc drive 必须支持 JDBC 3.0 

确保以上条件都满足后, 你就可以尝试使用 PROPAGATION_NESTED 了.

• 1.get()方法:先确认该ID对应的数据是否存在,先经过session缓存,再二级缓存,之后是数据库,如果不存在,返回null
• 2.load()方法:hibernate会默认你是存在的,他会放心的使用代理类在延迟加载数据,当用到他的其他属性时,就会跑去数据库中查询,如果不在,抛异常
• 3.list()方法:去数据库读取数据,填充缓存,
• 4.iterator()方法:先去数据库select id from table,之后到缓存中查找,如果不存在,出现N+1问题.

缓存 

• 1.一级缓存:session级缓存,如果session关闭,,清空,释放内存

• 2.二级缓存:SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置hibernate.cache.provider_class
• 缓存可以看成是个hastable,典型的空间换时间,一般在读写比高的情况下使用

Hibernate中使用二级缓存 

• Class的缓存  
  对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：  
  <cache usage=“read-write”/><缓存并发策略>
• 使用二级缓存第三方插件ehcache.jar来实现,在hibernate.cfg.xml中配置
• 如下图:是我测试TestDAO工程的hiberante.cfg.xml配置

Hiberante.cfg.xml

ehcache.xml配置 

• <defaultCache  
          maxElementsInMemory=“10000” //在缓存区最大元素 默认为10000；  
          eternal=“false”  //是否永久不超时  
          timeToIdleSeconds=“120”  // ：缓存数据的钝化时间，也就是在一个元素消亡之前，两次访问时间的最大时间间隔值  
          timeToLiveSeconds=“120” //从创建后存活的最长时间  
          overflowToDisk="true" //溢出到硬盘；  
          /> 

• 每个存储的CLASS都要有这样的配置,如果你没配置,Hibernate会警告你,然后使用缺省的defaultCache

查询缓存  

• 需要配置<property name="hibernate.cache.use_query_cache">true</property>
• query.setCacheable(true);//激活查询缓存  
  query.setCacheRegion(“myCacheRegion”);//指定要使用的cacheRegion,如果不做,会使用标准的查询缓存的配置
• 查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息
• 重点:如果是list()方式的话，value在这里并不是整个结果集，而是查询出来的一串ID.
• 不管是list方法还是iterate方法，第一次查询的时候，它们的查询方式和它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了value，value是一串id，然后在到class的缓存里面去一个一个的load出来。
• 所以说,查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的,还有一点,Class缓存的时间一定要比查询缓存长,不然还是会出现N+1问题

缓存与数据库同步 

• hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面org.hibernate.cache. UpdateTimestampsCache所指定的缓存配置里面。 

•   
  当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。  
  可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。

使用二级缓存的前置条件 

• 使用hiberante的应用对数据库具有独占访问权,既不能被第三方修改数据,因为那样缓存不知道你修改了数据,无法与数据库同步.
• 如果自己程序里使用了JDBC来更新，不通过hiberante更新,也会出现跟数据库不同步的情况