某些情況下，你可以使用iterate()方法得到更好的性能。 這通常是你預(yù)期返回的結(jié)果在session，或二級緩存(second-level cache)中已經(jīng)存在時的情況。 如若不然，iterate()會比list()慢，而且可能簡單查詢也需要進(jìn)行多次數(shù)據(jù)庫訪問： iterate()會首先使用1條語句得到所有對象的持久化標(biāo)識(identifiers)，再根據(jù)持久化標(biāo)識執(zhí)行n條附加的select語句實例化實際的對象。

// fetch ids
Iterator iter = sess.createQuery("from eg.Qux q order by q.likeliness").iterate();
while ( iter.hasNext() ) {
Qux qux = (Qux) iter.next();  // fetch the object
// something we couldnt express in the query
if ( qux.calculateComplicatedAlgorithm() ) {
// delete the current instance
iter.remove();
// dont need to process the rest
break;
}
}

（譯注：元組(tuples)指一條結(jié)果行包含多個對象） Hibernate查詢有時返回元組(tuples)，每個元組(tuples)以數(shù)組的形式返回:

Iterator kittensAndMothers = sess.createQuery(
"select kitten, mother from Cat kitten join kitten.mother mother")
.list()
.iterator();
while ( kittensAndMothers.hasNext() ) {
Object[] tuple = (Object[]) kittensAndMothers.next();
Cat kitten  = tuple[0];
Cat mother  = tuple[1];
....
}

查詢可在select從句中指定類的屬性，甚至可以調(diào)用SQL統(tǒng)計(aggregate)函數(shù)。 屬性或統(tǒng)計結(jié)果被認(rèn)定為"標(biāo)量(Scalar)"的結(jié)果（而不是持久(persistent state)的實體）。

Iterator results = sess.createQuery(
"select cat.color, min(cat.birthdate), count(cat) from Cat cat " +
"group by cat.color")
.list()
.iterator();
while ( results.hasNext() ) {
Object[] row = results.next();
Color type = (Color) row[0];
Date oldest = (Date) row[1];
Integer count = (Integer) row[2];
.....
}

接口Query提供了對命名參數(shù)(named parameters)、JDBC風(fēng)格的問號(?)參數(shù)進(jìn)行綁定的方法。 不同于JDBC，Hibernate對參數(shù)從0開始計數(shù)。 命名參數(shù)(named parameters)在查詢字符串中是形如:name的標(biāo)識符。 命名參數(shù)(named parameters)的優(yōu)點是:

//named parameter (preferred)
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();

//positional parameter
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();

//named parameter list
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");
q.setParameterList("namesList", names);
List cats = q.list();

如果你需要指定結(jié)果集的范圍（希望返回的最大行數(shù)/或開始的行數(shù)），應(yīng)該使用Query接口提供的方法:

Query q = sess.createQuery("from DomesticCat cat");
q.setFirstResult(20);
q.setMaxResults(10);
List cats = q.list();

Hibernate 知道如何將這個有限定條件的查詢轉(zhuǎn)換成你的數(shù)據(jù)庫的原生SQL(native SQL)。

如果你的JDBC驅(qū)動支持可滾動的ResuleSet，Query接口可以使用ScrollableResults，允許你在查詢結(jié)果中靈活游走。

Query q = sess.createQuery("select cat.name, cat from DomesticCat cat " +
"order by cat.name");
ScrollableResults cats = q.scroll();
if ( cats.first() ) {
// find the first name on each page of an alphabetical list of cats by name
firstNamesOfPages = new ArrayList();
do {
String name = cats.getString(0);
firstNamesOfPages.add(name);
}
while ( cats.scroll(PAGE_SIZE) );
// Now get the first page of cats
pageOfCats = new ArrayList();
cats.beforeFirst();
int i=0;
while( ( PAGE_SIZE > i++ ) && cats.next() ) pageOfCats.add( cats.get(1) );
}
cats.close()

請注意，使用此功能需要保持?jǐn)?shù)據(jù)庫連接（以及游標(biāo)(cursor)）處于一直打開狀態(tài)。 如果你需要斷開連接使用分頁功能，請使用setMaxResult()/setFirstResult()

你可以在映射文件中定義命名查詢(named queries)。 （如果你的查詢串中包含可能被解釋為XML標(biāo)記(markup)的字符，別忘了用CDATA包裹起來。）

<query name="eg.DomesticCat.by.name.and.minimum.weight"><![CDATA[
from eg.DomesticCat as cat
where cat.name = ?
and cat.weight > ?
] ]></query>

