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二级缓存作为优化的主要手段，一般情况下建议不要使用。

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