关于在使用hibernate在提交事务时常遇到的异常：
&&&&&& an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
net.sf.hibernate.AssertionFailure: possible
nonthreadsafe access to session
其实这个异常一般都是和我们在操作session flush方法和提交事务过程中会抛出的，下面就具体结合session的事务和声明周期来具体分析下，为什么会有这样的异常；
首先来看下，session的生命周期
Hibernate中java对象的三种状态：
1、临时状态（transient）：用new语句创建，还没有被持久化，不处于Session的缓存中。&
2、持久化状态（persistent）：已使用save()或者saveOrUpdate()方法，处于Session的缓存中和数据库表中，生成了自己的Oid标识。&
3、游离状态（detached）：被持久化，已使用evict(Object)，session.close()或者使用clear()清除缓存，不再处于Session的缓存中或不存在数据库表中，但是依然是存在自己的OId标识。&
对象的状态转换
& & & & & & & & & & &
& & & & & & & & & & &
& & & & &&
从上面的图中我们可以很清楚的明白一个java对象在session中三种状态的转换，
然后在来看看session缓存在什么时候会被清除：
1.当应用程序调用org.hibernate.Transaction的commit()方法的时候，commit()方法先清理缓存，然后再向数据库提交事务。&
2.当应用程序显式调用Session的flush()方法的时候，其实这个方法我们几乎很少用到，因为我们一般都是在完成一个事务才去清理缓存，提交数据更改，这样我们直接提交事务就可以。
clear()和evict(Object)的区别:
从参数就可以看出，clear()是会清除整个session中的缓存，evict(Object)是将一个对象从session缓存中清除；
其实在session持久化操作和数据库中之间还有一层对象缓冲区（entityEntries）
Commit():此方法在执行后会更新对象在对象缓存区中的existsInDatabase=true；
Flush():会按save,update,delete顺序执行，把缓存中的数据flush入数据库中，并清空缓存区；
下面几个例子可以充分说明我们异常抛出的情况：
SessionFactory sf = new
Configuration().configure().buildSessionFactory() ;
Session s = sf.openSession();
Person person = new Person();
Transaction tran =
s.beginTransaction(); (1)
s.save(person); (2)（此处同样可以为update
s.evict(person); (3)
mit(); (4)
s.close();(5)
看上面的代码，再参照下我们的示例图和commit()方法，就可以很明显的发现代码问题的所在，在第四步evict()方法将cat对象从对象缓存区清除，当我们执行commit()方法后，更新对象在缓存区中状态的时候，由于已被清除，就会出现上述断言的异常；
Person person1 = new Person
person1.setName(&tom&);
s.save(person1);
person1.setName(&mary&);
s.update(person1);
Person person2 = new Person
person2.setName(&tom&);
s.save(person2);
s.flush();
其实在这里我们看这个代码的时候感觉是没问题 ，在这里我们可以参考下刚提到的flush()方法，此方法会按save,update,delete的顺序进行提交事务，所以在这里会抛出主键冲突的异常，解决的办法是在update()操作后面也加入flush();
总的来说，由于flush()的特殊处理机制，虽然不建议使用此方法，但是在一些复杂的事务处理过程中，加入此方法虽然会破坏事务的一个提交的完整性，但是可以规避一些不可预见的异常情况！
阅读(...) 评论()hibernate flush 机制 - yanbin_new - 博客园
多学习，多积累，多分享，厚积薄发。
posts - 14, comments - 64, trackbacks - 0, articles - 0
针对昨天同事遇到的hibernate的问题。算是hibernate最基本的东西。具了解，这个问题很多人遇到过，也很常见，却遇到了还经常会懵了。
为了加深印象，知其然，知其所以然。
之后单纯用原始的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入数据库，这样看起来也许不太美观，但很有效。
疑问：session.save方法，放入缓存中，SQL直接查询数据库是查不出来的。
&&&&&& flush()方法之后，会打印出执行SQL，但是数据库中，还是没有。SQL直接查询却能查出数据来。
&&&&&& 1、flush() 之后这个实体数据存放在什么地方？和save()方法一样的缓存，那SQL也应该是取不到的。
&&&&&& 2、既然flush方法之后数据没有进数据库，SQL直接查询，利用session.createSQLQuery(sql) 查询，直接查得应该不是数据库，他查询的又是什么地方？}