參數(shù)綁定及執(zhí)行以編程方式(programatically)完成：

Query q = sess.getNamedQuery("eg.DomesticCat.by.name.and.minimum.weight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();

請注意實際的程序代碼與所用的查詢語言無關(guān)，你也可在元數(shù)據(jù)中定義原生SQL(native SQL)查詢， 或?qū)⒃械钠渌牟樵冋Z句放在配置文件中，這樣就可以讓Hibernate統(tǒng)一管理，達(dá)到遷移的目的。

首先，別再用session-per-operation這種反模式了，也就是說，在單個線程中， 不要因為一次簡單的數(shù)據(jù)庫調(diào)用，就打開和關(guān)閉一次Session！數(shù)據(jù)庫事務(wù)也是如此。 應(yīng)用程序中的數(shù)據(jù)庫調(diào)用是按照計劃好的次序，分組為原子的操作單元。（注意，這也意味著，應(yīng)用程 序中，在單個的SQL語句發(fā)送之后，自動事務(wù)提交(auto-commit)模式失效了。這種模式專門為SQL控制臺操作設(shè)計的。 Hibernate禁止立即自動事務(wù)提交模式，或者期望應(yīng)用服務(wù)器禁止立即自動事務(wù)提交模式。）

在多用戶的client/server應(yīng)用程序中，最常用的模式是 每個請求一個會話(session-per-request)。 在這種模式下，來自客戶端的請求被發(fā)送到服務(wù)器端（即Hibernate持久化層運行的地方），一 個新的Hibernate Session被打開，并且執(zhí)行這個操作單元中所有的數(shù)據(jù)庫操作。 一旦操作完成（同時發(fā)送到客戶端的響應(yīng)也準(zhǔn)備就緒），session被同步，然后關(guān)閉。你也可以使用單 個數(shù)據(jù)庫事務(wù)來處理客戶端請求，在你打開Session之后啟動事務(wù)，在你關(guān)閉 Session之前提交事務(wù)。會話和請求之間的關(guān)系是一對一的關(guān)系，這種模式對 于大多數(shù)應(yīng)用程序來說是很棒的。

真正的挑戰(zhàn)在于如何去實現(xiàn)這種模式：不僅Session和事務(wù)必須被正確的開始和結(jié)束， 而且他們也必須能被數(shù)據(jù)訪問操作訪問。用攔截器來實現(xiàn)操作單元的劃分，該攔截器在客戶端請求達(dá)到服 務(wù)器端的時候開始，在服務(wù)器端發(fā)送響應(yīng)（即，ServletFilter）之前結(jié)束。我們推薦 使用一個ThreadLocal 變量，把 Session綁定到處理客戶端請求的線 程上去。這種方式可以讓運行在該線程上的所有程序代碼輕松的訪問Session（就像訪問一 個靜態(tài)變量那樣）。你也可以在一個ThreadLocal 變量中保持事務(wù)上下文環(huán)境，不過這依賴 于你所選擇的數(shù)據(jù)庫事務(wù)劃分機制。這種實現(xiàn)模式被稱之為 ThreadLocal Session和 Open Session in View。你可以很容易的擴展本文前面章節(jié)展示的 HibernateUtil 輔助類來實現(xiàn)這種模式。當(dāng)然，你必須找到一種實現(xiàn)攔截器的方法，并 且可以把攔截器集成到你的應(yīng)用環(huán)境中。請參考Hibernate網(wǎng)站上面的提示和例子。

session-per-request模式不僅僅是一個可以用來設(shè)計操作單元的有用概念。很多業(yè)務(wù)處理流程都需 要一系列完整的和用戶之間的交互，即用戶對數(shù)據(jù)庫的交叉訪問。在基于web的應(yīng)用和企業(yè) 應(yīng)用中，跨用戶交互的數(shù)據(jù)庫事務(wù)是無法接受的。考慮下面的例子：

從用戶的角度來看，我們把這個操作單元稱為應(yīng)用程序長事務(wù)（application transaction）。 在你的應(yīng)用程序中，可以有很多種方法來實現(xiàn)它。

頭一個幼稚的做法是，在用戶思考的過程中，保持Session和數(shù)據(jù)庫事務(wù)是打開的， 保持?jǐn)?shù)據(jù)庫鎖定，以阻止并發(fā)修改，從而保證數(shù)據(jù)庫事務(wù)隔離級別和原子操作。這種方式當(dāng)然是一個反模式， 因為數(shù)據(jù)庫鎖定的維持會導(dǎo)致應(yīng)用程序無法擴展并發(fā)用戶的數(shù)目。

