關於在使用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 delete）
s.evict(person); (3)
tran.commit(); (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()的特殊處理機制，雖然不建議使用此方法，但是在一些復雜的事務處理過程中，加入此方法雖然會破壞事務的一個提交的完整性，但是可以規避一些不可預見的異常情況！