一、理解flush机制
之后单纯用原始的Hibernate框架做了一些验证,并且打开执行SQL打印输出台的,得出的结论:
前提是在同一事务中间:
1、利用sql语句, session.createSQLQuery(sql).executeUpdate();进行插入,输出台打印出sql插入语句; 再利用sql语句,进行session.createSQLQuery(sql).uniqueResult(); 也会打印SQL查询语句,没有问题,可以查询到数据。
2、利用hibernate封装操作, session.save(entity); 进行插入,输出台并没有打印出插入的SQL语句, 再利用 session.get(entity,id);方法做查询 ;也没有打印出SQL查询语句,但是是可以查询到数据的。到执行事务提交语句时,插入的SQL语句被打印出来
3、利用hibernate的session.save(entity); 进行插入,再利用《HQL》语句进行查询,效果同上面第二点。
4、利用hibernate的session.save(entity); 进行插入,输出台并没有打印出插入的SQL语句。 再利用sql语句,进行session.createSQLQuery(sql).uniqueResult(); 会打印SQL查询语句。问题出现了,查询不到任何数据。这种情况下利用session.flush()方法,在查询之前执行到flush()方法,输出台会打印出插入的SQL语句。 再进行查询就有数据。
验证完成之后,查了下往上资料,对于第四点,在开发过程中出现频繁,非常的常见,相信很多人都曾遇到,但又有很多人继续摸不到头脑。正好以此加深了印象。
从打印控制台SQL可以看出一个基本的hibernate save方法的操作流程:
1. 判断所要保存的实例是否已处于持久化状态,如果不是,则将其置入缓存;
2. 根据所要保存的实例计划一条insert sql语句,注意只是计划,并不执行;
3. 事务提交时执行之前所计划的insert语句;
将tx.commit()换成session.flush,此时控制太打印出了insert语句,但是数据库中并没有添加新的记录;
flush方法的主要作用就是清理缓存,强制数据库与Hibernate缓存同步,以保证数据的一致性。它的主要动作就是向数据库发送一系列的sql语句,并执行这些sql语句,但是不会向数据库提交。而commit方法则会首先调用flush方法,然后提交事务。这就是为什么我们仅仅调用flush的时候记录并未插入到数据库中的原因,因为只有提交了事务,对数据库所做的更新才会被保存下来。因为commit方法隐式的调用了flush,所以一般我们都不会显示的调用flush方法。
这是hibernate的flush机制。在一些复杂的对象更新和保存的过程中就要考虑数据库操作顺序的改变以及延时flush是否对程序的结果有影响。如果确实存在着影响,那就可以在需要保持这种操作顺序的位置加入flush强制Hibernate将缓存中记录的操作flush入数据库,这样看起来也许不太美观,但很有效。
二、深入flush机制
先讲解两个常用方法:
session.evict(obj) :会把指定的缓冲对象进行清除。
session.clear() :把缓冲区内的全部对象清除,但不包括操作中的对象。
如果在save(obj)后,evict(obj),再事务提交会怎样:
Hibernate 执行的顺序如下:
(1) 生成一个事务的对象,并标记当前的 Session 处于事务状态(注:此时并未启动数据库级事务)。
(2) 应用使用 s.save 保存对象,这个时候 Session 将这个对象放入 entityEntries ,用来标记对象已经和当前的会话建立了关联,由于应用对对象做了保存的操作,Session 还要在 insertions 中登记应用的这个插入行为(行为包括:对象引用、对象 id 、 Session 、持久化处理类)。
(3)s.evict 将对象从 s 会话中拆离,这时 s 会从 entityEntries 中将这个对象移出。
(4) 事务提交,需要将所有缓存 flush 入数据库, Session 启动一个事务,并按照 insert(save),update,……,delete 的顺序提交所有之前登记的操作(注意:所有 insert 执行完毕后才会执行 update ,这里的特殊处理也可能会将你的程序搞得一团糟,如需要控制操作的执行顺序,要善于使用 flush ),现在对象不在 entityEntries中,但在执行 insert 的行为时只需要访问 insertions 就足够了,所以此时不会有任何的异常。异常出现在插入后通知 Session 该对象已经插入完毕这个步骤上,这个步骤中需要将 entityEntries 中对象的 existsInDatabase 标志置为 true ,由于对象并不存在于 entityEntries 中,此时 Hibernate 就认为 insertions 和 entityEntries可能因为线程安全的问题产生了不同步(也不知道 Hibernate 的开发者是否考虑到例子中的处理方式,如果没有的话,这也许算是一个 bug 吧),于是一个net.sf.hibernate.AssertionFailure 就被抛出,程序终止。
一般我们会错误的认为 s.save 会立即执行,而将对象过早的与 Session 拆离,造成了 Session 的 insertions 和 entityEntries 中内容的不同步。所以我们在做此类操作时一定要清楚 Hibernate 什么时候会将数据 flush 入数据库,在未 flush 之前不要将已进行操作的对象从 Session 上拆离。解决办法是在 save 之后,添加session.flush 。
三、flush的设置
Flush方法是可以设置的,也就是 fulsh 什么时候执行是可以设置的
在session.beginTransaction 前设置 FlushMode
session.setFlushMode(FlushMode.Always|AUTO|COMMIT|NEVER|MANUAL)
FlushMode有 5 个值可选
Always:任何代码都会 Flush
AUTO:默认方式 – 自动
Commit:COMMIT时
Never:始终不
MANUAL:手动方式
设置FlushMode 有个好处是可以节省开销,比如默认 session 只做查询时,就可以不让他与数据库同步了。