很明顯，我們必須使用多個數(shù)據(jù)庫事務(wù)來實現(xiàn)一個應(yīng)用程序事務(wù)。在這個例子中，維護業(yè)務(wù)處理流程的 事務(wù)隔離變成了應(yīng)用程序?qū)拥牟糠重?zé)任。單個應(yīng)用程序事務(wù)通常跨越多個數(shù)據(jù)庫事務(wù)。如果僅僅只有一 個數(shù)據(jù)庫事務(wù)（最后的那個事務(wù)）保存更新過的數(shù)據(jù)，而所有其他事務(wù)只是單純的讀取數(shù)據(jù)（例如在一 個跨越多個請求/響應(yīng)周期的向?qū)эL(fēng)格的對話框中），那么應(yīng)用程序事務(wù)將保證其原子性。這種方式比聽 起來還要容易實現(xiàn)，特別是當(dāng)你使用了Hibernate的下述特性的時候：

session-per-request-with-detached-objects 和 session-per-application-transaction 各有優(yōu)缺點，我們在本章后面樂觀并發(fā) 控制那部分再進(jìn)行討論。

應(yīng)用程序可能在兩個不同的Session中并發(fā)訪問同一持久化狀態(tài)，但是， 一個持久化類的實例無法在兩個 Session中共享。因此有兩種不同的標(biāo)識語義：

對于那些關(guān)聯(lián)到 特定Session （也就是在單個Session的范圍內(nèi)）上的對象來說，這 兩種標(biāo)識的語義是等價的，與數(shù)據(jù)庫標(biāo)識對應(yīng)的JVM標(biāo)識是由Hibernate來保 證的。不過，當(dāng)應(yīng)用程序在兩個不同的session中并發(fā)訪問具有同一持久化標(biāo) 識的業(yè)務(wù)對象實例的時候，這個業(yè)務(wù)對象的兩個實例事實上是不相同的（從 JVM識別來看）。這種沖突可以通過在同步和提交的時候使用自動版本化和樂 觀鎖定方法來解決。

這種方式把關(guān)于并發(fā)的頭疼問題留給了Hibernate和數(shù)據(jù)庫；由于在單個線程內(nèi)，操作單元中的對象識別不 需要代價昂貴的鎖定或其他意義上的同步，因此它同時可以提供最好的可伸縮性。只要在單個線程只持有一個 Session，應(yīng)用程序就不需要同步任何業(yè)務(wù)對象。在Session 的范圍內(nèi)，應(yīng)用程序可以放心的使用==進(jìn)行對象比較。

不過，應(yīng)用程序在Session的外面使用==進(jìn)行對象比較可能會 導(dǎo)致無法預(yù)期的結(jié)果。在一些無法預(yù)料的場合，例如，如果你把兩個脫管對象實例放進(jìn)同一個 Set的時候，就可能發(fā)生。這兩個對象實例可能有同一個數(shù)據(jù)庫標(biāo)識（也就是說， 他們代表了表的同一行數(shù)據(jù)），從JVM標(biāo)識的定義上來說，對脫管的對象而言，Hibernate無法保證他們 的的JVM標(biāo)識一致。開發(fā)人員必須覆蓋持久化類的equals()方法和 hashCode() 方法，從而實現(xiàn)自定義的對象相等語義。警告：不要使用數(shù)據(jù)庫標(biāo)識 來實現(xiàn)對象相等，應(yīng)該使用業(yè)務(wù)鍵值，由唯一的，通常不變的屬性組成。當(dāng)一個瞬時對象被持久化的時 候，它的數(shù)據(jù)庫標(biāo)識會發(fā)生改變。如果一個瞬時對象（通常也包括脫管對象實例）被放入一 個Set，改變它的hashcode會導(dǎo)致與這個Set的關(guān)系中斷。雖 然業(yè)務(wù)鍵值的屬性不象數(shù)據(jù)庫主鍵那樣穩(wěn)定不變，但是你只需要保證在同一個Set 中的對象屬性的穩(wěn)定性就足夠了。請到Hibernate網(wǎng)站去尋求這個問題更多的詳細(xì)的討論。請注意，這不是一 個有關(guān)Hibernate的問題，而僅僅是一個關(guān)于Java對象標(biāo)識和判等行為如何實現(xiàn)的問題。

決不要使用反模式session-per-user-session或者 session-per-application（當(dāng)然，這個規(guī)定幾乎沒有例外）。請注意， 下述一些問題可能也會出現(xiàn)在我們推薦的模式中，在你作出某個設(shè)計決定之前，請務(wù)必理解該模式的應(yīng)用前提。

