在JDBC的數(shù)據(jù)庫操作中，一項事務(wù)是由一條或是多條表達式所組成的一個不可分割的工作單元。我們通過提交commit()或是回退rollback()來結(jié)束事務(wù)的操作。關(guān)于事務(wù)操作的方法都位于接口java.sql.Connection中。
首先我們要注意，在JDBC中，事務(wù)操作默認是自動提交。也就是說，一條對數(shù)據(jù)庫的更新表達式代表一項事務(wù)操作。操作成功后，系統(tǒng)將自動調(diào)用commit()來提交，否則將調(diào)用rollback()來回退。
其次，在JDBC中，可以通過調(diào)用setAutoCommit(false)來禁止自動提交。之后就可以把多個數(shù)據(jù)庫操作的表達式作為一個事務(wù)，在操作完成后調(diào)用commit()來進行整體提交。倘若其中一個表達式操作失敗，都不會執(zhí)行到commit()，并且將產(chǎn)生響應(yīng)的異常。此時就可以在異常捕獲時調(diào)用rollback()進行回退。這樣做可以保持多次更新操作后，相關(guān)數(shù)據(jù)的一致性。示例代碼如下：
java 代碼
try {
conn = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost:1433;User=JavaDB;Password=javadb;DatabaseName=northwind);
//點禁止自動提交，設(shè)置回退
conn.setAutoCommit(false);
stmt = conn.createStatement();
//數(shù)據(jù)庫更新操作1
stmt.executeUpdate(“update firsttable Set Name='testTransaction' Where ID = 1”);
//數(shù)據(jù)庫更新操作2
stmt.executeUpdate(“insert into firsttable ID = 12，Name = 'testTransaction2'”);
//事務(wù)提交
conn.commit();
}
catch(Exception ex) {
ex.printStackTrace();
try {
//操作不成功則回退
conn.rollback();
}
catch(Exception e){
e.printStackTrace();
}
}
這樣上面這段程序的執(zhí)行，或者兩個操作都成功，或者兩個都不成功，讀者可以自己修改第二個操作，使其失敗，以此來檢查事務(wù)處理的效果。我們在前面還提到了JDBC對事務(wù)所支持的隔離級別，下面將更詳細進行討論。
JDBC API支持事務(wù)對數(shù)據(jù)庫的加鎖，并且提供了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項為行加鎖。
“臟”數(shù)據(jù)讀寫(Dirty Reads)：當一個事務(wù)修改了某一數(shù)據(jù)行的值而未提交時，另一事務(wù)讀取了此行值。倘若前一事務(wù)發(fā)生了回退，則后一事務(wù)將得到一個無效的值(“臟”數(shù)據(jù))。
重復讀寫(Repeatable Reads)：當一個事務(wù)在讀取某一數(shù)據(jù)行時，另一事務(wù)同時在修改此數(shù)據(jù)行。則前一事務(wù)在重復讀取此行時將得到一個不一致的值。
錯誤(映像)讀寫(Phantom Reads)：當一個事務(wù)在某一表中進行數(shù)據(jù)查詢時，另一事務(wù)恰好插入了滿足了查詢條件的數(shù)據(jù)行。則前一事務(wù)在重復讀取滿足條件的值時，將得到一個額外的“影像”值。JDBC根據(jù)數(shù)據(jù)庫提供的默認值來設(shè)置事務(wù)支持及其加鎖，當然，也可以手工設(shè)置：
setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
可以查看數(shù)據(jù)庫的當前設(shè)置：
getTransactionIsolation ()
需要注意的是，在進行手動設(shè)置時，數(shù)據(jù)庫及其驅(qū)動程序必須得支持相應(yīng)的事務(wù)操作操作才行。
上述設(shè)置隨著值的增加，其事務(wù)的獨立性增加，更能有效地防止事務(wù)操作之間的沖突，同時也增加了加鎖的開銷，降低了用戶之間訪問數(shù)據(jù)庫的并發(fā)性，程序的運行效率也會隨之降低。因此得平衡程序運行效率和數(shù)據(jù)一致性之間的沖突。一般來說，對于只涉及到數(shù)據(jù)庫的查詢操作時，可以采用TRANSACTION_READ_UNCOMMITTED方式；對于數(shù)據(jù)查詢遠多于更新的操作，可以采用TRANSACTION_READ_COMMITTED方式；對于更新操作較多的，可以采用TRANSACTION_REPEATABLE_READ；在數(shù)據(jù)一致性要求更高的場合再考慮最后一項，由于涉及到表加鎖，因此會對程序運行效率產(chǎn)生較大的影響。
另外，在Oracle中數(shù)據(jù)庫驅(qū)動對事務(wù)處理的默認值是TRANSACTION_NONE，即不支持事務(wù)操作，所以需要在程序中手動進行設(shè)置。總之，JDBC提供的對數(shù)據(jù)庫事務(wù)操作的支持是比較完整的，通過事務(wù)操作可以提高程序的運行效率，保持數(shù)據(jù)的一致性。
4.8.4 分布式事務(wù)處理
在本節(jié)大部分篇幅中，我們一直討論的事務(wù)一直是僅僅涉及單個數(shù)據(jù)庫相連的單條連接，下面對分布式事務(wù)進行簡單的介紹。
事務(wù)處理是對某種服務(wù)的請求，而且是否接受或拒絕這種請求將即時答復請求者。在請求和響應(yīng)之間，資源(如文件、數(shù)據(jù)庫等)將根據(jù)需要閱讀和更新。從事務(wù)處理的發(fā)展歷史來看，大致經(jīng)歷了一個從集中處理到分布式處理的演進過程。這一轉(zhuǎn)變主要的動力是伴隨著Internet的興起，客戶對于更快、更安全的事務(wù)處理的客觀需求和面向?qū)ο蟮膽?yīng)用所提供的技術(shù)實現(xiàn)的可能性。
在Internet環(huán)境下，分布式事務(wù)處理為了滿足日益巨大的業(yè)務(wù)吞吐量所帶來的挑戰(zhàn)，其功能必須進一步拓展，必須支持分散應(yīng)用組件之間的互操作性，而這必須采用分布式事務(wù)處理管理器。這是有別于傳統(tǒng)的集中式事務(wù)處理的最鮮明的特點。指定一個事務(wù)叫做事務(wù)界定(demarcation)，通過把分布式的構(gòu)件綁定到一個全局事務(wù)上來完成事務(wù)界定工作，它是標記構(gòu)成一個事務(wù)的一組操作的一種方法。
最常用的界定的途徑是為事務(wù)處理標記執(zhí)行操作的線程，這叫做編程界定。這樣建立的事務(wù)可以通過去除標記而被掛起，并在以后通過從掛起點向恢復點顯式地傳遞事務(wù)上下文來恢復執(zhí)行。事務(wù)界定在向事務(wù)管理器的一個提交或一個回退請求之后結(jié)束，提交請求指導所有參與的資源管理器永久的記錄事務(wù)中的操作的效果，回退請求使資源管理器撤消事務(wù)中所有操作的效果。
一個可替代編程界定的是聲明界定。基于構(gòu)件的事務(wù)處理系統(tǒng)如 Microsoft 事務(wù)服務(wù)器，以及基于應(yīng)用服務(wù)器的事務(wù)處理系統(tǒng)如企業(yè) Java Beans 規(guī)范支持聲明界定。在這種技術(shù)中，構(gòu)件在部署時被標記為事務(wù)性的。這暗示了兩件事。首先，界定的職責從應(yīng)用轉(zhuǎn)移到了容納構(gòu)件的容器(Container)。為此，這種技術(shù)也叫做管理容器界定。其次，界定從應(yīng)用建造期間(靜態(tài))延期到構(gòu)件部署期間(動態(tài))。
因為多個應(yīng)用構(gòu)件和資源參與了一個事務(wù)，對于事務(wù)管理器建立和維護發(fā)生的事務(wù)的狀態(tài)是必須的。這通常以事務(wù)上下文的形式完成。事務(wù)上下文是在資源上的事務(wù)性操作和調(diào)用操作的構(gòu)件之間的一個關(guān)聯(lián)(Association)。在一個事務(wù)執(zhí)行期間，所有的參與事務(wù)的線程共享事務(wù)上下文。所以事務(wù)上下文在邏輯上封裝(Envelop)了在一個事務(wù)期間在事務(wù)性資源上的完成的所有操作。事務(wù)上下文通常由底層的事務(wù)管理器透明的維護。討論分布式事務(wù)的細節(jié)已經(jīng)超出本書的范圍，這里的目的是給大家一些思路和概念。下面分別介紹一下關(guān)于分布式事務(wù)處理的技術(shù)模型：
1. X/Open分布式事務(wù)處理模型
X/Open分布式事務(wù)處理(DTP)模型是Open Group提出的一個分布式處理模型，Open Group是一個廠商財團。這個模型是在事務(wù)處理和數(shù)據(jù)庫領(lǐng)域中多數(shù)商業(yè)廠商間的一個標準。這個模型由四個構(gòu)件組成：
(1) 應(yīng)用程序：實現(xiàn)事務(wù)性操作
(2) 資源管理器：同于上面的討論
(3) 事務(wù)管理器：同于上面的討論
(4) 通信資源管理器：方便在不同的事務(wù)處理領(lǐng)域中的不同的事務(wù)管理器之間的互操作
X/Open DTP模型在產(chǎn)業(yè)界中被確立的。一些商業(yè)事務(wù)管理產(chǎn)品，像TXSeries/Encina (完全附屬于IBM的Tranarc的產(chǎn)品)，Tuxedo和TopEnd (BEA Systems的產(chǎn)品)，還有 AT&T GIS 支持TX接口。盡管Microsoft的Transaction Server不支持TX接口，它還是能夠同像Oracle這樣的遵從XA的數(shù)據(jù)庫互操作。類似的，多數(shù)商業(yè)數(shù)據(jù)庫像Oracle，Sybase，Informix和 Microsoft SQL Server，以及消息中間件產(chǎn)品如IBM的MQSeries，和Microsoft的MSMQ Server 提供了XA接口的一個實現(xiàn)。
2. OMG對象事務(wù)服務(wù)
對象事務(wù)服務(wù)(OTS)是由對象管理組織(OMG)規(guī)定的分布式事務(wù)處理服務(wù)。這個規(guī)范擴展了CORBA模型并定義了一系列跨越(across)多個CORBA對象完成事務(wù)處理的接口。OTS模型基于X/Open DTP模型之上并提供增強，如OTS模型把函數(shù)形式的XA和TX接口替換成了CORBA IDL接口，在這個模型中的各種對象通過在IIOP之上的CORBA方法調(diào)用來通信。
OTS體系由下列構(gòu)件組成：
事務(wù)客戶：一個調(diào)用事務(wù)性對象上的操作的程序或?qū)ο蟆?span lang="EN-US">
事務(wù)性對象：一個封裝(encapsulate)或參照(refers to)持久數(shù)據(jù)的 CORBA 對象，并且它的行為依賴于在一個事務(wù)期間是否調(diào)用它的操作。
可恢復對象：一個直接維護持久數(shù)據(jù)并且參與事務(wù)協(xié)議的事務(wù)性對象。
事務(wù)性服務(wù)器：一個或多個事務(wù)性對象的集合(collection)。
可恢復服務(wù)器：一個對象的集合，其中至少有一個是可恢復的。
資源對象：一個資源對象是為了參與兩階段提交和恢復協(xié)議而被注冊的、在事務(wù)服務(wù)中的一個對象。