Hibernate 是對(duì)JDBC的輕量級(jí)對(duì)象封裝，Hibernate本身是不具備Transaction處理功能的，Hibernate的Transaction實(shí)際上是底層的JDBC Transaction的封裝，或者是JTA Transaction的封裝，下面我們?cè)敿?xì)的分析：

Hibernate可以配置為JDBCTransaction或者是JTATransaction，這取決于你在hibernate.properties中的配置:

#hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory
#hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory

如果你什么都不配置，默認(rèn)情況下使用JDBCTransaction，如果你配置為：

hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory

將使用JTATransaction

不管你準(zhǔn)備讓Hibernate使用JDBCTransaction，還是JTATransaction，我的忠告就是什么都不配，將讓它保持默認(rèn)狀態(tài)，如下：

#hibernate.transaction.factory_class net.sf.hibernate.transaction.JTATransactionFactory
#hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory

在下面的分析中我會(huì)給出原因。

一、JDBC Transaction

看看使用JDBC Transaction的時(shí)候我們的代碼例子：

Session session = sf.openSession();
Transaction tx = session.beginTransactioin();
...
session.flush();
tx.commit();
session.close();

這是默認(rèn)的情況，當(dāng)你在代碼中使用Hibernate的Transaction的時(shí)候?qū)嶋H上就是JDBCTransaction。那么JDBCTransaction究竟是什么東西呢？來(lái)看看源代碼就清楚了：

Hibernate2.0.3源代碼中的類(lèi)

net.sf.hibernate.transaction.JDBCTransaction:

public void begin() throws HibernateException {

...
if (toggleAutoCommit) session.connection().setAutoCommit(false);
...
}

這是啟動(dòng)Transaction的方法，看到 connection().setAutoCommit(false) 了嗎？是不是很熟悉？

再來(lái)看