如果Hibernat持久層運行在一個非托管環(huán)境中，數(shù)據(jù)庫連接通常由Hibernate的連接池機制 來處理。session/transaction處理方式如下所示：

//Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}

你不需要顯式flush() Session - 對commit()的調(diào)用會自動觸發(fā)session的同步。

調(diào)用 close() 標(biāo)志session的結(jié)束。 close()方法重要的暗示是，session釋放了JDBC連接。

這段Java代碼是可移植的，可以在非托管環(huán)境和JTA環(huán)境中運行。

你很可能從未在一個標(biāo)準(zhǔn)的應(yīng)用程序的業(yè)務(wù)代碼中見過這樣的用法；致命的（系統(tǒng)）異常應(yīng)該總是 在應(yīng)用程序“頂層”被捕獲。換句話說，執(zhí)行Hibernate調(diào)用的代碼（在持久層）和處理 RuntimeException異常的代碼（通常只能清理和退出應(yīng)用程序）應(yīng)該在不同 的應(yīng)用程序邏輯層。這對于你設(shè)計自己的軟件系統(tǒng)來說是一個挑戰(zhàn)，只要有可能，你就應(yīng)該使用 J2EE/EJB容器服務(wù)。異常處理將在本章稍后進(jìn)行討論。

請注意，你應(yīng)該選擇 org.hibernate.transaction.JDBCTransactionFactory (這是默認(rèn)選項).

如果你的持久層運行在一個應(yīng)用服務(wù)器中（例如，在EJB session beans的后面），Hibernate獲取 的每個數(shù)據(jù)源連接將自動成為全局JTA事務(wù)的一部分。Hibernate提供了兩種策略進(jìn)行JTA集成。

如果你使用bean管理事務(wù)（BMT），可以通過使用Hibernate的 Transaction API來告訴 應(yīng)用服務(wù)器啟動和結(jié)束BMT事務(wù)。因此，事務(wù)管理代碼和在非托管環(huán)境下是一樣的。

// BMT idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}

在CMT方式下，事務(wù)聲明是在session bean的部署描述符中，而不需要編程。 除非你設(shè)置了屬性hibernate.transaction.flush_before_completion和 hibernate.transaction.auto_close_session為true， 否則你必須自己同步和關(guān)閉Session。Hibernate可以為你自動同步和關(guān)閉 Session。你唯一要做的就是當(dāng)發(fā)生異常時進(jìn)行事務(wù)回滾。幸運的是， 在一個CMT bean中，事務(wù)回滾甚至可以由容器自動進(jìn)行，因為由session bean方法拋出的未處理的 RuntimeException異常可以通知容器設(shè)置全局事務(wù)回滾。這意味著 在CMT中，你完全無需使用Hibernate的Transaction API 。

請注意，當(dāng)你配置Hibernate事務(wù)工廠的時候，在一個BMT session bean中，你應(yīng)該選擇 org.hibernate.transaction.JTATransactionFactory，在一個 CMT session bean中選擇org.hibernate.transaction.CMTTransactionFactory。 記住，同時也要設(shè)置org.hibernate.transaction.manager_lookup_class。

如果你使用CMT環(huán)境，并且讓容器自動同步和關(guān)閉session，你可能也希望在你代碼的不同部分使用 同一個session。一般來說，在一個非托管環(huán)境中，你可以使用一個ThreadLocal 變量來持有這個session，但是單個EJB方法調(diào)用可能會在不同的線程中執(zhí)行（舉例來說，一個session bean調(diào)用另一個session bean）。如果你不想在應(yīng)用代碼中被傳遞Session對 象實例的問題困擾的話，那么SessionFactory 提供的 getCurrentSession()方法就很適合你，該方法返回一個綁定到JTA事務(wù) 上下文環(huán)境中的session實例。這也是把Hibernate集成到一個應(yīng)用程序中的最簡單的方法！這個“當(dāng) 前的”session總是可以自動同步和自動關(guān)閉（不考慮上述的屬性設(shè)置）。我們的session/transaction 管理代碼減少到如下所示：

// CMT idiom
Session sess = factory.getCurrentSession();
// do some work
...

換句話來說，在一個托管環(huán)境下，你要做的所有的事情就是調(diào)用 SessionFactory.getCurrentSession()，然后進(jìn)行你的數(shù)據(jù)訪問，把其余的工作 交給容器來做。事務(wù)在你的session bean的部署描述符中以可聲明的方式來設(shè)置。session的生命周期完全 由Hibernate來管理。

