# 11.3.2\. 擴展周期的session和自動版本化 單個 `Session`實例和它所關聯的所有持久化對象實例都被用于整個 對話，這被稱為_session-per-conversation_。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以獲得示例。