public void commit() throws HibernateException {
...
try {
if ( session.getFlushMode()!=FlushMode.NEVER ) session.flush();
try {
session.connection().commit();
committed = true;
}
...
toggleAutoCommit();
}

這是提交方法，看到connection().commit() 了嗎？下面就不用我多說(shuō)了，這個(gè)類(lèi)代碼非常簡(jiǎn)單易懂，通過(guò)閱讀使我們明白Hibernate的Transaction都在干了些什么？我現(xiàn)在把用 Hibernate寫(xiě)的例子翻譯成JDBC，大家就一目了然了：

Connection conn = ...; <--- session = sf.openSession();

conn.setAutoCommit(false); <--- tx = session.beginTransactioin();

... <--- ...

conn.commit(); <--- tx.commit(); (對(duì)應(yīng)左邊的兩句)
conn.setAutoCommit(true);

conn.close(); <--- session.close();

看明白了吧，Hibernate的JDBCTransaction根本就是conn.commit而已，根本毫無(wú)神秘可言，只不過(guò)在Hibernate 中，Session打開(kāi)的時(shí)候，就會(huì)自動(dòng)conn.setAutoCommit(false)，不像一般的JDBC，默認(rèn)都是true，所以你最后不寫(xiě) commit也沒(méi)有關(guān)系，由于Hibernate已經(jīng)把AutoCommit給關(guān)掉了，所以用Hibernate的時(shí)候，你在程序中不寫(xiě) Transaction的話，數(shù)據(jù)庫(kù)根本就沒(méi)有反應(yīng)。
如果你在EJB中使用Hibernate，或者準(zhǔn)備用JTA來(lái)管理跨Session的長(zhǎng)事務(wù)，那么就需要使用JTATransaction，先看一個(gè)例子：

javax.transaction.UserTransaction tx = new InitialContext().lookup("javax.transaction.UserTransaction");

Session s1 = sf.openSession();
...
s1.flush();
s1.close();

...

Session s2 = sf.openSession();
...
s2.flush();
s2.close();

tx.commit();

這是標(biāo)準(zhǔn)的使用JTA的代碼片斷，Transaction是跨Session的，它的生命周期比Session要長(zhǎng)。如果你在EJB中使用 Hibernate，那么是最簡(jiǎn)單不過(guò)的了，你什么Transaction代碼統(tǒng)統(tǒng)都不要寫(xiě)了，直接在EJB的部署描述符上配置某某方法是否使用事務(wù)就可以了。

現(xiàn)在我們來(lái)分析一下JTATransaction的源代碼， net.sf.hibernate.transaction.JTATransaction:

public void begin(InitialContext context, ...
...
ut = (UserTransaction) context.lookup(utName);
...

看清楚了嗎？ 和我上面寫(xiě)的代碼 tx = new Initial Context?().lookup("javax.transaction.UserTransaction"); 是不是完全一樣？

public void commit() ...
...
if (newTransaction) ut.commit();
...

JTATransaction的控制稍微復(fù)雜，不過(guò)仍然可以很清楚的看出來(lái)Hibernate是如何封裝JTA的Transaction代碼的。

但是你現(xiàn)在是否看到了什么問(wèn)題？ 仔細(xì)想一下，Hibernate Transaction是從Session中獲得的，tx = session.beginTransaction()，最后要先提交tx，然后再session.close，這完全符合JDBC的 Transaction的操作順序，但是這個(gè)順序是和JTA的Transactioin操作順序徹底矛盾的！！！ JTA是先啟動(dòng)Transaction，然后啟動(dòng)Session，關(guān)閉Session，最后提交Transaction，因此當(dāng)你使用JTA的 Transaction的時(shí)候，那么就千萬(wàn)不要使用Hibernate的Transaction，而是應(yīng)該像我上面的JTA的代碼片斷那樣使用才行。

總結(jié)：
1、在JDBC上使用Hibernate

必須寫(xiě)上Hibernate Transaction代碼，否則數(shù)據(jù)庫(kù)沒(méi)有反應(yīng)。此時(shí)Hibernate的Transaction就是Connection.commit而已

2、在JTA上使用Hibernate

寫(xiě)JTA的Transaction代碼，不要寫(xiě)Hibernate的Transaction代碼，否則程序會(huì)報(bào)錯(cuò)

3、在EJB上使用Hibernate

什么Transactioin代碼都不要寫(xiě)，在EJB的部署描述符里面配置

|---CMT(Container Managed Transaction)
|
|---BMT(Bean Managed Transaction)
|
|----JDBC Transaction
|
|----JTA Transaction

--------------------------------------------------------------------------------

提問(wèn)：

javax.transaction.UserTransaction tx = new InitialContext().lookup("javax.transaction.UserTransaction");

Session s1 = sf.openSession();
...
s1.flush();
s1.close();

...

Session s2 = sf.openSession();
...
s2.flush();
s2.close();

tx.commit();

s1不關(guān)閉，使用s2進(jìn)行操作的代碼中使用s1可不可以（我覺(jué)得這樣更加節(jié)約資源，不需要反復(fù)的連接、關(guān)閉）

但sf.opengSession()時(shí)，并沒(méi)有setAutoCommit(false)，我想問(wèn)的是，如果不編寫(xiě)任何事務(wù)代碼，如：
Session s = sf.openSession();
......
s.close();
數(shù)據(jù)庫(kù)會(huì)不會(huì)有反應(yīng)（此時(shí)應(yīng)該是默認(rèn)AutoCommit為true）。

不會(huì)有反應(yīng)。在sf.openSession() 創(chuàng)建Session實(shí)例的時(shí)候，就已經(jīng)調(diào)用了conn.setAutoCommit(false)了。

另外，我想問(wèn)一下：

1. s.flush()是不是必須的

2. s.close()是不是一定要關(guān)閉

--------------------------------------------------------------------------------

回答：

s.flush不是必須的，s.close()會(huì)調(diào)用一次s.flush()

s.close()正常情況下應(yīng)該關(guān)閉，除非你是用ThreadLocal管理Session。

s1不關(guān)閉，使用s2進(jìn)行操作的代碼中使用s1可不可以（我覺(jué)得這樣更加節(jié)約資源，不需要反復(fù)的連接、關(guān)閉）

在這個(gè)例子中看不出來(lái)JTA的作用。
假設(shè)
Class A {
find() {
Session s1 = sf.openSession();
...
s1.flush();
s1.close();
}
}

Class B {
find() {
Session s2 = sf.openSession();
...
s2.flush();
s2.close();
}
}

Main {

tx = ...;
A.find();
B.find();
tx.commit();
} （全文完）

數(shù)據(jù)庫(kù)事務(wù)必須具備ACID特征,ACID是Atomic(原子性),Consistency(一致性),Isolation(隔離性),和Durability(持久性).

Atomic(原子性):指整個(gè)數(shù)據(jù)庫(kù)事務(wù)是不可分割的工作單元,只有事務(wù)中所有的操作執(zhí)行成功,才算整個(gè)事務(wù)成功.
Consistency(一致性):指數(shù)據(jù)庫(kù)事務(wù)不能破換關(guān)系數(shù)據(jù)的完整性以及業(yè)務(wù)邏輯上的一致性(比如說(shuō)銀行轉(zhuǎn)帳事務(wù),不管事務(wù)成功還是
失敗,應(yīng)該保證事務(wù)結(jié)束后的存款總額為原來(lái)的.)
Isolation(隔離性):指在并發(fā)環(huán)境中,當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí),每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間.
Durability(持久性):指的是只要事務(wù)成功工結(jié)束,它對(duì)數(shù)據(jù)庫(kù)所做的更新就必須永久保存下來(lái),即使發(fā)生系統(tǒng)崩潰,從新啟動(dòng)數(shù)據(jù)庫(kù)系統(tǒng)后,數(shù)據(jù)庫(kù)還能恢復(fù)到事務(wù)成功結(jié)束時(shí)候的狀態(tài).

數(shù)據(jù)庫(kù)管理系統(tǒng)采用日志來(lái)保證事務(wù)的原子性,一致性和持久性,日志記錄了事務(wù)對(duì)數(shù)據(jù)庫(kù)所做的更新,如果某個(gè)事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤,就可以根據(jù)日志,撤消事務(wù)對(duì)數(shù)據(jù)庫(kù)已做的更新,使數(shù)據(jù)庫(kù)退回到執(zhí)行事務(wù)前的初始狀態(tài).

數(shù)據(jù)庫(kù)管理系統(tǒng)采用鎖機(jī)制來(lái)實(shí)現(xiàn)事務(wù)的隔離性,當(dāng)多個(gè)事務(wù)同時(shí)更新數(shù)據(jù)庫(kù)中的相同的數(shù)據(jù)時(shí),只允許只有鎖的事務(wù)能更新該數(shù)據(jù),其他事務(wù)必須等待,直到前一個(gè)事務(wù)釋放了鎖,其他事務(wù)才有機(jī)會(huì)更新該數(shù)據(jù)。

(POJOs IN ACTION中文版)
 
隔離的（isolated）數(shù)據(jù)庫(kù)事務(wù)
有時(shí)，你可以直接依賴(lài)數(shù)據(jù)庫(kù)本身處理共享數(shù)據(jù)的并發(fā)訪問(wèn)。可以將數(shù)據(jù)庫(kù)配置成執(zhí)行相互隔離（isolated，用數(shù)據(jù)庫(kù)的行話來(lái)講）的數(shù)據(jù)庫(kù)事務(wù)。如果你還不熟悉這一概念，請(qǐng)別擔(dān)心，第12章里會(huì)進(jìn)行詳細(xì)說(shuō)明。眼下最關(guān)鍵的是要記住，如果應(yīng)用程序使用完全隔離的事務(wù)，那么同時(shí)執(zhí)行兩個(gè)事務(wù)的效果將與一個(gè)接一個(gè)執(zhí)行這兩個(gè)事務(wù)完全等效。
從表面上看，這種方法看似非常簡(jiǎn)單，但這類(lèi)事務(wù)也存在問(wèn)題，由于隔離事務(wù)如何實(shí)現(xiàn)完全由數(shù)據(jù)庫(kù)決定，因此有時(shí)它們會(huì)導(dǎo)致性能降低，令人無(wú)法接受。鑒于此，許多應(yīng)用程序都避免使用這類(lèi)事務(wù)，轉(zhuǎn)而采用所謂的樂(lè)觀（optimistic）或者悲觀（pessimistic）鎖，稍后將作描述。

  樂(lè)觀鎖
處理并發(fā)更新的一種方式是使用樂(lè)觀鎖（optimistic locking）。樂(lè)觀鎖的工作原理是讓?xiě)?yīng)用程序檢查它即將更新的數(shù)據(jù)是否已被另一個(gè)事務(wù)修改（自該數(shù)據(jù)上次讀取以來(lái)）。實(shí)現(xiàn)樂(lè)觀鎖的一種常見(jiàn)做法是在每個(gè)表里添加一個(gè)版本字段，每次應(yīng)用程序更新數(shù)據(jù)表記錄時(shí)就增加這個(gè)版本字段。每個(gè)UPDATE語(yǔ)句中的WHERE子句會(huì)根據(jù)上次讀取的值來(lái)判斷這個(gè)版本號(hào)是否改變。通過(guò)查看PreparedStatement.executeUpdate()返回的記錄數(shù)，應(yīng)用程序可以判斷UPDATE語(yǔ)句是否成功。如果這條記錄已被另一個(gè)事務(wù)更新或刪除，應(yīng)用程序可以回滾這個(gè)事務(wù)，并重新開(kāi)始。
在直接執(zhí)行SQL語(yǔ)句的應(yīng)用程序中，樂(lè)觀鎖機(jī)制的實(shí)現(xiàn)非常容易。不過(guò)，使用諸如JDO和Hibernate的持久層構(gòu)架時(shí)，實(shí)現(xiàn)更為容易，因?yàn)樗鼈円褜?lè)觀鎖作為配置選項(xiàng)提供。一旦啟用該配置選項(xiàng)，持久層框架會(huì)自動(dòng)生成SQL UPDATE語(yǔ)句，執(zhí)行版本檢查。第12章將分析樂(lè)觀鎖的使用時(shí)機(jī)及其缺點(diǎn)，并向你展示怎樣在iBATIS、JDO和Hibernate中使用樂(lè)觀鎖。
樂(lè)觀鎖的名稱(chēng)源自如下假定情況，即并發(fā)更新的幾率極小，此外應(yīng)用程序并不阻止并發(fā)更新，而是檢測(cè)并發(fā)更新，并從并發(fā)更新中恢復(fù)過(guò)來(lái)。另一種方式是使用悲觀鎖（pessimistic locking），它假定并發(fā)更新將會(huì)發(fā)生，因此必須預(yù)先阻止。