對after_statement連接釋放方式有一個警告。因為JTA規(guī)范的一個很愚蠢的限制，Hibernate不可能自動清理任何未關(guān)閉的ScrollableResults 或者Iterator，它們是由scroll()或iterate()產(chǎn)生的。你must通過在finally塊中，顯式調(diào)用ScrollableResults.close()或者Hibernate.close(Iterator)方法來釋放底層數(shù)據(jù)庫游標(biāo)。(當(dāng)然，大部分程序完全可以很容易的避免在CMT代碼中出現(xiàn)scroll()或iterate()。)

如果 Session 拋出異常 (包括任何SQLException), 你應(yīng)該立即回滾數(shù)據(jù)庫事務(wù)，調(diào)用 Session.close() ，丟棄該 Session實例。Session的某些方法可能會導(dǎo)致session 處于不一致的狀態(tài)。所有由Hibernate拋出的異常都視為不可以恢復(fù)的。確保在 finally 代碼塊中調(diào)用close()方法，以關(guān)閉掉 Session。

HibernateException是一個非檢查期異常（這不同于Hibernate老的版本）， 它封裝了Hibernate持久層可能出現(xiàn)的大多數(shù)錯誤。我們的觀點是，不應(yīng)該強迫應(yīng)用程序開發(fā)人員 在底層捕獲無法恢復(fù)的異常。在大多數(shù)軟件系統(tǒng)中，非檢查期異常和致命異常都是在相應(yīng)方法調(diào)用 的堆棧的頂層被處理的（也就是說，在軟件上面的邏輯層），并且提供一個錯誤信息給應(yīng)用軟件的用戶 （或者采取其他某些相應(yīng)的操作）。請注意，Hibernate也有可能拋出其他并不屬于 HibernateException的非檢查期異常。這些異常同樣也是無法恢復(fù)的，應(yīng)該 采取某些相應(yīng)的操作去處理。

在和數(shù)據(jù)庫進(jìn)行交互時，Hibernate把捕獲的SQLException封裝為Hibernate的 JDBCException。事實上，Hibernate嘗試把異常轉(zhuǎn)換為更有實際含義 的JDBCException異常的子類。底層的SQLException可以 通過JDBCException.getCause()來得到。Hibernate通過使用關(guān)聯(lián)到 SessionFactory上的SQLExceptionConverter來 把SQLException轉(zhuǎn)換為一個對應(yīng)的JDBCException 異常的子類。默認(rèn)情況下，SQLExceptionConverter可以通過配置dialect 選項指定；此外，也可以使用用戶自定義的實現(xiàn)類（參考javadocs SQLExceptionConverterFactory類來了解詳情）。標(biāo)準(zhǔn)的 JDBCException子類型是：

未能充分利用Hibernate功能的實現(xiàn)代碼中，每次和數(shù)據(jù)庫交互都需要一個新的 Session，而且開發(fā)人員必須在顯示數(shù)據(jù)之前從數(shù)據(jù)庫中重 新載入所有的持久化對象實例。這種方式迫使應(yīng)用程序自己實現(xiàn)版本檢查來確保 應(yīng)用程序事務(wù)的隔離，從數(shù)據(jù)訪問的角度來說是最低效的。這種使用方式和 entity EJB最相似。

// foo is an instance loaded by a previous Session
session = factory.openSession();
Transaction t = session.beginTransaction();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() ); // load the current state
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
t.commit();
session.close();

version 屬性使用 <version>來映射，如果對象 是臟數(shù)據(jù)，在同步的時候，Hibernate會自動增加版本號。

當(dāng)然，如果你的應(yīng)用是在一個低數(shù)據(jù)并發(fā)環(huán)境下，并不需要版本檢查的話，你照樣可以使用 這種方式，只不過跳過版本檢查就是了。在這種情況下，最晚提交生效 （last commit wins）就是你的應(yīng)用程序長事務(wù)的默認(rèn)處理策略。 請記住這種策略可能會讓應(yīng)用軟件的用戶感到困惑，因為他們有可能會碰上更新丟失掉卻沒 有出錯信息，或者需要合并更改沖突的情況。

很明顯，手工進(jìn)行版本檢查只適合于某些軟件規(guī)模非常小的應(yīng)用場景，對于大多數(shù)軟件應(yīng)用場景 來說并不現(xiàn)實。通常情況下，不僅是單個對象實例需要進(jìn)行版本檢查，整個被修改過的關(guān) 聯(lián)對象圖也都需要進(jìn)行版本檢查。作為標(biāo)準(zhǔn)設(shè)計范例，Hibernate使用長生命周期 Session的方式，或者脫管對象實例的方式來提供自動版本檢查。

