某些情況下，你可以使用iterate()方法得到更好的性能。 這通常是你預期返回的結果在session，或二級緩存(second-level cache)中已經存在時的情況。 如若不然，iterate()會比list()慢，而且可能簡單查詢也需要進行多次數據庫訪問： iterate()會首先使用1條語句得到所有對象的持久化標識(identifiers)，再根據持久化標識執行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)指一條結果行包含多個對象） Hibernate查詢有時返回元組(tuples)，每個元組(tuples)以數組的形式返回:

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從句中指定類的屬性，甚至可以調用SQL統計(aggregate)函數。 屬性或統計結果被認定為"標量(Scalar)"的結果（而不是持久(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提供了對命名參數(named parameters)、JDBC風格的問號(?)參數進行綁定的方法。 不同于JDBC，Hibernate對參數從0開始計數。 命名參數(named parameters)在查詢字符串中是形如:name的標識符。 命名參數(named parameters)的優點是:

//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();

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

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

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

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

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()

請注意，使用此功能需要保持數據庫連接（以及游標(cursor)）處于一直打開狀態。 如果你需要斷開連接使用分頁功能，請使用setMaxResult()/setFirstResult()

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

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

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

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

請注意實際的程序代碼與所用的查詢語言無關，你也可在元數據中定義原生SQL(native SQL)查詢， 或將原有的其他的查詢語句放在配置文件中，這樣就可以讓Hibernate統一管理，達到遷移的目的。

首先，別再用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網站上面的提示和例子。

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

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

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

很明顯，我們必須使用多個數據庫事務來實現一個應用程序事務。在這個例子中，維護業務處理流程的 事務隔離變成了應用程序層的部分責任。單個應用程序事務通常跨越多個數據庫事務。如果僅僅只有一 個數據庫事務（最后的那個事務）保存更新過的數據，而所有其他事務只是單純的讀取數據（例如在一 個跨越多個請求/響應周期的向導風格的對話框中），那么應用程序事務將保證其原子性。這種方式比聽 起來還要容易實現，特別是當你使用了Hibernate的下述特性的時候：

session-per-request-with-detached-objects 和 session-per-application-transaction 各有優缺點，我們在本章后面樂觀并發 控制那部分再進行討論。

應用程序可能在兩個不同的Session中并發訪問同一持久化狀態，但是， 一個持久化類的實例無法在兩個 Session中共享。因此有兩種不同的標識語義：

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

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

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

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

如果Hibernat持久層運行在一個非托管環境中，數據庫連接通常由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()的調用會自動觸發session的同步。

調用 close() 標志session的結束。 close()方法重要的暗示是，session釋放了JDBC連接。

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

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

請注意，你應該選擇 org.hibernate.transaction.JDBCTransactionFactory (這是默認選項).

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

如果你使用bean管理事務（BMT），可以通過使用Hibernate的 Transaction API來告訴 應用服務器啟動和結束BMT事務。因此，事務管理代碼和在非托管環境下是一樣的。

// 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方式下，事務聲明是在session bean的部署描述符中，而不需要編程。 除非你設置了屬性hibernate.transaction.flush_before_completion和 hibernate.transaction.auto_close_session為true， 否則你必須自己同步和關閉Session。Hibernate可以為你自動同步和關閉 Session。你唯一要做的就是當發生異常時進行事務回滾。幸運的是， 在一個CMT bean中，事務回滾甚至可以由容器自動進行，因為由session bean方法拋出的未處理的 RuntimeException異?？梢酝ㄖ萜髟O置全局事務回滾。這意味著 在CMT中，你完全無需使用Hibernate的Transaction API 。

請注意，當你配置Hibernate事務工廠的時候，在一個BMT session bean中，你應該選擇 org.hibernate.transaction.JTATransactionFactory，在一個 CMT session bean中選擇org.hibernate.transaction.CMTTransactionFactory。 記住，同時也要設置org.hibernate.transaction.manager_lookup_class。

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

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

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

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

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

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

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

未能充分利用Hibernate功能的實現代碼中，每次和數據庫交互都需要一個新的 Session，而且開發人員必須在顯示數據之前從數據庫中重 新載入所有的持久化對象實例。這種方式迫使應用程序自己實現版本檢查來確保 應用程序事務的隔離，從數據訪問的角度來說是最低效的。這種使用方式和 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>來映射，如果對象 是臟數據，在同步的時候，Hibernate會自動增加版本號。

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

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

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

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

// 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相關聯。 Session.reconnect()獲取一個新的數據庫連接（或者 你可以提供一個），并且繼續當前的session。Session.disconnect() 方法把session與JDBC連接斷開，把數據庫連接返回到連接池（除非是你自己提供的數據 庫連接）。在Session重新連接上數據庫連接之后，你可以對任何可能被其他事務更新過 的對象調用Session.lock()，設置LockMode.READ 鎖定模式，這樣你就可以對那些你不準備更新的數據進行強制版本檢查。此外，你并不需要 鎖定那些你準備更新的數據。

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

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

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

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

// 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會再一次在同步的時候檢查對象實例的版本，如果發生更新沖突，就拋出異常。

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

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

遺留系統的數據庫Schema通常是靜態的，不可修改的?；蛘撸渌麘贸绦蛞部赡茉L問同一數據 庫，根本無法得知如何處理版本號，甚至時間戳。在以上的所有場景中，實現版本化不能依靠 數據庫表的某個特定列。在<class>的映射中設置 optimistic-lock="all"可以在沒有版本或者時間戳屬性映射的情況下實現 版本檢查，此時Hibernate將比較一行記錄的每個字段的狀態。請注意，只有當Hibernate能夠比 較新舊狀態的情況下，這種方式才能生效，也就是說， 你必須使用單個長生命周期Session模式，而不能使用 session-per-request-with-detached-objects模式。

有些情況下，只要更改不發生交錯，并發修改也是允許的。當你在<class> 的映射中設置optimistic-lock="dirty"，Hibernate在同步的時候將只比較有臟 數據的字段。

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

Interceptor接口提供了從會話(session)回調(callback)應用程序(application)的機制， 這種回調機制可以允許應用程序在持久化對象被保存、更新、刪除或是加載之前，檢查并（或）修改其 屬性。一個可能的用途，就是用來跟蹤審核(auditing)信息。例如：下面的這個攔截器，會在一個實現了 Auditable接口的對象被創建時自動地設置createTimestamp屬性，并在實現了 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;
}
...
}

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

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

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

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

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

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

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

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

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以使用選定的監聽器來替代默認的監聽器。

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

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

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

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

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

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

首先，你必須要配置適當的事件監聽器（event listener），來激活使用JAAS管理授權的功能。

<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文件中，綁定角色的權限：

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

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