1. Session和事務范圍(transaction scope)
SessionFactory對象的創建代價很昂貴，它是線程安全的對象，它為所有的應用程序線程所共享。它只創建一次，通常是在應用程序啟動的時候，由一個Configuraion的實例來創建。
Session對象的創建代價比較小，是非線程安全的，對于單個請求，單個會話、單個的 工作單元而言，它只被使用一次，然后就丟棄。只有在需要的時候，一個Session對象 才會獲取一個JDBC的Connection（或一個Datasource） 對象，因此假若不使用的時候它不消費任何資源。
此外我們還要考慮數據庫事務。數據庫事務應該盡可能的短，降低數據庫中的鎖爭用。 數據庫長事務會阻止你的應用程序擴展到高的并發負載。因此，假若在用戶思考期間讓數據庫事務開著，直到整個工作單元完成才關閉這個事務，這絕不是一個好的設計。
一個操作單元(Unit of work)的范圍是多大？單個的Hibernate Session能跨越多個 數據庫事務嗎？還是一個Session的作用范圍對應一個數據庫事務的范圍？應該何時打開 Session，何時關閉Session？，你又如何劃分數據庫事務的邊界呢？
1.1 操作單元(Unit of work)
首先，別用session-per-operation這種反模式了，也就是說，在單個線程中， 不要因為一次簡單的數據庫調用，就打開和關閉一次Session！數據庫事務也是如此。 應用程序中的數據庫調用是按照計劃好的次序，分組為原子的操作單元。（注意，這也意味著，應用程 序中，在單個的SQL語句發送之后，自動事務提交(auto-commit)模式失效了。這種模式專門為SQL控制臺操作設計的。 Hibernate禁止立即自動事務提交模式，或者期望應用服務器禁止立即自動事務提交模式。）數據庫事務絕不是可有可無的，任何與數據庫之間的通訊都必須在某個事務中進行，不管你是在讀還是在寫數據。對讀數據而言，應該避免auto-commit行為，因為很多小的事務比一個清晰定義的工作單元性能差。后者也更容易維護和擴展。
在多用戶的client/server應用程序中，最常用的模式是 每個請求一個會話(session-per-request)。 在這種模式下，來自客戶端的請求被發送到服務器端（即Hibernate持久化層運行的地方），一 個新的Hibernate Session被打開，并且執行這個操作單元中所有的數據庫操作。 一旦操作完成（同時對客戶端的響應也準備就緒），session被同步，然后關閉。你也可以使用單 個數據庫事務來處理客戶端請求，在你打開Session之后啟動事務，在你關閉 Session之前提交事務。會話和請求之間的關系是一對一的關系，這種模式對 于大多數應用程序來說是很棒的。
實現才是真正的挑戰。Hibernate內置了對"當前session(current session)" 的管理，用于簡化此模式。你要做的一切就是在服務器端要處理請求的時候，開啟事務，在響應發送給客戶之前結束事務。你可以用任何方式來完成這一操作，通常的方案有ServletFilter，在service方法中進行pointcut的AOP攔截器，或者proxy/interception容器。EJB容器是實現橫切諸如EJB session bean上的事務分界，用CMT對事務進行聲明等方面的標準手段。假若你決定使用編程式的事務分界，請參考本章后面講到的Hibernate Transaction API，這對易用性和代碼可移植性都有好處。
在任何時間，任何地方，你的應用代碼可以通過簡單的調用sessionFactory.getCurrentSession()來訪問"當前session"，用于處理請求。你總是會得到當前數據庫事務范圍內的Session。在使用本地資源或JTA環境時，必須配置它，請參見第 2.5 節 “上下文相關的（Contextual）Session”。
有時，將Session和數據庫事務的邊界延伸到"展示層被渲染后"會帶來便利。有些serlvet應用程序在對請求進行處理后，有個單獨的渲染期，這種延伸對這種程序特別有用。假若你實現你自己的攔截器，把事務邊界延伸到展示層渲染結束后非常容易。然而，假若你依賴有容器管理事務的EJB，這就不太容易了，因為事務會在EJB方法返回后結束，而那是在任何展示層渲染開始之前。請訪問Hibernate網站和論壇，你可以找到Open Session in View這一模式的提示和示例。
1.1 長對話
session-per-request模式不僅僅是一個可以用來設計操作單元的有用概念。很多業務處理都需 要一系列完整的與用戶之間的交互，而這些用戶是指對數據庫有交叉訪問的用戶。在基于web的應用和企業 應用中，跨用戶交互的數據庫事務是無法接受的。考慮下面的例子：
從用戶的角度來看，我們把這個操作單元稱為長時間運行的對話（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 各有優缺點，我們在本章后面樂觀并發 控制那部分再進行討論。