單個 Session實例和它所關(guān)聯(lián)的所有持久化對象實例都被用于整個 應(yīng)用程序事務(wù)。Hibernate在同步的時候進(jìn)行對象實例的版本檢查，如果檢測到并發(fā)修 改則拋出異常。由開發(fā)人員來決定是否需要捕獲和處理這個異常（通常的抉擇是給用戶 提供一個合并更改，或者在無臟數(shù)據(jù)情況下重新進(jìn)行業(yè)務(wù)操作的機會）。

在等待用戶交互的時候， Session 斷開底層的JDBC連接。這種方式 以數(shù)據(jù)庫訪問的角度來說是最高效的方式。應(yīng)用程序不需要關(guān)心版本檢查或脫管對象實例 的重新關(guān)聯(lián)，在每個數(shù)據(jù)庫事務(wù)中，應(yīng)用程序也不需要載入讀取對象實例。

// foo is an instance loaded earlier by the Session
session.reconnect(); // Obtain a new JDBC connection
Transaction t = session.beginTransaction();
foo.setProperty("bar");
t.commit(); // End database transaction, flushing the change and checking the version
session.disconnect(); // Return JDBC connection 

foo 對象始終和載入它的Session相關(guān)聯(lián)。 Session.reconnect()獲取一個新的數(shù)據(jù)庫連接（或者 你可以提供一個），并且繼續(xù)當(dāng)前的session。Session.disconnect() 方法把session與JDBC連接斷開，把數(shù)據(jù)庫連接返回到連接池（除非是你自己提供的數(shù)據(jù) 庫連接）。在Session重新連接上數(shù)據(jù)庫連接之后，你可以對任何可能被其他事務(wù)更新過 的對象調(diào)用Session.lock()，設(shè)置LockMode.READ 鎖定模式，這樣你就可以對那些你不準(zhǔn)備更新的數(shù)據(jù)進(jìn)行強制版本檢查。此外，你并不需要 鎖定那些你準(zhǔn)備更新的數(shù)據(jù)。

假若對disconnect()和reconnect()的顯式調(diào)用發(fā)生得太頻繁了，你可以使用hibernate.connection.release_mode來代替。

如果在用戶思考的過程中，Session因為太大了而不能保存，那么這種模式是有 問題的。舉例來說，一個HttpSession應(yīng)該盡可能的小。由于 Session是一級緩存，并且保持了所有被載入過的對象，因此 我們只應(yīng)該在那些少量的request/response情況下使用這種策略。而且在這種情況下， Session 里面很快就會有臟數(shù)據(jù)出現(xiàn)，因此請牢牢記住這一建議。

此外，也請注意，你應(yīng)該讓與數(shù)據(jù)庫連接斷開的Session對持久層保持 關(guān)閉狀態(tài)。換句話說，使用有狀態(tài)的EJB session bean來持有Session， 而不要把它傳遞到web層（甚至把它序列化到一個單獨的層），保存在HttpSession中。

這種方式下，與持久化存儲的每次交互都發(fā)生在一個新的Session中。 然而，同一持久化對象實例可以在多次與數(shù)據(jù)庫的交互中重用。應(yīng)用程序操縱脫管對象實例 的狀態(tài)，這個脫管對象實例最初是在另一個Session 中載入的，然后 調(diào)用 Session.update()，Session.saveOrUpdate(), 或者 Session.merge() 來重新關(guān)聯(lián)該對象實例。

// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
Transaction t = session.beginTransaction();
session.saveOrUpdate(foo); // Use merge() if "foo" might have been loaded already
t.commit();
session.close();

Hibernate會再一次在同步的時候檢查對象實例的版本，如果發(fā)生更新沖突，就拋出異常。

如果你確信對象沒有被修改過，你也可以調(diào)用lock() 來設(shè)置 LockMode.READ（繞過所有的緩存，執(zhí)行版本檢查），從而取 代 update()操作。

對于特定的屬性和集合，通過為它們設(shè)置映射屬性optimistic-lock的值 為false，來禁止Hibernate的版本自動增加。這樣的話，如果該屬性 臟數(shù)據(jù)，Hibernate將不再增加版本號。