悲觀鎖

不同于樂(lè)觀鎖的另一種方式是使用悲觀鎖。當(dāng)讀取某些記錄時(shí)，事務(wù)先鎖住這些記錄，這樣可以防止其他事務(wù)訪問(wèn)這些數(shù)據(jù)記錄。具體細(xì)節(jié)要視數(shù)據(jù)庫(kù)而定，不過(guò)糟糕的是，并非所有數(shù)據(jù)庫(kù)都支持悲觀鎖。如果數(shù)據(jù)庫(kù)支持悲觀鎖，在直接執(zhí)行SQL語(yǔ)句的應(yīng)用程序中，實(shí)現(xiàn)悲觀鎖非常容易。然而，正如你所預(yù)料的，在JDO或Hibernate應(yīng)用程序中使用悲觀鎖更為容易。JDO以配置選項(xiàng)的方式提供悲觀鎖，而Hibernate則提供一個(gè)簡(jiǎn)單實(shí)用的API，來(lái)鎖定對(duì)象。同樣，在第12章，你將學(xué)習(xí)何時(shí)使用悲觀鎖，分析其缺點(diǎn)，并看看怎樣在iBATIS、JDO和Hibernate中使用悲觀鎖。

除了處理單個(gè)數(shù)據(jù)庫(kù)事務(wù)里的并發(fā)，通常你還必須處理跨一系列數(shù)據(jù)庫(kù)事務(wù)的并發(fā)