臟檢查 Session到底是如何進行臟檢查的呢？當一個Customer對象被加入到Session緩存中時，Session會為Customer對象的值類型的屬性複製一份快照。當Session清理緩存時，會先進行臟檢查，即比較Customer對象的當前屬性與它的快照，來判斷Customer對象的屬性是否 ...
臟檢查
Session到底是如何進行臟檢查的呢？當一個Customer對象被加入到Session緩存中時，Session會為Customer對象的值類型的屬性複製一份快照。當Session清理緩存時，會先進行臟檢查，即比較Customer對象的當前屬性與它的快照，來判斷Customer對象的屬性是否發生了變化，如果發生了變化，就稱這個對象是“臟對象”，Session會根據臟對象的最新屬性來執行相關的SQL語句，從而同步更新資料庫。
臟數據檢查：
什麼是臟數據？臟數據並不是廢棄和無用的數據，而是狀態前後發生變化的數據。我們看下麵的代碼：
Transaction tx=session.beginTransaction();
User user=(User)session.load(User.class,”1”);//從資料庫中載入符合條件的數據
user.setName(“zz”);//改變了user對象的姓名屬性，此時user對象成為了所謂的“臟數據”
tx.commit();
當事務提交時，Hibernate會對session中的PO(持久化對象)進行檢測，判斷持久化對象的狀態是否發生了改變，如果發生了改變就會將改變更新到資料庫中。這裡就存在一個問題，Hibernate如何來判斷一個實體對象的狀態前後是否發生了變化。也就是說Hibernate是如何檢查出一個數據已經變髒了。
通常臟數據的檢查有如下兩種辦法：
A、數據對象監控：
數據對象監控是通過攔截器對數據對象的setter方法進行監控來實現的，這類似於資料庫中的觸發器的概念，當某一個對象的屬性調用了setter方法而發生了改變，這時攔截器會捕獲這個動作，並且將改屬性標誌為已經改變，在之後的資料庫操作時將其更新到資料庫中。這個方法的優點是提高了數據更新的同步性，但是這也是它的缺點，如果一個實體對象有很多屬性發生了改變，勢必造成大量攔截器回調方法的調用，這些攔截器都是通過Dynamic Proxy或者CGLIB實現的，在執行時都會付出一定的執行代價，所以有可能造成更新操作的較大延時。
B、數據版本比對:
這種方法是在持久化框架中保存數據對象的最近讀取版本，當提交數據時將提交的數據與這個保存的版本進行比對，如果發現發生了變化則將其同步跟新到資料庫中。這種方法降低了同步更新的實時性，但是當一個數據對象的很多屬性發生改變時，由於持久層框架緩存的存在，比對版本時可以充分利用緩存，這反而減少了更新數據的延遲。
在Hibernate中是採用數據版本比對的方法來進行臟數據檢查的，我們結合下麵的代碼來講解Hibernate的具體實現策略。
Transaction tx=session.beginTransaction();
User user=(User)session.load(User.class,”1”);
user.setName(“zz”);
tx.commit();
當調用tx.commit();時好戲就此開場，commit()方法會調用session.flush()方法，在調用flush()方法時，會首先調用flushEverything()來進行一些預處理（如調用intercepter,完成級聯操作等），然後調用flushEntities()方法，這個方法是進行臟數據檢查的關鍵。
在繼續講解之前，我要先來介紹一個內部數據結構EntityEntry,EntityEntry是從屬於SessionImpl(Session介面的實現類)的內部類，每一個EntityEntry保存了最近一次與資料庫同步的實體原始狀態信息（如：實體的版本信息，實體的加鎖模式，實體的屬性信息等）。除了EntityEntry結構之外，還存在一個結構，這個結構稱為EntityEntries，它也是SessionImpl的內部類，而且是一個Map類型，它以”key-value”的形式保存了所有與當前session實例相關聯的實體對象和原始狀態信息，其中key是實體對象，value是EntityEntry。而flushEntities()的工作就是遍歷entityEntities,並將其中的實體對象與原始版本進行對比，判斷實體對象是否發生來了改變。flushEntities()首先會判斷實體的ID是否發生了改變，如果發生了改變則認為發生了異常，因為當前實體與EntityEntry的對應關係非法。如果沒有發生異常，而且經過版本比對判斷確實實體屬性發生了改變，則向當前的更新任務隊列中加入一個新的更新任務，此任務將在將在session.flush()方法中的execute()方法的調用中，轉化為相應的SQL語句交由資料庫去執行。最後Transaction將會調用當前session對應的JDBC Connection的commit()方法將當前事務提交。
臟數據檢查是發生在顯示保存實體對象時，所謂顯示保存是指在代碼中明確使用session調用save,update,saveOrupdate方法對實體對象進行保存，如：session.save(user);但是有時候由於級聯操作的存在，會產生一個問題，比如當保存一個user對象時，會根據user對象的狀態來對他所關聯的address對象進行保存，但是此時並沒有根據級聯對象的顯示保存語句。此時需要Hibernate能根據當前對象的狀態來判斷是否要將級聯對象保存到資料庫中。此時，Hibernate會根據unsaved-value進行判斷。Hibernate將首先取出目標對象的ID，然後將ID與unsaved-value值進行比較，如果相等，則認為實體對象尚未保存，進而馬上將進行保存，否則，則認為實體對象已經保存，而無須再次進行保存。比如，當向一個user對象新加入一個它所關聯的address對象後，當進行session.save(user)時，Hibernate會根據unsaved-value的值判斷出哪個address對象需要保存，對於新加入的address對象它的id尚未賦值，以此為null，與unsaved-value值相等，因此Hibernate會將其視為未保存對象，生成insert語句加以保存。如果想使用unsaved-value必須如下配置address對象的id屬性：
……
<id name=”id” type=”java.lang.Integer” unsaved-value=”null”>
<generator class=”increment”/>
</id>
……
緩存清理機制
當Session緩存中對象的屬性每次發生了變化，Session並不會立即清理緩存和執行相關的SQL update語句，而是在特定的時間點才清理緩存，這使得Session能夠把幾條相關的SQL語句合併為一條SQL語句，一遍減少訪問資料庫的次數，從而提高應用程式的數據訪問性能。
在預設情況下，Session會在以下時間點清理緩存。
- 當應用程式調用org.hibernate.Transaction的commit()方法的時候.commit方法先清理緩存，然後再向資料庫提交事務。Hibernate之所以把清理緩存的時間點安排在事務快結束時，一方面是因為可以減少訪問資料庫的頻率，還有一方面是因為可以儘可能縮短當前事務對資料庫中相關資源的鎖定時間。
- 當應用程式執行一些查詢操作時，如果緩存中持久化對象的屬性已經發生了變化，就會清理緩存，使得Session緩存與資料庫已經進行了同步，從而保證查詢結果返回的是正確的數據。
- 當應用程式顯示調用Session的flush()方法的時候。
Session進行清理緩存的例外情況是，如果對象使用native生成器來生成OID，那麼當調用Session的save()方法保存該對象時，會立即執行向資料庫插入該實體的insert語句。