遺留系統(tǒng)的數(shù)據(jù)庫Schema通常是靜態(tài)的，不可修改的。或者，其他應(yīng)用程序也可能訪問同一數(shù)據(jù) 庫，根本無法得知如何處理版本號，甚至?xí)r間戳。在以上的所有場景中，實現(xiàn)版本化不能依靠 數(shù)據(jù)庫表的某個特定列。在<class>的映射中設(shè)置 optimistic-lock="all"可以在沒有版本或者時間戳屬性映射的情況下實現(xiàn) 版本檢查，此時Hibernate將比較一行記錄的每個字段的狀態(tài)。請注意，只有當(dāng)Hibernate能夠比 較新舊狀態(tài)的情況下，這種方式才能生效，也就是說， 你必須使用單個長生命周期Session模式，而不能使用 session-per-request-with-detached-objects模式。

有些情況下，只要更改不發(fā)生交錯，并發(fā)修改也是允許的。當(dāng)你在<class> 的映射中設(shè)置optimistic-lock="dirty"，Hibernate在同步的時候?qū)⒅槐容^有臟 數(shù)據(jù)的字段。

在以上所有場景中，不管是專門設(shè)置一個版本/時間戳列，還是進(jìn)行全部字段/臟數(shù)據(jù)字段比較， Hibernate都會針對每個實體對象發(fā)送一條UPDATE（帶有相應(yīng)的 WHERE語句 ）的SQL語句來執(zhí)行版本檢查和數(shù)據(jù)更新。如果你對關(guān)聯(lián)實體 設(shè)置級聯(lián)關(guān)系使用傳播性持久化（transitive persistence），那么Hibernate可能會執(zhí)行不必 要的update語句。這通常不是個問題，但是數(shù)據(jù)庫里面對on update點火 的觸發(fā)器可能在脫管對象沒有任何更改的情況下被觸發(fā)。因此，你可以在 <class>的映射中，通過設(shè)置select-before-update="true" 來定制這一行為，強制Hibernate SELECT這個對象實例，從而保證， 在更新記錄之前，對象的確是被修改過。

Interceptor接口提供了從會話(session)回調(diào)(callback)應(yīng)用程序(application)的機制， 這種回調(diào)機制可以允許應(yīng)用程序在持久化對象被保存、更新、刪除或是加載之前，檢查并（或）修改其 屬性。一個可能的用途，就是用來跟蹤審核(auditing)信息。例如：下面的這個攔截器，會在一個實現(xiàn)了 Auditable接口的對象被創(chuàng)建時自動地設(shè)置createTimestamp屬性，并在實現(xiàn)了 Auditable接口的對象被更新時，同步更新lastUpdateTimestamp屬性。

package org.hibernate.test;
import java.io.Serializable;
import java.util.Date;
import java.util.Iterator;
import org.hibernate.Interceptor;
import org.hibernate.type.Type;
public class AuditInterceptor implements Interceptor, Serializable {
private int updates;
private int creates;
public void onDelete(Object entity,
Serializable id,
Object[] state,
String[] propertyNames,
Type[] types) {
// do nothing
}
public boolean onFlushDirty(Object entity,
Serializable id,
Object[] currentState,
Object[] previousState,
String[] propertyNames,
Type[] types) {
if ( entity instanceof Auditable ) {
updates++;
for ( int i=0; i < propertyNames.length; i++ ) {
if ( "lastUpdateTimestamp".equals( propertyNames[i] ) ) {
currentState[i] = new Date();
return true;
}
}
}
return false;
}
public boolean onLoad(Object entity,
Serializable id,
Object[] state,
String[] propertyNames,
Type[] types) {
return false;
}
public boolean onSave(Object entity,
Serializable id,
Object[] state,
String[] propertyNames,
Type[] types) {
if ( entity instanceof Auditable ) {
creates++;
for ( int i=0; i<propertyNames.length; i++ ) {
if ( "createTimestamp".equals( propertyNames[i] ) ) {
state[i] = new Date();
return true;
}
}
}
return false;
}
public void postFlush(Iterator entities) {
System.out.println("Creations: " + creates + ", Updates: " + updates);
}
public void preFlush(Iterator entities) {
updates=0;
creates=0;
}
...
}

創(chuàng)建會話(session)的時候可以指定攔截器。

Session session = sf.openSession( new AuditInterceptor() );

你也可以使用Configuration來設(shè)置一個全局范圍的攔截器。

new Configuration().setInterceptor( new AuditInterceptor() );

如果需要響應(yīng)持久層的某些特殊事件，你也可以使用Hibernate3的事件框架。 該事件系統(tǒng)可以用來替代攔截器，也可以作為攔截器的補充來使用。

