Hibernate的session.flush做了什么呢【2】

前面简单的介绍了一下Hibernate的flush机制和对我们程序可能带来的影响以及相应的解决方法，Hibernate的缓存机制还会在其他的方面给我们的程序带来一些意想不到的影响。看下面的例子：

（name为cat表的主键）
Cat cat = new Cat();
cat.setName(“tom”);
s.save(cat);

cat.setName(“mary”);
s.update(cat);(6)

Cat littleCat = new Cat();
littleCat.setName(“tom”);
s.save(littleCat);

s.flush();

这个例子看起来有什么问题？估计不了解Hibernate缓存机制的人多半会说没有问题，但它也一样不能按照我们的思路正常运行，在flush过程中会产生主键冲突，可能你想问：“在save(littleCat)之前不是已经更改cat.name并已经更新了么？为什么还会发生主键冲突那？”这里的原因就是我在解释第一个例子时所提到的缓存flush顺序的问题，Hibernate按照insert,update,……,delete的顺序提交所有登记的操作，所以你的s.update(cat)虽然在程序中出现在s.save(littleCat)之前，但是在flush的过程中，所有的save都将在update之前执行，这就造成了主键冲突的发生。

这个例子中的更改方法一样是在(6)之后加入s.flush()强制Session在保存littleCat之前更新cat的name。这样在第二次flush时就只会执行s.save(littleCat)这次登记的动作，这样就不会出现主键冲突的状况。

再看一个例子（很奇怪的例子，但是能够说明问题）

Cat cat = new Cat();
cat.setName(“tom”);
s.save(cat); (7)
s.delete(cat);(8)

cat.id=null;(9)
s.save(cat);(10)
s.flush();

这个例子在运行时会产生异常net.sf.hibernate.HibernateException: identifier of an instance of Cat altered from 8b818e920a86f038010a86f03a9d0001 to null

这里例子也是有关于缓存的问题，但是原因稍有不同：
（7）和（2）的处理相同。
（8）Session会在deletions中登记这个删除动作，同时更新entityEntries中该对象的登记状态为DELETED。
（9）Cat类的标识符字段为id,将其置为null便于重新分配id并保存进数据库。
（10）此时Session会首先在entityEntries查找cat对象是否曾经与Session做过关联，因为cat只改变了属性值，引用并未改变，所以会取得状态为DELETED的那个登记对象。由于第二次保存的对象已经在当前Session中删除，save会强制Session将缓存flush才会继续，flush的过程中首先要执行最开始的save动作，在这个save中检查了cat这个对象的id是否与原来执行动作时的id相同。不幸的是，此时cat的id被赋为null，异常被抛出，程序终止（此处要注意，我们在以后的开发过程尽量不要在flush之前改变已经进行了操作的对象的id）。

这个例子中的错误也是由于缓存的延时更新造成的（当然，与不正规的使用Hibernate也有关系），处理方法有两种：
1、在（8）之后flush，这样就可以保证（10）处save将cat作为一个全新的对象进行保存。
2、删除（9），这样第二次save所引起的强制flush可以正常的执行，在数据库中插入cat对象后将其删除，然后继续第二次save重新插入cat对象，此时cat的id仍与从前一致。

这两种方法可以根据不同的需要来使用，呵呵，总觉得好像是很不正规的方式来解决问题，但是问题本身也不够正规，只希望能够在应用开发中给大家一些帮助，不对的地方也希望各位给与指正。

　　总的来说，由于Hibernate的flush处理机制，我们在一些复杂的对象更新和保存的过程中就要考虑数据库操作顺序的改变以及延时flush是否对程序的结果有影响。如果确实存在着影响，那就可以在需要保持这种操作顺序的位置加入flush强制Hibernate将缓存中记录的操作flush入数据库，这样看起来也许不太美观，但很有效。