在JDBC的數據庫操作中，一項事務是由一條或是多條表達式所組成的一個不可分割的工作單元。我們通過提交commit()或是回退rollback()來結束事務的操作。關于事務操作的方法都位于接口java.sql.Connection中。

首先我們要注意，在JDBC中，事務操作默認是自動提交。也就是說，一條對數據庫的更新表達式代表一項事務操作。操作成功后，系統將自動調用commit()來提交，否則將調用rollback()來回退。

其次，在JDBC中，可以通過調用setAutoCommit(false)來禁止自動提交。之后就可以把多個數據庫操作的表達式作為一個事務，在操作完成后調用commit()來進行整體提交。倘若其中一個表達式操作失敗，都不會執行到commit()，并且將產生響應的異常。此時就可以在異常捕獲時調用rollback()進行回退。這樣做可以保持多次更新操作后，相關數據的一致性。示例代碼如下：

java 代碼

try {   

  

conn = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost:1433;User=JavaDB;Password=javadb;DatabaseName=northwind);   

  

//點禁止自動提交，設置回退   

  

conn.setAutoCommit(false);    

  

stmt = conn.createStatement();   

  

//數據庫更新操作1   

  

stmt.executeUpdate(“update firsttable Set Name='testTransaction' Where ID = 1”);    

  

//數據庫更新操作2   

  

stmt.executeUpdate(“insert into firsttable ID = 12，Name = 'testTransaction2'”);    

  

//事務提交   

  

conn.commit();   

  

}   

  

catch(Exception ex) {    

  

ex.printStackTrace();   

  

try {   

  

//操作不成功則回退   

  

conn.rollback();   

  

}   

  

catch(Exception e){   

  

e.printStackTrace();   

  

}   

  

}    

 

這樣上面這段程序的執行，或者兩個操作都成功，或者兩個都不成功，讀者可以自己修改第二個操作，使其失敗，以此來檢查事務處理的效果。我們在前面還提到了JDBC對事務所支持的隔離級別，下面將更詳細進行討論。

JDBC API支持事務對數據庫的加鎖，并且提供了5種操作支持，2種加鎖密度。

5種加鎖支持為：

static int TRANSACTION_NONE = 0;

static int TRANSACTION_READ_UNCOMMITTED = 1;

static int TRANSACTION_READ_COMMITTED = 2;

static int TRANSACTION_REPEATABLE_READ = 4;

static int TRANSACTION_SERIALIZABLE = 8;

具體的說明見表4-2。

2種加鎖密度：

最后一項為表加鎖，其余3～4項為行加鎖。

“臟”數據讀寫(Dirty Reads)：當一個事務修改了某一數據行的值而未提交時，另一事務讀取了此行值。倘若前一事務發生了回退，則后一事務將得到一個無效的值(“臟”數據)。

重復讀寫(Repeatable Reads)：當一個事務在讀取某一數據行時，另一事務同時在修改此數據行。則前一事務在重復讀取此行時將得到一個不一致的值。

錯誤(映像)讀寫(Phantom Reads)：當一個事務在某一表中進行數據查詢時，另一事務恰好插入了滿足了查詢條件的數據行。則前一事務在重復讀取滿足條件的值時，將得到一個額外的“影像”值。JDBC根據數據庫提供的默認值來設置事務支持及其加鎖，當然，也可以手工設置：

setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);

可以查看數據庫的當前設置：

getTransactionIsolation ()

需要注意的是，在進行手動設置時，數據庫及其驅動程序必須得支持相應的事務操作操作才行。

上述設置隨著值的增加，其事務的獨立性增加，更能有效地防止事務操作之間的沖突，同時也增加了加鎖的開銷，降低了用戶之間訪問數據庫的并發性，程序的運行效率也會隨之降低。因此得平衡程序運行效率和數據一致性之間的沖突。一般來說，對于只涉及到數據庫的查詢操作時，可以采用TRANSACTION_READ_UNCOMMITTED方式；對于數據查詢遠多于更新的操作，可以采用TRANSACTION_READ_COMMITTED方式；對于更新操作較多的，可以采用TRANSACTION_REPEATABLE_READ；在數據一致性要求更高的場合再考慮最后一項，由于涉及到表加鎖，因此會對程序運行效率產生較大的影響。

另外，在Oracle中數據庫驅動對事務處理的默認值是TRANSACTION_NONE，即不支持事務操作，所以需要在程序中手動進行設置。總之，JDBC提供的對數據庫事務操作的支持是比較完整的，通過事務操作可以提高程序的運行效率，保持數據的一致性。

4.8.4 分布式事務處理

在本節大部分篇幅中，我們一直討論的事務一直是僅僅涉及單個數據庫相連的單條連接，下面對分布式事務進行簡單的介紹。