基本上，Session接口的每個方法都有相對應(yīng)的事件。比如 LoadEvent，FlushEvent，等等（查閱XML配置文件 的DTD，以及org.hibernate.event包來獲得所有已定義的事件的列表）。當(dāng)某個方 法被調(diào)用時，Hibernate Session會生成一個相對應(yīng)的事件并激活所 有配置好的事件監(jiān)聽器。系統(tǒng)預(yù)設(shè)的監(jiān)聽器實現(xiàn)的處理過程就是被監(jiān)聽的方法要做的（被監(jiān)聽的方法所做的其實僅僅是激活監(jiān)聽器， “實際”的工作是由監(jiān)聽器完成的）。不過，你可以自由地選擇實現(xiàn) 一個自己定制的監(jiān)聽器（比如，實現(xiàn)并注冊用來處理處理LoadEvent的LoadEventListener接口）， 來負(fù)責(zé)處理所有的調(diào)用Session的load()方法的請求。

監(jiān)聽器應(yīng)該被看作是單例(singleton)對象，也就是說，所有同類型的事件的處理共享同一個監(jiān)聽器實例，因此監(jiān)聽器 不應(yīng)該保存任何狀態(tài)（也就是不應(yīng)該使用成員變量）。

用戶定制的監(jiān)聽器應(yīng)該實現(xiàn)與所要處理的事件相對應(yīng)的接口，或者從一個合適的基類繼承（甚至是從Hibernate自帶的默認(rèn)事件監(jiān)聽器類繼承， 為了方便你這樣做，這些類都被聲明成non-final的了）。用戶定制的監(jiān)聽器可以通過編程使用Configuration對象 來注冊，也可以在Hibernate的XML格式的配置文件中進(jìn)行聲明（不支持在Properties格式的配置文件聲明監(jiān)聽器）。 下面是一個用戶定制的加載事件(load event)的監(jiān)聽器：

public class MyLoadListener extends DefaultLoadEventListener {
// this is the single method defined by the LoadEventListener interface
public Object onLoad(LoadEvent event, LoadEventListener.LoadType loadType)
throws HibernateException {
if ( !MySecurity.isAuthorized( event.getEntityClassName(), event.getEntityId() ) ) {
throw MySecurityException("Unauthorized access");
}
return super.onLoad(event, loadType);
}
}

你還需要修改一處配置，來告訴Hibernate以使用選定的監(jiān)聽器來替代默認(rèn)的監(jiān)聽器。

<hibernate-configuration>
<session-factory>
...
<listener type="load" class="MyLoadListener"/>
</session-factory>
</hibernate-configuration>

看看用另一種方式，通過編程的方式來注冊它。

Configuration cfg = new Configuration();
cfg.getSessionEventListenerConfig().setLoadEventListener( new MyLoadListener() );

通過在XML配置文件聲明而注冊的監(jiān)聽器不能共享實例。如果在多個<listener/>節(jié)點中使用 了相同的類的名字，則每一個引用都將會產(chǎn)生一個獨立的實例。如果你需要在多個監(jiān)聽器類型之間共享 監(jiān)聽器的實例，則你必須使用編程的方式來進(jìn)行注冊。

為什么我們實現(xiàn)了特定監(jiān)聽器的接口，在注冊的時候還要明確指出我們要注冊哪個事件的監(jiān)聽器呢？ 這是因為一個類可能實現(xiàn)多個監(jiān)聽器的接口。在注冊的時候明確指定要監(jiān)聽的事件，可以讓啟用或者禁用對某個事件的監(jiān)聽的配置工作簡單些。

通常，Hibernate應(yīng)用程序的聲明式安全機制由會話外觀層(session facade)所管理。 現(xiàn)在，Hibernate3允許某些特定的行為由JACC進(jìn)行許可管理，由JAAS進(jìn)行授權(quán)管理。 本功能是一個建立在事件框架之上的可選的功能。

首先，你必須要配置適當(dāng)?shù)氖录O(jiān)聽器（event listener），來激活使用JAAS管理授權(quán)的功能。

<listener type="pre-delete" class="org.hibernate.secure.JACCPreDeleteEventListener"/>
<listener type="pre-update" class="org.hibernate.secure.JACCPreUpdateEventListener"/>
<listener type="pre-insert" class="org.hibernate.secure.JACCPreInsertEventListener"/>
<listener type="pre-load" class="org.hibernate.secure.JACCPreLoadEventListener"/>

接下來，仍然在hibernate.cfg.xml文件中，綁定角色的權(quán)限：

<grant role="admin" entity-name="User" actions="insert,update,read"/>
<grant role="su" entity-name="User" actions="*"/>

這些角色的名字就是你的JACC provider所定義的角色的名字。