Hibernate擴展周期的Session和自動版本化
今天我們主要介紹擴展周期的Hibernate session和自動版本化，望讀者能夠加以借鑒。
單個Hibernate Session實例和它所關聯的所有持久化對象實例都被用于整個對話，這被稱為session-per-conversation。Hibernate在同步的時候進行對象實例的版本檢查，如果檢測到并發修 改則拋出異常。由開發人員來決定是否需要捕獲和處理這個異常（通常的抉擇是給用戶 提供一個合并更改，或者在無臟數據情況下重新進行業務對話的機會）。
在等待用戶交互的時候，Hibernate Session 斷開底層的JDBC連接。這種方式 以數據庫訪問的角度來說是***效的方式。應用程序不需要關心版本檢查或脫管對象實例 的重新關聯，在每個數據庫事務中，應用程序也不需要載入讀取對象實例。
- // foo is an instance loaded earlier by the old session
- Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction
- foo.setProperty("bar");
- session.flush(); // Only for last transaction in conversation
- t.commit(); // Also return JDBC connection
- session.close(); // Only for last transaction in conversation
foo對象知道它是在哪個Session中被裝入的。在一個舊session中開啟一個新的數據庫事務，會導致session獲取一個新的連接，并恢復session的功能。
將數據庫事務提交，使得session從JDBC連接斷開，并將此連接交還給連接池。在重新連接之后，要強制對你沒有更新的數據進行一次版本檢查，你可以對所有可能被其他事務修改過的對象，使用參數LockMode.READ來調用Session.lock()。你不用lock任何你正在更新的數據。
一般你會在擴展的Session上設置FlushMode.NEVER，因此只有***一個數據庫事務循環才會真正的吧整個對話中發生的修改發送到數據庫。因此，只有這***一次數據庫事務才會包含flush()操作，然后在整個對話結束后，還要close()這個session。
如果在用戶思考的過程中，Session因為太大了而不能保存，那么這種模式是有 問題的。舉例來說，一個HttpSession應該盡可能的小。
由于 Session是一級緩存，并且保持了所有被載入過的對象，因此 我們只應該在那些少量的request/response情況下使用這種策略。你應該只把一個Session用于單個對話，因為它很快就會出現臟數據。
注意：
早期的Hibernate版本需要明確的對Session進行disconnec和reconnect。這些方法現在已經過時了，打開事務和關閉事務會起到同樣的效果。
此外，也請注意，你應該讓與數據庫連接斷開的Session對持久層保持 關閉狀態。換句話說，在三層環境中，使用有狀態的EJB session bean來持有Session， 而不要把它傳遞到web層（甚至把它序列化到一個單獨的層），保存在HttpSession中。
擴展session模式，或者被稱為每次對話一個session(session-per-conversation), 在與自動管理當前session上下文聯用的時候會更困難。你需要提供你自己的CurrentSessionContext實現。請參閱Hibernate Wiki以獲得示例。
【編輯推薦】
