引言
JTA(Java Transaction API)允許應用程序執行分布式事務處理
在兩個或多個網絡計算機資源上訪問並且更新數據
JDBC驅動程序的JTA支持極大地增強了數據訪問能力
本文的目的是要提供一個關於的Java事務處理API（JTA）的高級的概述
以及與分布式事務相關的內容
一個事務處理定義了一個工作邏輯單元
要麼徹底成功要麼不產生任何結果
一個分布式事務處理只是一個在兩個或更多網絡資源上訪問和更新數據的事務處理
因此它在那些資源之間必然是等價的
在本文中
我們主要關心的是如何處理關系數據庫系統
我們要討論的分布式事務處理（DTP）模型中包含的組件是
應用程序
應用程序服務器
事務管理程序
資源適配器
資源管理程序
在以後的內容中
我們將描述這些組件以及它們與JTA和數據庫訪問的關系
訪問數據庫
最好把分布式事務處理中包含的組件看作是獨立的過程
而不是考慮它們在一個特定的電腦中的位置
這些組件中的一些可以保存在單機中
或者也可在好幾台機器之間分布
下面例子中的圖表可以顯示在一台特定的電腦上的組件
但是這些操作之間的關系是必須首要考慮的
最簡單的例子
用於本地數據庫事務處理的應用程序
關系數據庫訪問的最簡單的形式僅僅包括應用程序
資源管理程序和資源適配器
應用程序只不過是發送請求到數據庫並且從數據庫中獲取數據的最終用戶訪問點
我們討論的資源管理程序是一個關系數據庫管理系統（RDBMS）
比如Oracle或者SQL Server
所有的實際數據庫管理都是由這個組件處理的
資源適配器是外部空間之間的通信管道組件
或者是請求翻譯器
在本例中
是應用程序和資源管理程序
在我們的討論中
這是一個JDBC驅動程序
下面的描述是資源管理程序本地事務處理的一個描述
也就是說
一個事務處理被被限制在一個特定的企業數據庫
應用程序發送一個用於JDBC驅動程序數據的請求
然後翻譯這個請求並把它通過網絡發送到數據庫中
數據庫把數據發送回驅動程序
然後把翻譯的結果發送回應用程序
如下圖所示
這個例子說明了在一個簡化的系統中的基本的信息流
然而
今天的企業使用的應用程序服務器都添加了其他的組件到這個過程處理中
應用程序服務器
應用程序服務器是事務處理操作的另一個組件
應用程序服務器處理大部分的應用程序操作並且獲得最終用戶應用程序的一些負載
基於前面的例子
我們可以看出應用程序服務器在事務處理上添加了另一個操作層:
到目前為止
我們的例子說明了單個的本地事務處理
並且描述了分布式事務處理模型的五個組件中的四個
第五個組件
事務管理程序只有當事務將要被分配的時候才會開始被考慮
分布式事務處理和事務管理程序
像我們前面所提到的
一個分布式事務處理是一個在兩個或更多網絡資源上訪問和更新數據的事務處理
這些資源可以由好幾個位於一個單獨服務器上的不同的關系型數據庫管理系統組成
比如說Oracle
SQL Server和Sybase
它們也可以包含存在於若干不同的服務器上的同一種數據庫的若干個實例
在任何情況下
一個分布式事務處理包括各種的資源管理程序之間的協同作用
這個協同作用是事務管理函數
事務管理程序負責作出要麼提交(commit)要麼退回(rollback)任何分布式事務處理的決定
一個提交決定應該導致一個成功的事務處理
而退回操作則是保持數據庫中的數據不變
JTA指定一個分布式事務處理中的事務管理程序和另一個組件之間的標准Java接口
應用程序
應用程序服務器和資源管理程序
這個關系被顯示在下面的圖表中
在事務管理程序周圍的數字框框相應於JTA的三個接口部分
—UserTransaction—javax
transaction
UserTransaction接口提供能夠編程地控制事務處理范圍的應用程序
javax
transaction
UserTransaction方法開啟一個全局事務並且使用調用線程與事務處理關聯
—Transaction Manager—javax
transaction
TransactionManager接口允許應用程序服務器來控制代表正在管理的應用程序的事務范圍
—XAResource—javax
transaction
xa
XAResource接口是一個基於X/Open CAE Specification的行業標准XA接口的Java映射
注意
一個限制性環節是通過JDBC驅動程序的XAResource接口的支持
JDBC驅動程序必須支持兩個正常的JDBC交互作用
應用程序和/或應用程序服務器
而且以及JTA的XAResource部分
編寫應用程序水平代碼的開發者不會關心分布式事務處理管理的細節
這是分布式事務處理基本結構的工作—應用程序服務器
事務管理程序和JDBC驅動程序
應用程序代碼中唯一的需要注意的就是當連接處於一個分布式事務范圍內的時候
不應該調用一個會影響事務邊界的方法
特別的是
一個應用程序不應該調用Connection方法commit
rollback和setAutoCommit(true)
因為它們將破壞分布式事務的基本結構管理
分布式事務處理
事務管理程序是分布式事務基本結構的基本組件
然而JDBC驅動程序和應用程序服務器組件應該具備下面的特征
驅動程序應該實現JDBC
應用程序接口
包括Optional Package接口XADataSource和XAConnection以及JTA接口XAResource
應用程序服務器應該提供一個DataSource類
用來實現與分布式事務基本結的交互以及一個連接池模塊（用於改善性能）
分布式事務處理的第一步就是應用程序要發送一個事務請求到事務管理程序
雖然最後的commit/rollback決定把事務作為一個簡單的邏輯單元來對待
但是仍然可能會包括許多事務分支
一個事務分支與一個到包含在分布式事務中的每個資源管理程序相關聯
因此
到三個不同的關系數據庫管理的請求需要三個事務分支
每個事務分支必須由本地資源管理程序提交或者返回
事務管理程序控制事務的邊界
並且負責最後決定應該提交或者返回的全部事務
這個決定由兩個步驟組成
稱為Two
Phase Commit Protocol
在第一步驟中
事務管理程序輪詢所有包含在分布式事務中的資源管理程序（關系數據庫管理）來看看哪個可以准備提交
如果一個資源管理程序不能提交
它將不響應
並且把事務的特定部分返回
以便數據不被修改
在第二步驟中
事務管理程序判斷否定響應的資源管理程序中是否有能夠返回整個事務的
如果沒有否定響應的話
翻譯管理程序提交整個事務並且返回結果到應用程序中
開發事項管理程序代碼的開發者必須與所有三個JTA接口有關
UserTransaction
TransactionManager和XAResource
這三個接口都被描述在
Sun JTA specification中
JDBC驅動程序開發者只需要關心XAResource接口
這個接口是允許一個資源管理程序參與事務的行業標准X/Open XA協議的Java映射
連接XAResource接口的驅動程序組件負責在事務管理程序和資源管理程序之間擔任
翻譯
的任務
下面的章節提供了XAResource調用的例子
JDBC驅動程序和XAResource
為了簡化XAResource的說明
這些例子說明了一個應用程序在不包含應用程序服務器和事項管理程序的情況下應該如何使用JTA
基本上
這些例子中的應用程序也擔任應用程序服務器和事項管理程序的任務
大部分的企業使用事務管理程序和應用程序服務器
因為它們能夠比一個應用程序更能夠高效地管理分布式事務
然而遵循這些例子
一個應用程序開發者可以測試在JDBC驅動程序中的JTA支持的健壯性
而且有一些例子可能不是工作在某個特定的數據庫上
這是因為關聯在數據庫上的一些內在的問題
在使用JTA之前
你必須首先實現一個Xid類用來標識事務（在普通情況下這將由事務管理程序來處理）
Xid包含三個元素
formatID
gtrid（全局事務標識符）和bqual（分支修飾詞標識符）
formatID通常是零
這意味著你將使用OSI CCR（Open Systems Interconnection Commitment
Concurrency和Recovery 標准）來命名
如果你要是用另外一種格式
那麼formatID應該大於零
值意味著Xid為無效
gtrid和bqual可以包含
個字節二進制碼來分別標識全局事務和分支事務
唯一的要求是gtrid和bqual必須是全局唯一的
此外
這可以通過使用指定在OSI CCR中的命名規則規范來完成
下面的例子說明Xid的實現
import javax
transaction
xa
*;
public class MyXid implements Xid
{
protected int formatId;
protected byte gtrid[];
protected byte bqual[];
public MyXid()
{
}
public MyXid(int formatId
byte gtrid[]
byte bqual[])
{
this
formatId = formatId;
this
gtrid = gtrid;
this
bqual = bqual;
}
public int getFormatId()
{
return formatId;
}
public byte[] g
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19232.html