事務處理是對某種服務的請求，而且是否接受或拒絕這種請求將即時答復請求者。在請求和響應之間，資源(如文件、數據庫等)將根據需要閱讀和更新。從事務處理的發展歷史來看，大致經歷了一個從集中處理到分布式處理的演進過程。這一轉變主要的動力是伴隨著Internet的興起，客戶對于更快、更安全的事務處理的客觀需求和面向對象的應用所提供的技術實現的可能性。

在Internet環境下，分布式事務處理為了滿足日益巨大的業務吞吐量所帶來的挑戰，其功能必須進一步拓展，必須支持分散應用組件之間的互操作性，而這必須采用分布式事務處理管理器。這是有別于傳統的集中式事務處理的最鮮明的特點。指定一個事務叫做事務界定(demarcation)，通過把分布式的構件綁定到一個全局事務上來完成事務界定工作，它是標記構成一個事務的一組操作的一種方法。

最常用的界定的途徑是為事務處理標記執行操作的線程，這叫做編程界定。這樣建立的事務可以通過去除標記而被掛起，并在以后通過從掛起點向恢復點顯式地傳遞事務上下文來恢復執行。事務界定在向事務管理器的一個提交或一個回退請求之后結束，提交請求指導所有參與的資源管理器永久的記錄事務中的操作的效果，回退請求使資源管理器撤消事務中所有操作的效果。

一個可替代編程界定的是聲明界定。基于構件的事務處理系統如 Microsoft 事務服務器，以及基于應用服務器的事務處理系統如企業 Java Beans 規范支持聲明界定。在這種技術中，構件在部署時被標記為事務性的。這暗示了兩件事。首先，界定的職責從應用轉移到了容納構件的容器(Container)。為此，這種技術也叫做管理容器界定。其次，界定從應用建造期間(靜態)延期到構件部署期間(動態)。

因為多個應用構件和資源參與了一個事務，對于事務管理器建立和維護發生的事務的狀態是必須的。這通常以事務上下文的形式完成。事務上下文是在資源上的事務性操作和調用操作的構件之間的一個關聯(Association)。在一個事務執行期間，所有的參與事務的線程共享事務上下文。所以事務上下文在邏輯上封裝(Envelop)了在一個事務期間在事務性資源上的完成的所有操作。事務上下文通常由底層的事務管理器透明的維護。討論分布式事務的細節已經超出本書的范圍，這里的目的是給大家一些思路和概念。下面分別介紹一下關于分布式事務處理的技術模型：

1. X/Open分布式事務處理模型

X/Open分布式事務處理(DTP)模型是Open Group提出的一個分布式處理模型，Open Group是一個廠商財團。這個模型是在事務處理和數據庫領域中多數商業廠商間的一個標準。這個模型由四個構件組成：

(1) 應用程序：實現事務性操作

(2) 資源管理器：同于上面的討論

(3) 事務管理器：同于上面的討論

(4) 通信資源管理器：方便在不同的事務處理領域中的不同的事務管理器之間的互操作

X/Open DTP模型在產業界中被確立的。一些商業事務管理產品，像TXSeries/Encina (完全附屬于IBM的Tranarc的產品)，Tuxedo和TopEnd (BEA Systems的產品)，還有 AT&T GIS 支持TX接口。盡管Microsoft的Transaction Server不支持TX接口，它還是能夠同像Oracle這樣的遵從XA的數據庫互操作。類似的，多數商業數據庫像Oracle，Sybase，Informix和 Microsoft SQL Server，以及消息中間件產品如IBM的MQSeries，和Microsoft的MSMQ Server 提供了XA接口的一個實現。

2. OMG對象事務服務

對象事務服務(OTS)是由對象管理組織(OMG)規定的分布式事務處理服務。這個規范擴展了CORBA模型并定義了一系列跨越(across)多個CORBA對象完成事務處理的接口。OTS模型基于X/Open DTP模型之上并提供增強，如OTS模型把函數形式的XA和TX接口替換成了CORBA IDL接口，在這個模型中的各種對象通過在IIOP之上的CORBA方法調用來通信。

 

OTS體系由下列構件組成：

事務客戶：一個調用事務性對象上的操作的程序或對象。

事務性對象：一個封裝(encapsulate)或參照(refers to)持久數據的 CORBA 對象，并且它的行為依賴于在一個事務期間是否調用它的操作。

可恢復對象：一個直接維護持久數據并且參與事務協議的事務性對象。

事務性服務器：一個或多個事務性對象的集合(collection)。

可恢復服務器：一個對象的集合，其中至少有一個是可恢復的。

資源對象：一個資源對象是為了參與兩階段提交和恢復協議而被注冊的、在事務服務中的一個對象。