1. Session和事務(wù)范圍(transaction scope)
SessionFactory對(duì)象的創(chuàng)建代價(jià)很昂貴，它是線程安全的對(duì)象，它為所有的應(yīng)用程序線程所共享。它只創(chuàng)建一次，通常是在應(yīng)用程序啟動(dòng)的時(shí)候，由一個(gè)Configuraion的實(shí)例來(lái)創(chuàng)建。
Session對(duì)象的創(chuàng)建代價(jià)比較小，是非線程安全的，對(duì)于單個(gè)請(qǐng)求，單個(gè)會(huì)話、單個(gè)的 工作單元而言，它只被使用一次，然后就丟棄。只有在需要的時(shí)候，一個(gè)Session對(duì)象 才會(huì)獲取一個(gè)JDBC的Connection（或一個(gè)Datasource） 對(duì)象，因此假若不使用的時(shí)候它不消費(fèi)任何資源。
此外我們還要考慮數(shù)據(jù)庫(kù)事務(wù)。數(shù)據(jù)庫(kù)事務(wù)應(yīng)該盡可能的短，降低數(shù)據(jù)庫(kù)中的鎖爭(zhēng)用。 數(shù)據(jù)庫(kù)長(zhǎng)事務(wù)會(huì)阻止你的應(yīng)用程序擴(kuò)展到高的并發(fā)負(fù)載。因此，假若在用戶思考期間讓數(shù)據(jù)庫(kù)事務(wù)開著，直到整個(gè)工作單元完成才關(guān)閉這個(gè)事務(wù)，這絕不是一個(gè)好的設(shè)計(jì)。
一個(gè)操作單元(Unit of work)的范圍是多大？單個(gè)的Hibernate Session能跨越多個(gè) 數(shù)據(jù)庫(kù)事務(wù)嗎？還是一個(gè)Session的作用范圍對(duì)應(yīng)一個(gè)數(shù)據(jù)庫(kù)事務(wù)的范圍？應(yīng)該何時(shí)打開 Session，何時(shí)關(guān)閉Session？，你又如何劃分?jǐn)?shù)據(jù)庫(kù)事務(wù)的邊界呢？
1.1 操作單元(Unit of work)
首先，別用session-per-operation這種反模式了，也就是說(shuō)，在單個(gè)線程中， 不要因?yàn)橐淮魏?jiǎn)單的數(shù)據(jù)庫(kù)調(diào)用，就打開和關(guān)閉一次Session！數(shù)據(jù)庫(kù)事務(wù)也是如此。 應(yīng)用程序中的數(shù)據(jù)庫(kù)調(diào)用是按照計(jì)劃好的次序，分組為原子的操作單元。（注意，這也意味著，應(yīng)用程 序中，在單個(gè)的SQL語(yǔ)句發(fā)送之后，自動(dòng)事務(wù)提交(auto-commit)模式失效了。這種模式專門為SQL控制臺(tái)操作設(shè)計(jì)的。 Hibernate禁止立即自動(dòng)事務(wù)提交模式，或者期望應(yīng)用服務(wù)器禁止立即自動(dòng)事務(wù)提交模式。）數(shù)據(jù)庫(kù)事務(wù)絕不是可有可無(wú)的，任何與數(shù)據(jù)庫(kù)之間的通訊都必須在某個(gè)事務(wù)中進(jìn)行，不管你是在讀還是在寫數(shù)據(jù)。對(duì)讀數(shù)據(jù)而言，應(yīng)該避免auto-commit行為，因?yàn)楹芏嘈〉氖聞?wù)比一個(gè)清晰定義的工作單元性能差。后者也更容易維護(hù)和擴(kuò)展。
在多用戶的client/server應(yīng)用程序中，最常用的模式是 每個(gè)請(qǐng)求一個(gè)會(huì)話(session-per-request)。 在這種模式下，來(lái)自客戶端的請(qǐng)求被發(fā)送到服務(wù)器端（即Hibernate持久化層運(yùn)行的地方），一 個(gè)新的Hibernate Session被打開，并且執(zhí)行這個(gè)操作單元中所有的數(shù)據(jù)庫(kù)操作。 一旦操作完成（同時(shí)對(duì)客戶端的響應(yīng)也準(zhǔn)備就緒），session被同步，然后關(guān)閉。你也可以使用單 個(gè)數(shù)據(jù)庫(kù)事務(wù)來(lái)處理客戶端請(qǐng)求，在你打開Session之后啟動(dòng)事務(wù)，在你關(guān)閉 Session之前提交事務(wù)。會(huì)話和請(qǐng)求之間的關(guān)系是一對(duì)一的關(guān)系，這種模式對(duì) 于大多數(shù)應(yīng)用程序來(lái)說(shuō)是很棒的。
實(shí)現(xiàn)才是真正的挑戰(zhàn)。Hibernate內(nèi)置了對(duì)"當(dāng)前session(current session)" 的管理，用于簡(jiǎn)化此模式。你要做的一切就是在服務(wù)器端要處理請(qǐng)求的時(shí)候，開啟事務(wù)，在響應(yīng)發(fā)送給客戶之前結(jié)束事務(wù)。你可以用任何方式來(lái)完成這一操作，通常的方案有ServletFilter，在service方法中進(jìn)行pointcut的AOP攔截器，或者proxy/interception容器。EJB容器是實(shí)現(xiàn)橫切諸如EJB session bean上的事務(wù)分界，用CMT對(duì)事務(wù)進(jìn)行聲明等方面的標(biāo)準(zhǔn)手段。假若你決定使用編程式的事務(wù)分界，請(qǐng)參考本章后面講到的Hibernate Transaction API，這對(duì)易用性和代碼可移植性都有好處。
在任何時(shí)間，任何地方，你的應(yīng)用代碼可以通過(guò)簡(jiǎn)單的調(diào)用sessionFactory.getCurrentSession()來(lái)訪問(wèn)"當(dāng)前session"，用于處理請(qǐng)求。你總是會(huì)得到當(dāng)前數(shù)據(jù)庫(kù)事務(wù)范圍內(nèi)的Session。在使用本地資源或JTA環(huán)境時(shí)，必須配置它，請(qǐng)參見第 2.5 節(jié) “上下文相關(guān)的（Contextual）Session”。
有時(shí)，將Session和數(shù)據(jù)庫(kù)事務(wù)的邊界延伸到"展示層被渲染后"會(huì)帶來(lái)便利。有些serlvet應(yīng)用程序在對(duì)請(qǐng)求進(jìn)行處理后，有個(gè)單獨(dú)的渲染期，這種延伸對(duì)這種程序特別有用。假若你實(shí)現(xiàn)你自己的攔截器，把事務(wù)邊界延伸到展示層渲染結(jié)束后非常容易。然而，假若你依賴有容器管理事務(wù)的EJB，這就不太容易了，因?yàn)槭聞?wù)會(huì)在EJB方法返回后結(jié)束，而那是在任何展示層渲染開始之前。請(qǐng)?jiān)L問(wèn)Hibernate網(wǎng)站和論壇，你可以找到Open Session in View這一模式的提示和示例。
1.1 長(zhǎng)對(duì)話
session-per-request模式不僅僅是一個(gè)可以用來(lái)設(shè)計(jì)操作單元的有用概念。很多業(yè)務(wù)處理都需 要一系列完整的與用戶之間的交互，而這些用戶是指對(duì)數(shù)據(jù)庫(kù)有交叉訪問(wèn)的用戶。在基于web的應(yīng)用和企業(yè) 應(yīng)用中，跨用戶交互的數(shù)據(jù)庫(kù)事務(wù)是無(wú)法接受的。考慮下面的例子：
-
在界面的第一屏，打開對(duì)話框，用戶所看到的數(shù)據(jù)是被一個(gè)特定的 Session 和數(shù)據(jù) 庫(kù)事務(wù)載入(load)的。用戶可以隨意修改對(duì)話框中的數(shù)據(jù)對(duì)象。
-
5分鐘后，用戶點(diǎn)擊“保存”，期望所做出的修改被持久化；同時(shí)他也期望自己是唯一修改這個(gè)信息的人，不會(huì)出現(xiàn) 修改沖突。
從用戶的角度來(lái)看，我們把這個(gè)操作單元稱為長(zhǎng)時(shí)間運(yùn)行的對(duì)話（conversation）,或者(or 應(yīng)用事務(wù),application transaction)。 在你的應(yīng)用程序中，可以有很多種方法來(lái)實(shí)現(xiàn)它。
頭一個(gè)幼稚的做法是，在用戶思考的過(guò)程中，保持Session和數(shù)據(jù)庫(kù)事務(wù)是打開的， 保持?jǐn)?shù)據(jù)庫(kù)鎖定，以阻止并發(fā)修改，從而保證數(shù)據(jù)庫(kù)事務(wù)隔離級(jí)別和原子操作。這種方式當(dāng)然是一個(gè)反模式， 因?yàn)殒i爭(zhēng)用會(huì)導(dǎo)致應(yīng)用程序無(wú)法擴(kuò)展并發(fā)用戶的數(shù)目。
很明顯，我們必須使用多個(gè)數(shù)據(jù)庫(kù)事務(wù)來(lái)實(shí)現(xiàn)這個(gè)對(duì)話。在這個(gè)例子中，維護(hù)業(yè)務(wù)處理的 事務(wù)隔離變成了應(yīng)用程序?qū)拥牟糠重?zé)任。一個(gè)對(duì)話通常跨越多個(gè)數(shù)據(jù)庫(kù)事務(wù)。如果僅僅只有一 個(gè)數(shù)據(jù)庫(kù)事務(wù)（最后的那個(gè)事務(wù)）保存更新過(guò)的數(shù)據(jù)，而所有其他事務(wù)只是單純的讀取數(shù)據(jù)（例如在一 個(gè)跨越多個(gè)請(qǐng)求/響應(yīng)周期的向?qū)эL(fēng)格的對(duì)話框中），那么應(yīng)用程序事務(wù)將保證其原子性。這種方式比聽 起來(lái)還要容易實(shí)現(xiàn)，特別是當(dāng)你使用了Hibernate的下述特性的時(shí)候：
-
自動(dòng)版本化 - Hibernate能夠自動(dòng)進(jìn)行樂(lè)觀并發(fā)控制 ，如果在用戶思考 的過(guò)程中發(fā)生并發(fā)修改，Hibernate能夠自動(dòng)檢測(cè)到。一般我們只在對(duì)話結(jié)束時(shí)才檢查。
-
脫管對(duì)象（Detached Objects）- 如果你決定采用前面已經(jīng)討論過(guò)的 session-per-request模式，所有載入的實(shí)例在用戶思考的過(guò)程 中都處于與Session脫離的狀態(tài)。Hibernate允許你把與Session脫離的對(duì)象重新關(guān)聯(lián)到Session 上，并且對(duì)修改進(jìn)行持久化，這種模式被稱為 session-per-request-with-detached-objects。自動(dòng)版本化被用來(lái)隔離并發(fā)修改。
-
Extended (or Long) Session - Hibernate 的Session 可以在數(shù)據(jù)庫(kù)事務(wù)提交之后和底層的JDBC連接斷開，當(dāng)一個(gè)新的客戶端請(qǐng)求到來(lái)的時(shí)候，它又重新連接上底層的 JDBC連接。這種模式被稱之為session-per-conversation，這種情況可 能會(huì)造成不必要的Session和JDBC連接的重新關(guān)聯(lián)。自動(dòng)版本化被用來(lái)隔離并發(fā)修改, Session通常不允許自動(dòng)flush,而是明確flush。
session-per-request-with-detached-objects 和 session-per-conversation 各有優(yōu)缺點(diǎn)，我們?cè)诒菊潞竺鏄?lè)觀并發(fā) 控制那部分再進(jìn)行討論。