原理:
1. 读取并解析配置文件
2. 读取并解析映射信息,创建SessionFactory
3. 打开Sesssion
4. 创建事务Transation
5. 持久化操作
6. 提交事务
7. 关闭Session
8. 关闭SesstionFactory
1.Hibernate 的初始化
读取Hibernate 的配置信息,创建Session Factory
1)创建Configeration类的实例
它的构造方法:将配置信息(Hibernate config.xml)读入到内存。
一个Configeration 实例代表Hibernate 所有Java类到Sql数据库映射的集合。
2)创建SessionFactory实例
把Configeration 对象中的所有配置信息拷贝到SessionFactory的缓存中。
SessionFactory的实例代表一个数据库存储源,创建后不再与Configeration 对象关联。
缓存(cache):指Java对象的属性(通常是一些集合类型的属性)占用内存空间。
SessionFactory的缓存中:Hibernate 配置信息。OR映射元数据。
缓存-大:重量级对象 小:轻量级对象
3)调用SessionFactory创建Session的方法
1】用户自行提供JDBC连接。
Connection con=dataSource.getConnection();
Session s=sessionFactory.openSession(con);
2】让SessionFactory提供连接
Session s=sessionFactory.openSession();
4)通过Session 接口提供的各种方法来操纵数据库访问。
2.Hibernate 的缓存体系
一级缓存:
Session 有一个内置的缓存,其中存放了被当前工作单元加载的对象。 每个Session 都有自己独立的缓存,且只能被当前工作单元访问。
二级缓存 :
SessionFactory的外置的可插拔的缓存插件。其中的数据可被多个Session共享访问。
SessionFactory的内置缓存:存放了映射元数据,预定义的Sql语句。
3.Hibernate 中Java对象的状态
1.临时状态 (transient)
特征:
1】不处于Session 缓存中
2】数据库中没有对象记录
Java如何进入临时状态
1】通过new语句刚创建一个对象时
2】当调用Session 的delete()方法,从Session 缓存中删除一个对象时。
2.持久化状态(persisted)
特征:
1】处于Session 缓存中
2】持久化对象数据库中设有对象记录
3】Session 在特定时刻会保持二者同步
Java如何进入持久化状态
1】Session 的save()把临时-》持久化状态
2】Session 的load(),get()方法返回的对象
3】Session 的find()返回的list集合中存放的对象
4】Session 的update(),saveOrupdate()使游离-》持久化
3.游离状态(detached)
特征:
1】不再位于Session 缓存中
2】游离对象由持久化状态转变而来,数据库中可能还有对应记录。
Java如何进入持久化状态-》游离状态
1】Session 的close()方法
2】Session 的evict()方法,从缓存中删除一个对象。提高性能。少用
Hibernate优点
1. 对JDBC访问数据库的代码做了封装,大大简化了数据访问层繁琐的重复性代码。
2. Hibernate是一个基于JDBC的主流持久化框架,是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作
3. hibernate使用Java反射机制 ,而不是字节码增强程序来实现透明性。
4. hibernate的性能非常好,因为它是个轻量级框架 。映射的灵活性很出色。它支持各种关系数据库 ,从一对一到多对多的各种复杂关系。
Hibernate延迟加载
1. Hibernate2延迟加载实现:a)实体对象 b)集合(Collection)
2. Hibernate3 提供了属性的延迟加载功能
当Hibernate在查询数据的时候,数据并没有存在与内存中,当程序真正对数据的操作时,对象才存在与内存中,就实现了延迟加载,他节省了服务器的内存开销,从而提高了服务器的性能。
Hibernate关系
类与类之间的关系主要体现在表与表之间的关系进行操作,它们都市对对象进行操作,我们程序中把所有的表与类都映射在一起,它们通过配置文件中的many-to-one、one-to-many、many-to-many、
优化Hibernate
灵活使用单向一对多关联
不用一对一,用多对一取代
配置对象缓存,不使用集合缓存
一对多集合使用Bag,多对多集合使用Set
继承类使用显式多态
表字段要少,表关联不要怕多,有二级缓存撑腰
缓存
hibernate是目前javaee项目中普遍采用ORM解决方案之一,但他提供的缓存机制以及其背后的设计初衷往往并不为开发者完全明了。以下阐述了笔者对hibernate缓存的理解和看法。
注:以下说明忽略了一级缓存
缓存原理:
1 hibernate 只对实体对象缓存,不对属性级别缓存;
2 如果启用了二级缓存,则所有通过hibernate查询到的实体对象都将被缓存到二级缓存;二级缓存的形式为 {key:value,...}形式的hash结构,其中key是实体的主键,value是实体对象。发生查询时,首先获取目标数据的所有id,然后拿这 些id去二级缓存中找,找不到就通过id查数据库,所以有可能会出现查询实体对象*N+1问题;
3 如果启用了查询缓存,则所有通过hibernate查询到的实体对象都将被缓存到二级缓存和查询缓存,查询缓存的形式为 {key:value,...}形式的hash结构,其中key是hql查询语句,value是实体的主键集合。发生查询时,如果查询字符串与缓存的查询 串完全匹配,则用缓存的id去二级缓存中找,找不到就 通过id查数据库,所以有可能会出现查询实体对象*N+1问题;
4 查询缓存的失效控制是以数据表为粒度的,只要数据表中任何一条记录发生改变,整个表相关的所有查询缓存就都无效了;(题外话:这和数据库的查询缓存失效策略是一致的)
5 二级缓存和查询缓存的是否失效都由hibernate维护,如果不通过hibernate改变了缓存涉及到的数据库数据,则缓存不可能正确;
6 对于写操作频繁的系统,必须设置严格的缓存并发策略,在这种情况下,二级缓存和查询缓存对提升数据访问性能的贡献有限,并且仍然存在数据藏读的可能。
7 默认情况下,hibernate不缓存子对象,可以通过配置开启;
2 如果启用了二级缓存,则所有通过hibernate查询到的实体对象都将被缓存到二级缓存;二级缓存的形式为 {key:value,...}形式的hash结构,其中key是实体的主键,value是实体对象。发生查询时,首先获取目标数据的所有id,然后拿这 些id去二级缓存中找,找不到就通过id查数据库,所以有可能会出现查询实体对象*N+1问题;
3 如果启用了查询缓存,则所有通过hibernate查询到的实体对象都将被缓存到二级缓存和查询缓存,查询缓存的形式为 {key:value,...}形式的hash结构,其中key是hql查询语句,value是实体的主键集合。发生查询时,如果查询字符串与缓存的查询 串完全匹配,则用缓存的id去二级缓存中找,找不到就 通过id查数据库,所以有可能会出现查询实体对象*N+1问题;
4 查询缓存的失效控制是以数据表为粒度的,只要数据表中任何一条记录发生改变,整个表相关的所有查询缓存就都无效了;(题外话:这和数据库的查询缓存失效策略是一致的)
5 二级缓存和查询缓存的是否失效都由hibernate维护,如果不通过hibernate改变了缓存涉及到的数据库数据,则缓存不可能正确;
6 对于写操作频繁的系统,必须设置严格的缓存并发策略,在这种情况下,二级缓存和查询缓存对提升数据访问性能的贡献有限,并且仍然存在数据藏读的可能。
7 默认情况下,hibernate不缓存子对象,可以通过配置开启;
所以,如果你的应用系统
1 使用hibernate作为唯一的数据访问代理;
2 读操作频繁而写操作不频繁;
3 常用查询比较简单,缓存命中率较高;
4 数据不要求绝对的安全性;
1 使用hibernate作为唯一的数据访问代理;
2 读操作频繁而写操作不频繁;
3 常用查询比较简单,缓存命中率较高;
4 数据不要求绝对的安全性;
你就可以使用hibernate缓存减轻你的工作负担。
从 以上说明看来,使用hibernate缓存似乎走入了一种全有或全无的误区。其实,hibernate缓存设计的初衷是为开发者提供一种可选的工具,并且 给应用开发提供了足够的自由,这种自由体现到了实体和操作的级别。比如你要使用二级缓存,不但要在.cfg.xml文件中开启,并且还需要 在.hbm.xml中指定,如果你需要,你还可以通过CacheMode在某种操作中禁止使用缓存。初看起来这样做真是不必要的麻烦,但实际上这正是 hibernate认为缓存只应该用在合适的地方的初衷。想想看,尽管在你的业务系统中,大部分数据都变化频繁,但总会有为数不少的元数据,而为这些变化 很少的元数据开启二级缓存甚至查询缓存,不但会提高系统性能,也会为你省去“手工”缓存的麻烦。也许更重要的一点,就是应用hibernate缓存方案不 需要改变你的程序,在你认为可以的地方,通过简单的配置,缓存方案就生效了,这就等于是给系统设计和优化提供了一种非常方便的可能性。
通过以上描述,是否使用hibernate缓存的原则可以变成下面这样:
如果你的系统
或系统的某一部分数据
1 使用hibernate作为唯一的数据访问代理;
2 读操作频繁而写操作不频繁;
3 常用查询比较简单,缓存命中率较高;
4 数据不要求绝对的安全性;
2 读操作频繁而写操作不频繁;
3 常用查询比较简单,缓存命中率较高;
4 数据不要求绝对的安全性;
你就可以使用hibernate缓存减轻你的工作负担。恩... 是的,我只是想强调“某一部分数据”这个概念。好好思考你的系统的需求和特点,对符合条件的数据使用hibernate缓存,也许就是对hibernate开发团队最好的致敬。