Hibernate的事務和並發控制很容易掌握。Hibernate直接使用JDBC連接和JTA資源，不添加任何附加鎖定 行為。我們強烈推薦你花點時間了解JDBC編程，ANSI SQL查詢語言和你使用 的數據庫系統的事務隔離規范。Hibernate只添加自動版本管理，而不會鎖 定內存中的對象，也不會改變數據庫事務的隔離級別。基本上，使用 Hibernate就好像直接使用JDBC(或者JTA/CMT)來訪問你的數據庫資源。
除了自動版本管理，針對行級悲觀鎖定，Hibernate也提供了輔助的API，它使用了 SELECT FOR UPDATE的SQL語法。本章後面會討論這個API。
我們從Configuration層、SessionFactory層, 和 Session層開始討論Hibernate的並行控制、數據庫事務和應用 程序的長事務。
12.1.Session和事務范圍(transaction scopes)
一個SessionFactory對象的創建代價很昂貴，它是線程安全的對象，它被設計成可以 為所有的應用程序線程所共享。它只創建一次，通常是在應用程序啟動的時候，由一個 Configuraion的實例來創建。
一個Session的對象是輕型的，非線程安全的，對於單個業務進程，單個的 工作單元而言，它只被使用一次，然後就丟棄。只有在需要的時候，Session 才會獲取一個JDBC的Connection（或一個Datasource） 對象。所以你可以放心的打開和關閉Session，甚至當你並不確定一個特定的請 求是否需要數據訪問時，你也可以這樣做。(一旦你實現下面提到的使用了請求攔截的模式，這就 變得很重要了。
此外我們還要考慮數據庫事務。數據庫事務應該盡可能的短，降低數據庫鎖定造成的資源爭用。 數據庫長事務會導致你的應用程序無法擴展到高的並發負載。
一個操作單元(Unit of work)的范圍是多大？單個的Hibernate Session能跨越多個 數據庫事務嗎？還是一個Session的作用范圍對應一個數據庫事務的范圍？應該何時打開 Session，何時關閉Session？，你又如何劃分數據庫事務的邊界呢？
12.1.1.操作單元(Unit of work)
首先，別再用session-per-operation這種反模式了，也就是說，在單個線程中， 不要因為一次簡單的數據庫調用，就打開和關閉一次Session！數據庫事務也是如此。 應用程序中的數據庫調用是按照計劃好的次序，分組為原子的操作單元。（注意，這也意味著，應用程 序中，在單個的SQL語句發送之後，自動事務提交(auto-commit)模式失效了。這種模式專門為SQL控制台操作設計的。 Hibernate禁止立即自動事務提交模式，或者期望應用服務器禁止立即自動事務提交模式。）
在多用戶的client/server應用程序中，最常用的模式是 每個請求一個會話(session-per-request)。 在這種模式下，來自客戶端的請求被發送到服務器端（即Hibernate持久化層運行的地方），一 個新的Hibernate Session被打開，並且執行這個操作單元中所有的數據庫操作。 一旦操作完成（同時發送到客戶端的響應也准備就緒），session被同步，然後關閉。你也可以使用單 個數據庫事務來處理客戶端請求，在你打開Session之後啟動事務，在你關閉 Session之前提交事務。會話和請求之間的關系是一對一的關系，這種模式對 於大多數應用程序來說是很棒的。
真正的挑戰在於如何去實現這種模式：不僅Session和事務必須被正確的開始和結束， 而且他們也必須能被數據訪問操作訪問。用攔截器來實現操作單元的劃分，該攔截器在客戶端請求達到服 務器端的時候開始，在服務器端發送響應（即，ServletFilter）之前結束。我們推薦 使用一個ThreadLocal 變量，把 Session綁定到處理客戶端請求的線 程上去。這種方式可以讓運行在該線程上的所有程序代碼輕松的訪問Session（就像訪問一 個靜態變量那樣）。你也可以在一個ThreadLocal 變量中保持事務上下文環境，不過這依賴 於你所選擇的數據庫事務劃分機制。這種實現模式被稱之為 ThreadLocal Session和 Open Session in View。你可以很容易的擴展本文前面章節展示的 HibernateUtil 輔助類來實現這種模式。當然，你必須找到一種實現攔截器的方法，並 且可以把攔截器集成到你的應用環境中。請參考Hibernate網站上面的提示和例子。
12.1.2.應用程序事務(Application transactions)
session-per-request模式不僅僅是一個可以用來設計操作單元的有用概念。很多業務處理流程都需 要一系列完整的和用戶之間的交互，即用戶對數據庫的交叉訪問。在基於web的應用和企業 應用中，跨用戶交互的數據庫事務是無法接受的。考慮下面的例子：
