`

hibernate总结

    博客分类:
  • SSH
阅读更多

Hibernate不是盏省油的灯,也不是想像的射来射去很简单的事。有很多细节处理不好会让你很不舒服的,这方面最突出的表现在两方面:一是事务管理,是JTA事务还是JDBC事务?幸亏有了Spring和J2EE容器;二是胡乱映射,模型关系建立不合理或者错误导致,或者是映射策略和技术不过关导致。这样的最终结果是抛出一堆HibernateException,摸不着头脑。下面是我实践中的一些总结作为备忘录写出来。参考的是最新的 Hibernate 3.2.6GA API文档,还吸收了Hibernate牛人(夏新)写的书和翻译中文开发手册的精华。  
 
1、Configuration/SessionFactory/Session  
   Configuration实例代表了一个应用程序中Java类型 到SQL数据库映射的完整集合. Configuration被用来构建一个(不可变的 (immutable))SessionFactory.  
   SessionFactory是线程安全的,创建代价很高。  
    Session是非线程安全的,轻量级的。一个Session对应一个JDBC连接,  
    Session的connection()会获取Session与之对应的数据库连接Connection对象。  
    Session的功能就是操作对象的,这些对象和数据库表有映射关系。  
    Session操作的对象是有状态的,分三类:  
    自由状态(transient): 未持久化,未与任何Session相关联,数据库表中没有对应的记录。  
    持久化状态(persistent): 与一个Session相关联,对应数据库表中一条记录。  
    游离状态(detached): 已经进行过持久化,但当前未与任何Session相关联,数据库表中曾经有一条记录,现在还有没有就不知道了。  
 
    游离状态的实例可以通过调用save()、persist()或者saveOrUpdate()方法进行持久化。持久化实例可以通过调用 delete()变成游离状态。通过get()或load()方法得到的实例都是持久化状态的。游离状态的实例可以通过调用 update()、0saveOrUpdate()、lock()或者replicate()进行持久化。游离或者自由状态下的实例可以通过调用 merge()方法成为一个新的持久化实例。  
 
2、Session的save()/persist()/update()/saveOrUpdate()/merge()/delete()方法  
    save()方法将指定对象保存,插入表中一条数据;  
    persist()方法将指定对象保存,插入表中一条数据,我还没发现它和save方法有什么特别之处。  
    replicate()方法完全使用给定对象各个属性的值(包括标识id)来持久化给定的游离状态(Transient)的实体,很暴力啊,其中还需要指定存储模式(有四种保存策略供选择)。  
    update()方法将指定对象更新,更新表中一条数据;  
    saveOrUpdate()方法接收一个实体对象,根据实体对象的id判断是否已经存在进行保存或更新操作,这样保存和更新方法就统一了;  
    merge()方法将给定的对象的状态复制到具有相同标识的持久化对象上。  
    delete()方法将指定对象删除,删除表中一条数据;  
 
    特别注意:为了使用saveOrUpdate()方法,在由定义映射文件时,通过设定<id>标签的unsaved-value= "null"来判断执行什么操作:当id属性等于unsaved-value的值(在此为null)时,则认为还没有保存,应该执行保存操作,否则执行更新操作。这样设定之后,可以使用 saveOrUpdate()方法来统一保存和更新的方法。  
 
    <id name="id" column="id" type="java.lang.Integer" unsaved-value="null">  
        <generator class="native"/>  
    </id>  
 
unsaved-value可以设定的值有四个:  
    any:总是储存  
    none:总是更新  
    null:id为null时储存(预设)  
    valid:id为null或是指定值时储存  
 
3、Session的get()/load()方法  
    get()方法会总是查询实体对象,不存在时候返回null;  
    load()方法也是获取一个实体对象,不存在时候抛空指针异常。  
 
4、Session的clear()/evict()方法  
    clear()方法清除Session级别缓存中的所有实体(包括各种状态)对象,目的是释放内存。  
    evict()方法清除Session级别缓存中的指定的实体(包括各种状态)对象。  
    当然,Session关闭后,这些缓存也就不存在了,会等待JVM回收。  
 
5、Session的flush()方法  
    flush()强制持久化Session缓存中的实体对象。一般还会调用clear()或evict(),目的是赶紧保存,释放宝贵内存资源。  
 
6、Session的commit()/rollback()方法  
    commit()方法用于提交Session上的事务,否则工作单元不会对数据库产生影响。如果执行出现异常(也就是commit()失败了),则之前的操作取消,执行rollback()可撤消之前的操作。  
 
7、Session的close()/isOpen()/isConnected()/reconnect()方法  
    close()方法关闭Session所对应数据库连接,与其相关联的对象生命周期结束。  
    isOpen()方法检查Session是否仍然打开,如果Session已经断开,则可以使用reconnect(Connection connection)来重新让Session关联一个JDBC连接。  
    isConnected()方法检查当前Session是否处于连接状态。  
 
8、Criteria、DetchedCriteria和Query接口  
    Criteria和Query的实例都是和Session绑定的,其生命周期跟随着Session结束而结束。  
    DetchedCriteria实例相当于一个SQL模板,目的是为了复用。其中的getExecutableCriteria(session)方法接收一个Session对象,并与之绑定,返回一个Criteria对象。  
 
9、Hibernate类的initialize()方法  
    initialize()方法强制Hibernate立即加载指定实体所关联的对象和集合。Hibernate类中还有其他几个很有用但不适很常用的方法。  
 
10、映射文件中的lazy属性  
    在Hibernate3中,class元素的lazy属性默认是true,如果不需要,则需要显示指定为lazy="false",否则,操作load返回的对象会抛异常。另外Hibernate3中还可以为实体属性指定lazy属性。  
 
11、JDBC事务和JTA事务  
    Hibernate本身没有事务管理功能,它依赖于JDBC或JTA的事务管理功能,在Hibernate配置文件中,如果不显式指定 Transaction的工厂类别属性hibernate.transaction.factory_class的配置,则默认为JDBC事务:  
    <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory< /property>。  
    在通过SessionFactory获取到Session后,与Session相关联的JDBC Connection实例就被设定为false。  
 
    特别注意:如果数据库不支持事务,比如MySQL的MyISAM引擎的表就不支持事务,声明事务也不会起作用。要使MySQL5的表支持事务,则可以指定表的引擎类型为InnoDB。如果是学习或者研究,目前最好还是使用PostgreSQL 8.3或DB2、Oracle。  
JDBC事务总是和一个数据库连接(或一个Session)相关联的。  
    JTA事务则可以跨越多个数据连接(或多个Session),这些连接还可以是不同数据库的连接,JTA事务一般由容器进行管理。编程只要在多个操作单元的开始和结束定义JTA事务的边界即可。  
 
    特别注意:如果使用了JTA事务,则不能再用在JDBC式的事务来管理每个Session的操作,否则会出错。为了程序的的通用性,一般来说,都是使用 JTA事务来构建应用,这使用任何环境。当然,也可以使用事务代理为每个JDBC的操作方法加入事务控制。这样也为程序以后移植到JTA容器事务上带来很大方便。其实现在可以使用Spring的事务管理,与Hibernate结合的非常完美。  
*****************************************  
hibernate配置正确的情况下:  
   
      在服务层上:  
                  一:如果通过HibernateDaoSupport来getSession  那么 这个session当一个方法结束的时候 就关闭了  
                  二:如果通过HibenateDAOSupport 来getSessionFactory在opensession()那么就是   方法结束后不会关闭session需要自己手动的关闭  
                  三:如果采用的是HibernateTemplate的hbiernatecallback 里面的session是当do..方法结束 就关闭session(不代表 马上就提交事务 这里以后讨论)  
   
  如果 没有配置正确:包括改业务逻辑 没有被spring的事务控制控制 则 上诉 不适用

 

 

 Hibernate缓存总结

1.             Session 级别的缓存,它同 session邦定。它的生命周期和 session相同。 Session消毁,它也同时消毁;管理一级缓存,一级缓存无法取消,用两个方法管理, clear(),evict()

2.             两个 session 不能共享一级缓存,因它会伴随 session的生命周期的创建和消毁;

3.             Session缓存是实体级别的缓存,就是只有在查询对象级别的时候才使用,如果

使用 HQL SQL是查询属性级别的,是不使用一级缓存的!切记!!!!

4 .  iterate 查询使用缓存,会发出查询 Id SQL HQL语句,但不会发出查实体的,

它查询完会把相应的实体放到缓存里边,一些实体查询如果缓存里边有,就从缓存中查询,但还是会发出查询 id SQL HQL语句。如果缓存中没有它会数据库中查询,然后将查询到的实体一个一个放到缓存中去,所以会有 N+1问题出现。

5 . List() iterate 查询区别:

使用iterate,list查询实体对象*N+1问题,在默认情况下,使用query.iterate查询,有可以能出现N+1问题

所谓的N+1是在查询的时候发出了N+1条sql语句1:首先发出一条查询对象id列表的sqlN:

根据id列表到缓存中查询,如果缓存中不存在与之匹配的数据,那么会根据id发出相应的sql语句list和iterate的区别?

list每次都会发出sql语句,list会向缓存中放入数据,而不利用缓存中的数据

iterate:在默认情况下iterate利用缓存数据,但如果缓存中不存在数据有可以能出现N+1问题

6.Get()和load(),iterate方法都会使用一级缓存.  

7.hiberate3 session 存储过程如下:

       例如 object 对象

       Session.save(object);

       这时候不会把数据放到数据库,会先放到session缓存中去,数据库中没有相应记录,session.flush();才发SQL和HQL语句,数据库中有了相应记录,

       但是数据库用select 查不到,这是跟数据库事物级别有关系 .

 

       Session.beginTrransaction().commit();

       事物提交后 可以查询到了。

Session.flush()语句但是为什么不写呢,因为commit()会默认调用flush();


Hiberante3 二级缓存总结

1. Hibernate3的( sessionFactory)二级缓存和 session级别的缓存一样都只对实体对象做缓存,不对属性级别的查询做缓存;二级缓存的生命周期和 sessionFactory的生命周期是一样的, sessionFactory可以管理二级缓存;

2. sessionFactory级别的缓存,需要手动配置;所有的 session可以共享 sessionFactory 级别的缓存;(一般把一些不经常变化的实体对象放到 sessionFactory级别的缓存中,适合放不经常变化的实体对象。)

3. Hiberante3二级缓存的配置和使用方法如下:

1. 必须把 ehcache.jar包导入,然后到 Hibernate3.2 etc文件下把 ehcache.xml复制到工程 src目录下( ehcache.xml里边的参数里边有详细英文说明);

(说明: ehcache.jar是第三方法的缓存产品, hiberante只是把它做了集成,还有好多第三方 hibernate集成的缓存产品,相关说明请查阅 hiberante3开发手册; ehcache是不支持分布应用的,如果有分布式需求,请换成支持分布式的二级缓存产品, hiberate3开发手册都有相头说明。配置方法都类似);

4. Hibernate3的二级缓存默认是开起的,也可以指定开起。在 hibernate.cfg.xml 文件下配置如下:

*修改 hibernate.cfg.xml文件,开户二级缓存;

                     <property name=”hibernate.cache.use_second_level_cache”>true</property>

                     *指定二级缓存产品的提供商;

<property name=”hibernate.cache.provider_class”> org.hibernate.cache.EhCacheProvider

</property>

要让那些实体使用二级缓存,在 hibernate.cfg.xml配置文件中加入:

<!—

让这个实体用二级缓存  也可以在实体中映射文件去配置即:

<cache usage="read-only"/>

-->

<class-cache class=”com.zzz.hibernate.ClassT” usage=”read-only”/>

Read-only一般使用这个策略,其它的 hibernate3开发手册中也有详细介绍;

CacheMode hibernate3开发手册中搜索这个关键字,可以找到一级缓存和二级缓存交互使用的问题;

很多人对二级缓存都不太了解,或者是有错误的认识,我一直想写一篇文章介绍一下hibernate的二级缓存的,今天终于忍不住了。
我的经验主要来自hibernate2.1版本,基本原理和3.0、3.1是一样的,请原谅我的顽固不化。

hibernate的session提供了一级缓存,每个session,对同一个id进行两次load,不会发送两条sql给数据库,但是session关闭的时候,一级缓存就失效了。

二级缓存是SessionFactory级别的全局缓存,它底下可以使用不同的缓存类库,比如ehcache、oscache等,需要设置hibernate.cache.provider_class,我们这里用ehcache,在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查询缓存,加上
hibernate.cache.use_query_cache=true


缓存可以简单的看成一个Map,通过key在缓存里面找value。

Class的缓存
对于一条记录,也就是一个PO来说,是根据ID来找的,缓存的key就是ID,value是POJO。无论list,load还是iterate,只要读出一个对象,都会填充缓存。但是list不会使用缓存,而iterate会先取数据库select id出来,然后一个id一个id的load,如果在缓存里面有,就从缓存取,没有的话就去数据库load。假设是读写缓存,需要设置:
&lt;cache usage="read-write"/&gt;
如果你使用的二级缓存实现是ehcache的话,需要配置ehcache.xml
&lt;cache name="com.xxx.pojo.Foo" maxElementsInMemory="500" eternal="false" timeToLiveSeconds="7200" timeToIdleSeconds="3600" overflowToDisk="true" /&gt;
其中eternal表示缓存是不是永远不超时,timeToLiveSeconds是缓存中每个元素(这里也就是一个POJO)的超时时间,如果eternal="false",超过指定的时间,这个元素就被移走了。timeToIdleSeconds是发呆时间,是可选的。当往缓存里面put的元素超过500个时,如果overflowToDisk="true",就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置,hibernate会在启动的时候警告你,然后使用defaultCache的配置,这样多个class会共享一个配置。
当某个ID通过hibernate修改时,hibernate会知道,于是移除缓存。
这样大家可能会想,同样的查询条件,第一次先list,第二次再iterate,就可以使用到缓存了。实际上这是很难的,因为你无法判断什么时候是第一次,而且每次查询的条件通常是不一样的,假如数据库里面有100条记录,id从1到100,第一次list的时候出了前50个id,第二次iterate的时候却查询到30至70号id,那么30-50是从缓存里面取的,51到70是从数据库取的,共发送1+20条sql。所以我一直认为iterate没有什么用,总是会有1+N的问题。
(题外话:有说法说大型查询用list会把整个结果集装入内存,很慢,而iterate只select id比较好,但是大型查询总是要分页查的,谁也不会真的把整个结果集装进来,假如一页20条的话,iterate共需要执行21条语句,list虽然选择若干字段,比iterate第一条select id语句慢一些,但只有一条语句,不装入整个结果集hibernate还会根据数据库方言做优化,比如使用mysql的limit,整体看来应该还是list快。)
如果想要对list或者iterate查询的结果缓存,就要用到查询缓存了

查询缓存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache,配置ehcache.xml,注意hibernate3.0以后不是net.sf的包名了
&lt;cache name="net.sf.hibernate.cache.StandardQueryCache"
   maxElementsInMemory="50" eternal="false" timeToIdleSeconds="3600"
   timeToLiveSeconds="7200" overflowToDisk="true"/&gt;
&lt;cache name="net.sf.hibernate.cache.UpdateTimestampsCache"
   maxElementsInMemory="5000" eternal="true" overflowToDisk="true"/&gt;
然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion,可选
第二行指定要使用的cacheRegion是myCacheRegion,即你可以给每个查询缓存做一个单独的配置,使用setCacheRegion来做这个指定,需要在ehcache.xml里面配置它:
&lt;cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" /&gt;
如果省略第二行,不设置cacheRegion的话,那么会使用上面提到的标准查询缓存的配置,也就是net.sf.hibernate.cache.StandardQueryCache

对于查询缓存来说,缓存的key是根据hql生成的sql,再加上参数,分页等信息(可以通过日志输出看到,不过它的输出不是很可读,最好改一下它的代码)。
比如hql:
from Cat c where c.name like ?
生成大致如下的sql:
select * from cat c where c.name like ?
参数是"tiger%",那么查询缓存的key*大约*是这样的字符串(我是凭记忆写的,并不精确,不过看了也该明白了):
select * from cat c where c.name like ? , parameter:tiger%
这样,保证了同样的查询、同样的参数等条件下具有一样的key。
现在说说缓存的value,如果是list方式的话,value在这里并不是整个结果集,而是查询出来的这一串ID。也就是说,不管是list方法还是iterate方法,第一次查询的时候,它们的查询方式很它们平时的方式是一样的,list执行一条sql,iterate执行1+N条,多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候,就都和iterate的行为一样了,根据缓存的key去缓存里面查到了value,value是一串id,然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。
可以看出来,查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候,都是既填充查询缓存又填充class缓存的。
这里还有一个很容易被忽视的重要问题,即打开查询缓存以后,即使是list方法也可能遇到1+N的问题!相同条件第一次list的时候,因为查询缓存中找不到,不管class缓存是否存在数据,总是发送一条sql语句到数据库获取全部数据,然后填充查询缓存和class缓存。但是第二次执行的时候,问题就来了,如果你的class缓存的超时时间比较短,现在class缓存都超时了,但是查询缓存还在,那么list方法在获取id串以后,将会一个一个去数据库load!因此,class缓存的超时时间一定不能短于查询缓存设置的超时时间!如果还设置了发呆时间的话,保证class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况,比如class缓存被程序强制evict了,这种情况就请自己注意了。

另外,如果hql查询包含select字句,那么查询缓存里面的value就是整个结果集了。

当hibernate更新数据库的时候,它怎么知道更新哪些查询缓存呢?
hibernate在一个地方维护每个表的最后更新时间,其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。
当通过hibernate更新的时候,hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表,当hibernate查询一个缓存是否存在的时候,如果缓存存在,它还要取出缓存的生成时间和这个缓存所查询的表,然后去查找这些表的最后更新时间,如果有一个表在生成时间后更新过了,那么这个缓存是无效的。
可以看出,只要更新过一个表,那么凡是涉及到这个表的查询缓存就失效了,因此查询缓存的命中率可能会比较低。

Collection缓存
需要在hbm的collection里面设置
&lt;cache usage="read-write"/&gt;
假如class是Cat,collection叫children,那么ehcache里面配置
&lt;cache name="com.xxx.pojo.Cat.children"
   maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
   overflowToDisk="true" /&gt;
Collection的缓存和前面查询缓存的list一样,也是只保持一串id,但它不会因为这个表更新过就失效,一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题,如果你的collection是根据某个字段排序的,当其中一个元素更新了该字段时,导致顺序改变时,collection缓存里面的顺序没有做更新。

缓存策略
只读缓存(read-only):没有什么好说的
读/写缓存(read-write):程序可能要的更新数据
不严格的读/写缓存(nonstrict-read-write):需要更新数据,但是两个事务更新同一条记录的可能性很小,性能比读写缓存好
事务缓存(transactional):缓存支持事务,发生异常的时候,缓存也能够回滚,只支持jta环境,这个我没有怎么研究过

读写缓存和不严格读写缓存在实现上的区别在于,读写缓存更新缓存的时候会把缓存里面的数据换成一个锁,其他事务如果去取相应的缓存数据,发现被锁住了,然后就直接取数据库查询。
在hibernate2.1的ehcache实现中,如果锁住部分缓存的事务发生了异常,那么缓存会一直被锁住,直到60秒后超时。
不严格读写缓存不锁定缓存中的数据。


使用二级缓存的前置条件
你的hibernate程序对数据库有独占的写访问权,其他的进程更新了数据库,hibernate是不可能知道的。你操作数据库必需直接通过hibernate,如果你调用存储过程,或者自己使用jdbc更新数据库,hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的,但是据说3.1已经解决了这个问题。
这个限制相当的棘手,有时候hibernate做批量更新、删除很慢,但是你却不能自己写jdbc来优化,很郁闷吧。
SessionFactory也提供了移除缓存的方法,你一定要自己写一些JDBC的话,可以调用这些方法移除缓存,这些方法是:
void evict(Class persistentClass)
          Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
          Evict an entry from the second-level cache.
void evictCollection(String roleName)
          Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
          Evict an entry from the second-level cache.
void evictQueries()
          Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
          Evict any query result sets cached in the named query cache region.
不过我不建议这样做,因为这样很难维护。比如你现在用JDBC批量更新了某个表,有3个查询缓存会用到这个表,用evictQueries(String cacheRegion)移除了3个查询缓存,然后用evict(Class persistentClass)移除了class缓存,看上去好像完整了。不过哪天你添加了一个相关查询缓存,可能会忘记更新这里的移除代码。如果你的jdbc代码到处都是,在你添加一个查询缓存的时候,还知道其他什么地方也要做相应的改动吗?

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

总结:
不要想当然的以为缓存一定能提高性能,仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的,不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用,可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制,那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存,效果就会越好。就好像尽管磁盘有缓存,数据库还是要实现自己的缓存,尽管数据库有缓存,咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么,只能做的比较通用,而高层可以有针对性的实现缓存,所以在更高的级别上做缓存,效果也要好些吧。


终于写完了,好累……

近日为是否在项目中使用Hibernate进行大数据量的性能测试,有一些总结,
1) 在处理大数据量时,会有大量的数据缓冲保存在Session的一级缓存中,这缓存大太时会严重显示性能,所以在使用Hibernate处理大数据量的,可以使用session.clear()或者session. Evict(Object) 在处理过程中,清除全部的缓存或者清除某个对象。
2) 对大数据量查询时,慎用list()或者iterator()返回查询结果,
1. 使用List()返回结果时,Hibernate会所有查询结果初始化为持久化对象,结果集较大时,会占用很多的处理时间。
2. 而使用iterator()返回结果时,在每次调用iterator.next()返回对象并使用对象时,Hibernate才调用查询将对应的对象初始化,对于大数据量时,每调用一次查询都会花费较多的时间。当结果集较大,但是含有较大量相同的数据,或者结果集不是全部都会使用时,使用iterator ()才有优势。
3. 对于大数据量,使用qry.scroll()可以得到较好的处理速度以及性能。而且直接对结果集向前向后滚动。
3) 对于关联操作,Hibernate虽然可以表达复杂的数据关系,但请慎用,使数据关系较为简单时会得到较好的效率,特别是较深层次的关联时,性能会很差。
4) 对含有关联的PO(持久化对象)时,若default-cascade="all"或者 “save-update”,新增PO时,请注意对PO中的集合的赋值操作,因为有可能使得多执行一次update操作。
5) 在一对多、多对一的关系中,使用延迟加载机制,会使不少的对象在使用时方会初始化,这样可使得节省内存空间以及减少数据库的负荷,而且若PO中的集合没有被使用时,就可减少互数据库的交互从而减少处理时间。
6) 对于大数据量新增、修改、删除操作或者是对大数据量的查询,与数据库的交互次数是决定处理时间的最重要因素,减少交互的次数是提升效率的最好途径,所以在开发过程中,请将show_sql设置为true,深入了解Hibernate的处理过程,尝试不同的方式,可以使得效率提升。
7) Hibernate是以JDBC为基础,但是Hibernate是对JDBC的优化,其中使用Hibernate的缓冲机制会使性能提升,如使用二级缓存以及查询缓存,若命中率较高明,性能会是到大幅提升。
Cool Hibernate可以通过设置hibernate.jdbc.fetch_size,hibernate.jdbc.batch_size等属性,对Hibernate进行优化

 

一。 持久化层的缓存的范围

缓存的范围决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。

1:事务范围:缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期,当事务结束时,缓存也就结束生命周期。在此范围下,缓存的介质是内存。事务可以是数据库事务或者应用事务,每个事务都有独自的缓存,缓存内的数据通常采用相互关联的对象形式。

2:进程范围:缓存被进程内的所有事务共享。这些事务有可能是并发访问缓存,因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于进程的生命周期,进程结束时,缓存也就结束了生命周期。进程范围的缓存可能会存放大量的数据,所以存放的介质可以是内存或硬盘。缓存内的数据既可以是相互关联的对象形式也可以是对象的松散数据形式。松散的对象数据形式有点类似于对象的序列化数据,但是对象分解为松散的算法比对象序列化的算法要求更快。

3:集群范围:在集群环境中,缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点,进程间通过远程通信来保证缓存中的数据的一致性,缓存中的数据通常采用对象的松散数据形式。

持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据,还可以到进程范围或集群范围的缓存内查询,如果还是没有查到,那么只有到数据库中查询。事务范围的缓存是持久化层的第一级缓存,通常它是必需的;进程范围或集群范围的缓存是持久化层的第二级缓存,通常是可选的。

 二。持久化层的缓存的并发访问策略
当多个并发的事务同时访问持久化层的缓存的相同数据时,会引起并发问题,必须采用必要的事务隔离措施。
在进程范围或集群范围的缓存,即第二级缓存,会出现并发问题。因此可以设定以下四种类型的并发访问策略,每一种策略对应一种事务隔离级别。
1: 事务型(Transactional)策略:仅仅在受管理环境中适用。它提供了Repeatable Read事务隔离级别。对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读和不可重复读这类的并发问题。
2: 读写型(read-write)策略:提供了Read Committed事务隔离级别。仅仅在非集群的环境中适用。对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读这类的并发问题。
3: 非严格读写型(nonstrict-read-write)策略:不保证缓存与数据库中数据的一致性。如果存在两个事务同时访问缓存中相同数据的可能,必须为该数据配置一个很短的数据过期时间,从而尽量避免脏读。对于极少被修改,并且允许偶尔脏读的数据,可以采用这种并发访问策略。
4) 只读型策略(read-only):对于从来不会修改的数据,如参考数据,可以使用这种并发访问策略。
事务型并发访问策略是事务隔离级别最高,只读型的隔离级别最低。事务隔离级别越高,并发性能就越低。
分享到:
评论
1 楼 rihui1hao 2012-08-10  
总的来说还是不错的
3、Session的get()/load()方法  
    get()方法会总是查询实体对象,不存在时候返回null;  
    load()方法也是获取一个实体对象,不存在时候抛空指针异常。

load()方法返回的是一个代理对象不是实体对象的

相关推荐

Global site tag (gtag.js) - Google Analytics