Hibernate知识点汇总

Hibernate主键生成策略:


1. assigned - 新增数据时由应用程序指定主键的值
2. increment - 新增数据时先查询主键列最大值，加1作为新主键
3. identity - SQL Server自增列
4. native - 针对不同数据库采用不同的主键生成策略. SQL Server用identity, Oracle则用sequence，区分数据库以Hibernate配置文件里的dialect.
5. uuid - 32位随机码


<id name="实体类属性名" type="java.lang.Integer"> 
      <column name="对应表中主键字段名" /> 
      <generator class="assiged|increment|identity|native|........" /> 
</id> 


---------------------------------------------------------------------------------------------------------------------------


清理缓存:


1. Transaction.commit();
2. 查询操作
3. Session.flush();
                                                       查询操作                        commit()                      flush()
--------------------------------------------------------------------------------------------
FlushMode.AUTO                       Y                                          Y                                       Y


FlushMode.COMMIT                 N                                         Y                                        Y


FlushMode.NEVER                    N                                         N                                       Y


-----------------------------------------------------------------------------------------------------------------------------


Java对象状态:


transient      new Object();


persistent    transient->save(); detached->update()


removed       delete();


detached      session.close();  evict();


=================================================================================


同步:   save(),update(), saveOrUpdate(), delete() -> flush() -> refresh() - If trigger exists


=================================================================================


CacheConcurrencyStrategy.READ_ONLY  只读模式，在此模式下，如果对数据进行更新操作，会有异常；
CacheConcurrencyStrategy.READ_WRITE  读写模式在更新缓存的时候会把缓存里面的数据换成一个锁，其它事务如果去取相应的缓存数据，发现被锁了，直接就去数据库查询；
CacheConcurrencyStrategy.NONSTRICT_READ_WRITE  不严格的读写模式则不会的缓存数据加锁；
CacheConcurrencyStrategy.TRANSACTIONAL   事务模式指缓存支持事务，当事务回滚时，缓存也能回滚，只支持 JTA环境。


EHCache: 可作为进程范围内的缓存，对查询缓存提供了支持(1.7以上支持集群)
JbossCache: 可作为集群范围内的缓存，支持事务型并发访问策略，对Hibernate查询缓存提供了支持


=================================================================================
Session与二级缓存交互模式:


CacheMode.NORMAL: 正常模式(默认), Session会从二级缓存里读取也会写入
CacheMode.IGNORE:  忽略二级缓存，不读不写
CacheMode.GET: 读取模式，Session会读二级缓存，但不会写
CacheMode.PUT:  写入模式，Session不会读二级缓存，但是会写从数据库读到的数据
CacheMode.REFRESH: 刷新模式，Session不读二级缓存，但是会强制刷新二级缓存中的数据


=================================================================================


ehcache.xml
<cache name="org.hibernate.cache.StandardQueryCache"
        maxElementsInMemory="10000"  -缓存中存放对象的最大数目
        eternal="false"                                          -true永不过期
        timeToIdleSeconds="18000"            -自最后一次访问空闲时间，超时则过期
        timeToLiveSeconds="0"                      -最长过期时间，0为无期限, 这一参数应该大于等于timeToIdleSeconds才有意义
        overflowToDisk="true"/>                   - 内存中超过对象最大数目，则缓存在硬盘上




=================================================================================


hibernate的查询缓存


查询缓存的实现机制与二级缓存基本一致，最大的差异在于放入缓存中的key是查询的语句，value是查询之后得到的结果集的id列表。
表面看来这样的方案似乎能解决hql利用缓存的问题，但是需要注意的是，构成key的是：hql生成的sql、sql的参数、排序、分页信息等。
也就是说如果你的hql有小小的差异，比如第一条hql取1-50条数据，第二条hql取20-60条数据，那么hibernate会认为这是两个完全不同的key，
无法重复利用缓存。因此利用率也不高。
另外一个需要注意的问题是，查询缓存和二级缓存是有关联关系的，他们不是完全独立的两套东西。假如一个查询条件hql_1，第一次被执行的时候，
它会从数据库取得数据，然后把查询条件作为key，把返回数据的所有id列表作为value（请注意仅仅是id）放到查询缓存中，同时整个结果集放到
class缓存（也就是二级缓存），key是id，value是pojo对象。当你再次执行hql_1，它会从缓存中得到id列表，然后根据这些列表一个一个的到class缓存
里面去找pojo对象，如果找不到就向数据库发起查询。也就是说，如果二级缓存配置了超时时间（或者发呆时间），就有可能出现查询缓存命中了，
获得了id列表，但是class里面相应的pojo已经因为超时(或发呆)被失效，hibernate就会根据id清单，一个一个的去向数据库查询，有多少个id，就执行多少个sql。
该情况将导致性能下降严重。
查询缓存的失效机制也由hibernate控制，数据进入缓存时会有一个timestamp，它和数据表的timestamp对应。当hibernate环境内发生save、update等操作时，
会更新被操作数据表的timestamp。用户在获取缓存的时候，一旦命中就会检查它的timestamp是否和数据表的timestamp匹配，如果不，缓存会被失效。
因此查询缓存的失效控制是以数据表为粒度的，只要数据表中任何一条记录发生一点修改，整个表相关的所有查询缓存就都无效了。因此查询缓存的命中率可能会很低。
结论：不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。


==========================================================================================================================