jdbc數據庫

　　

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

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

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