# 11.1.2\. 長對話 session-per-request模式不僅僅是一個可以用來設計操作單元的有用概念。很多業務處理都需 要一系列完整的與用戶之間的交互，而這些用戶是指對數據庫有交叉訪問的用戶。在基于web的應用和企業 應用中，跨用戶交互的數據庫事務是無法接受的。考慮下面的例子： * 在界面的第一屏，打開對話框，用戶所看到的數據是被一個特定的 `Session` 和數據 庫事務載入(load)的。用戶可以隨意修改對話框中的數據對象。 * 5分鐘后，用戶點擊“保存”，期望所做出的修改被持久化；同時他也期望自己是唯一修改這個信息的人，不會出現 修改沖突。 從用戶的角度來看，我們把這個操作單元稱為長時間運行的_對話_（conversation）,或者(or _應用事務_,application transaction)。 在你的應用程序中，可以有很多種方法來實現它。 頭一個幼稚的做法是，在用戶思考的過程中，保持`Session`和數據庫事務是打開的， 保持數據庫鎖定，以阻止并發修改，從而保證數據庫事務隔離級別和原子操作。這種方式當然是一個反模式， 因為鎖爭用會導致應用程序無法擴展并發用戶的數目。 很明顯，我們必須使用多個數據庫事務來實現這個對話。在這個例子中，維護業務處理的 事務隔離變成了應用程序層的部分責任。一個對話通常跨越多個數據庫事務。如果僅僅只有一 個數據庫事務（最后的那個事務）保存更新過的數據，而所有其他事務只是單純的讀取數據（例如在一 個跨越多個請求/響應周期的向導風格的對話框中），那么應用程序事務將保證其原子性。這種方式比聽 起來還要容易實現，特別是當你使用了Hibernate的下述特性的時候： * _自動版本化_ - Hibernate能夠自動進行樂觀并發控制 ，如果在用戶思考 的過程中發生并發修改，Hibernate能夠自動檢測到。一般我們只在對話結束時才檢查。 * _脫管對象_（Detached Objects）- 如果你決定采用前面已經討論過的 _session-per-request_模式，所有載入的實例在用戶思考的過程 中都處于與Session脫離的狀態。Hibernate允許你把與Session脫離的對象重新關聯到Session 上，并且對修改進行持久化，這種模式被稱為 _session-per-request-with-detached-objects_。自動版本化被用來隔離并發修改。 * _Extended (or Long) Session_ - Hibernate 的`Session` 可以在數據庫事務提交之后和底層的JDBC連接斷開，當一個新的客戶端請求到來的時候，它又重新連接上底層的 JDBC連接。這種模式被稱之為_session-per-conversation_，這種情況可 能會造成不必要的Session和JDBC連接的重新關聯。自動版本化被用來隔離并發修改, `Session`通常不允許自動flush,而是明確flush。 _session-per-request-with-detached-objects_ 和 _session-per-conversation_ 各有優缺點，我們在本章后面樂觀并發 控制那部分再進行討論。