用於具有委託承諾特徵的事務處理的系統和方法
2023-06-04 13:13:31
專利名稱：用於具有委託承諾特徵的事務處理的系統和方法
技術領域：
總的來說，本發明涉及應用和事務伺服器，具體涉及用於允許事務或消息的委託承諾的系統。
優先權本申請要求下列申請的優先權2002年7月15日提交的第＿＿＿號美國實用新型申請「用於具有委託承諾特徵的事務處理的系統和方法」，2001年7月17日提交的第60/306,100號臨時申請「用於具有委託承諾特徵的事務處理的系統和方法」，2001年7月30日提交的第60/308,753號臨時申請「用於具有委託承諾特徵的事務處理的系統和方法」，這些申請在此通過引用併入。
交叉參考本申請涉及待審的實用新型申請2002年7月15日提交的第＿＿＿號「用於具有委託承諾特徵的事務處理的系統和方法」，發明人Edward P.Felt、Priscilla Fung、Alex Somogyi和Sriram Srinivasan；2002年7月15日提交的第＿＿＿號申請「用於具有同步回叫處理特徵的事務處理的系統」，發明人Edward P.Felt、Priscilla Fung、Alex Somogyi和Sriram Srinivasan；這些申請整體在此通過引用併入。
背景技術：
Java 2平臺企業版(J2EE)規範定義了用於開發多層企業應用程式的當前標準之一。J2EE提供了企業應用程式的設計、開發、彙編和部署的基於組件的方法，它降低了成本並且使開發者能專注於設計和實現。J2EE平臺向開發者提供了多層分布應用模型、重新使用組件的能力、統一的安全模型和靈活的事務控制。它們不僅可以比以往更快地向市場提供革新的客戶解決方案，而且所產生的獨立於平臺的、基於J2EE組件的解決方案不依附於任何廠商的產品和應用程式接口(API)。
J2EE規範定義了下列種類的組件應用客戶端組件、企業JavaBeans(EJB)、小服務程序(servlet)和Java伺服器網頁(JSP)(也稱為全球資訊網組件)和小應用程式(applet)。多層分布應用模型暗示應用邏輯按照功能被劃分為組件，並且不同的應用組件可以在同一或不同的伺服器上構成J2EE應用。在何處實際安裝應用組件依賴於所述應用組件屬於多層J2EE環境中的哪層。這些層被圖解在圖1中。如圖所示，應用伺服器層4用於開發EJB容器和/或表示容器，諸如小服務程序、JSP和html網頁14。它們繼而被用作在客戶層2和後端層6之間的接口，其中在所述客戶層2部署了客戶端8和客戶程序，而所述後端層6用作容納企業或傳統的應用程式，諸如企業資源計劃(ERP)系統。
客戶層-這可以是在公司防火牆內部或外部的客戶層內運行的瀏覽器、基於Java的程序或其他全球資訊網啟動的編程環境。
應用伺服器層-通常，這個層容納用於支持客戶請求的表示邏輯和商業邏輯的組合。經由顯示HTML網頁的JSP網頁和小服務程序來支持表示邏輯，經由遠程方法調用(RMI)對象和EJB 12來支持商業邏輯。EJB依賴於用於事務的容器環境、生存周期和狀態管理、資源池、安全等，它們一起構成其中執行bean的運行時間環境。
後端層-這一般是現有的應用程式和數據商店的組合。它也被稱為企業信息系統(EIS)層，因為它可以包括下述系統企業資源計劃(ERP)、主機事務處理、資料庫系統和其他傳統信息系統。
因為J2EE應用的組件獨立地並且經常在不同器件上運行，因此需要一種客戶和應用伺服器層代碼查找和引用其他代碼和資源的方式。客戶和應用代碼可以例如使用Java命名和目錄接口(JNDI)16來查找諸如企業bean之類的用戶定義的對象、諸如Java資料庫連接器(JDBC)數據源對象的位置和消息連接的環境項目，其中Java資料庫連接器(JDBC)數據源對象繼而用於查找在後端層中的資源。
可以在全球資訊網和企業bean組件的部署時間配置諸如安全和事務管理之類的應用行為。這個部署時間特徵從可能隨著彙編改變的配置設置分離(decouple)應用邏輯。J2EE安全模型讓開發者配置全球資訊網或企業bean組件，以便僅僅授權的用戶可以訪問系統資源。例如，全球資訊網組件可以被配置成提示輸入用戶姓名和密碼。企業bean組件可以被配置成僅僅在特定組中的人能夠調用某些種類的其方法。作為另一種選擇，一個小服務程序組件可以被配置成具有可以由每個人訪問的某些方法和僅僅可以由在一個組織中的某些有權限的人訪問的少量方法。同一小服務程序組件可以對另一個環境被配置成具有每個人可以獲得的所有方法，或者僅僅所選擇的一些人可以獲得的方法。
諸如加利福尼亞的San Jose的BEA系統公司的WebLogic伺服器之類的一些應用伺服器使用訪問控制列表(ACL)機制，它允許細微地控制在伺服器上運行的組件的使用。利用ACL，開發者可以在Java方法級定義哪個用戶或哪組用戶可以或不可以執行什麼。這個ACL機制涵蓋了除了EJB之外的、運行在應用伺服器上的任何內容，它們具有在EJB規範中定義的、各自的訪問控制機制。安全域使得管理員可以將來自現有的授權或認證系統的信息輸入到ACL中。
Java小服務程序小服務程序是擴展全球資訊網伺服器的功能的程序，小服務程序從客戶接收請求，動態地產生響應(可能是查詢資料庫來完成請求)，然後向客戶發送包括HTML或XML文件的響應。小服務程序類似於CGI(公共網關接口)，但是通常容易寫，因為小服務程序使用Java類和流。它們執行得更快，因為小服務程序被編譯為Java字節代碼，並且在運行時間，小服務程序被保存在存儲器中，每個客戶請求產生一個新的線程。小服務程序使得容易以動態方式產生對於HTTP響應流的數據。每個客戶請求作為新的連接被執行，因此流控制不自然地存在於請求之間。為了允許這個會話，管理維持在請求之間的特定客戶的狀態。在一些應用伺服器中，多個小服務程序利用HTTP會話對象來存儲它們在方法請求之間的狀態。為了在線恢復故障的目的，這個對象可以在成群環境中被複製。
Java伺服器網頁JSP網頁是用於開發小服務程序的基於文本的、以表示為中心的方式。JSP網頁提供了小服務程序的所有益處，並且當與JavaBeans類相結合時，提供使得內容和顯示邏輯分離的容易方式。與公共網關接口(CGI)相比較，JSP網頁和小服務程序更是所期望的，因為JSP網頁和小服務程序獨立於平臺並且使用較少的開銷。JSP網頁可以與JavaBeans類一起用來定義全球資訊網模板，所述全球資訊網模板用於建立具有類似觀感的、由網頁構成的網站。JavaBeans類執行數據翻譯，因此所述模板沒有Java代碼。這意味著所述模板可以由HTML編輯器來保存。可以使用利用JSP網頁的、簡單的基於全球資訊網的應用程式來將內容綁定到使用常規標籤或scriptlet而不是JavaBeans類的應用邏輯上。常規的標籤被捆綁為被輸入到JSP網頁的標籤庫。scriptlet是直接嵌入到JSP網頁中的小Java代碼段。
資料庫訪問業務(JDBC)JDBC作為到關係資料庫的橋梁，並且按ODBC(開放資料庫連接)規範成型。它通過使用驅動器來從程序代碼中分離資料庫。JDBC的一些實現方式提供對於高級數據類型的支持，並且也支持可滾動的結果集和批更新的功能。
Java消息傳遞服務(JMS)JMS是用於支持在Java程序之間的消息交換的J2EE機制。這有關於Java如何支持異步通信，其中發送者和接收者不必知道彼此，因此可以獨立地操作。JMS支持兩種消息傳遞模型點到點-它基於消息隊列。在這個模型中消息產生者向一個隊列發送消息。消息用戶可以將其本身附加到一個隊列以傾聽消息。當一個消息到達所述隊列時，用戶將其從隊列取出並且響應於它。消息可以僅僅向一個隊列發送並且由僅僅一個用戶使用。用戶具有指定它們需要的精確消息類型的過濾消息的選擇。
公布和申請-它使得產生者可以向一個主題發送消息，並且那個主體的所有註冊用戶可以檢索那些消息。在這種情況下，許多用戶可以接收到同一消息。
Java接口定義語言(IDL)CORBA對象使用IDL來指定合同，即它們如何與其他對象交互。利用Java IDL，可以在Java世界和CORBA世界之間定義合同。從Sun的JDK 1.2開始，包括ORB，它使得Java應用可以經由網際網路InterORB(IIOP)協議來調用遠程的CORBA對象。
企業JavaBeans(EJB)EJB組件被設計來封裝商業邏輯，以便開發者不必牽涉到用於諸如資料庫訪問、事務支持、安全、超高速緩存和並發之類的典型任務的編程代碼。在EJB規範中，這些任務是EJB容器的責任。一個企業bean包括接口和類。客戶通過企業bean的家庭和遠程接口來訪問企業bean方法。家庭接口提供了用於建立、去除和定位企業bean的方法，遠程接口提供了商業方法。在部署時間，所述容器從這些接口建立類，然後使用它們來向尋求建立、去除、定位和調用在企業bean上的商業方法的客戶提供訪問。企業bean類提供了商業方法、建立方法和探測器方法的實現；如果bean管理它本身的持續，則提供關於其生存期方法的實現。
存在兩種企業bean實體bean和會話bean。會話bean表示與客戶的短暫會話，並且可能執行資料庫讀寫。會話bean可以調用JDBC調用本身，或它可以使用實體bean來進行調用，在這種情況下，會話bean對於實體bean是客戶。會話bean的欄位包括會話的狀態並且是暫態的。如果伺服器或客戶崩潰，則會話bean消失。
實體bean表示在資料庫中的數據和對那個數據作用的方法。在僱員信息表的關係資料庫環境中，表中每行可以有一個bean。實體bean是事務型和生存期長的。只要數據保存在資料庫中，則實體bean存在。這個模型可以容易地用於關係資料庫，而不限於對象資料庫。
會話bean可以是有狀態的和無狀態的。有狀態的會話bean包括客戶的會話狀態。會話狀態是會話bean的實例欄位值外加可以從會話的bean的欄位達到的所有對象。有狀態的會話bean不表示在永久的數據存儲器中的數據，但是它們可以訪問和更新代表客戶的數據。無狀態會話bean沒有用於特定客戶的任何狀態信息。它們通常提供不維持任何特定狀態的伺服器端的行為。無狀態會話bean需要較少的系統資源。提供一般業務或表示被存儲的數據的共享視圖的商業對象是無狀態的會話bean的良好候選者。
使用所管理的容器的持續性來訪問關係資料庫的企業bean不要求開發者使用關於資料庫訪問的任何JDBC 2.0 API，因為容器處理這一點。但是，如果使用所管理的bean的持續性，或者如果需要訪問除了關係資料庫之外的企業信息系統，則必須提供用於如此的適當代碼。
在使用所管理的bean的持續性訪問資料庫的企業bean的情況下，必須實現具有JDBC 2.0 API代碼的bean的生存期方法來處理裝載和存儲數據，並且在運行時間和永久資料庫存儲器之間維持一致性。雖然全球資訊網層使用HTTP或HTTPS來在層之間傳送數據，但是EJB層使用RMI-IIOP。RMI-IIOP是全面(full-scale)分布式計算協議，它使得訪問企業bean的任何客戶或全球資訊網層程序可以直接訪問在EJB層中的業務。這些業務包括用於引用企業bean的JNDI、用於發送和接收異步消息的Java消息傳遞業務(JMS)和用於關係資料庫訪問的JDBC。
事務管理諸如WebLogic伺服器系統之類的任何應用伺服器的最基本特徵之一是事務管理。事務是用於保證資料庫事務被精確地完成並且它們採用高性能事務的所有「ACID」屬性的手段，包括原子性-事務對資料庫做出的所有改變是永久做出的，否則所有改變被退回重來。
一致性-成功的事務將資料庫從前一個有效狀態變換到新的有效狀態。
隔離-事務對資料庫做出的改變對於其他操作是不可見的，除非事務完成其工作。
持久性-事務對資料庫做出的改變經受得住未來系統或媒體故障的考驗。
J2EE事務模型讓應用開發者在部署時間指定包括單個事務的方法之間的關係，因此在一個事務中的所有方法被作為單個的單元。這是所期望的，因為一個事務是必須全部完成的一系列步驟，或者如果它們未全完成，則所有都返回。例如，開發者可能具有在通過將第一個帳戶作為借方，並且將第二帳戶作為貸方來從一個銀行帳戶向另一個轉帳的企業bean中的一系列方法。在這個實例中，它們要將整個傳輸操作作為一個單元，以便如果出現在借之後和在貸之前的失敗，則借退回重來。
彙編期間在應用組件上指定事務屬性，使得開發者可以將方法編組為跨應用組件的事務。以這種方式，可以在J2EE應用中改變應用組件，並且可以不改變代碼而重新分配事務屬性。Java事務業務(JTS)和Java事務API(JTA)形成J2EE中，具體地說，是用於EJB和JDBC 2.0的事務支持的基礎。JTS規範是用於事務管理的底層應用程式接口(API)，它將Java映射為對象管理組(OMG)對象事務服務。JTA規範是Sun Microsystems公司與事務處理和資料庫系統業內的領先的工業合作夥伴合作開發的，並且指定了在事務管理器、資源管理器、應用伺服器和事務應用之間的標準Java接口。具體地說，JTA是包括下列兩個部分的高層API事務接口-它使由分布式組件完成的工作能夠由全局事務來約束，並且是標註或識別構成一個事務的操作的組的方式。
XA資源接口-它是基於X/Open或XA接口的接口，它使能處理分布式事務。這涉及在多個資源上的事務的協調，諸如在資料庫或隊列內或之間的協調。
多數時間，開發者不必關心使用JTA來編程明確的事務，因為這個工作是通過JDBC和EJB API來執行的，所述JDBC和EJB API由容器處理並且由應用部署描述符配置。開發者可以不把精力放在事務的設計上，而是放在其實現上。
WebLogic伺服器支持用於企業應用的分布式事務和兩階段承諾(two-phase commit)協議。分布式事務是以協作的方式更新多個資源管理器(諸如資料庫)的事務。相反，本地的事務更新單個資源管理器。兩階段承諾協議是在兩個或多個資源管理器上協調單個事務的方法。它通過下列方式來保證數據的完整性保證在所有參與的資料庫中承諾事務的更新，或者將事務的更新離開所有的資料庫返回，返回到事務開始之前的狀態。換句話說，或者所有的參與資料庫被更新，或者它們都不被更新。分布式事務涉及下列參與者事務始發者-啟動事務。事務始發者可以是用戶應用、企業JavaBean或JMS客戶。
事務管理器-管理代表應用程式的事務。事務管理器通過與在那些事務中參與的所有資源管理器通信來協調來自應用程式的命令，以便開始和完成事務。當在事務期間資源管理器故障時，事務管理器幫助資源管理器確定是否承諾或返回待決的事務。
可恢復資源-提供數據的永久存儲。所述資源通常是資料庫。
資源管理器-提供對信息和處理的集合的訪問。
知道的事務的JDBC驅動器是公共資源管理器。資源管理器提供事務能力和行為的持久性；它們是在分布式事務內被訪問和控制的實體。在資源管理器和特定資源之間的通信被稱為事務分支。
兩階段承諾協議的第一階段被稱為準備階段。在事務日誌文件中記錄所需要的更新，並且資源必須通過資源管理器指示準備好進行改變。資源可以或者選擇承諾更新或者返回到前一個狀態。在第二階段中能發生的內容依賴於資源如何選擇。如果所有資源選擇承諾，則更新參與事務的所有資源。如果一個或多個資源選擇返回，則參與事務的所有資源返回其前一個狀態。
對商業事務的支持事務在下述的實例情況下是適當的(雖然這些情況僅僅是說明性的而不是窮舉性的)。
作為第一個實例，客戶應用需要對幾個對象進行調用，這可能涉及到向一個或多個資料庫的寫入操作。如果任何一個調用不成功，則被寫入(或者在存儲器中，或者更典型的是向資料庫)的狀態必須退回重來。例如，考慮一個旅行社的應用。客戶應用需要安排到遠處的行程；例如從法國的Strasbourg到澳大利亞的Alice Springs。這樣的行程將不可避免地需要多個獨立的飛機預訂。客戶應用通過依序預定行程的每個獨立段而工作；例如，Strasbourg到巴黎、巴黎到紐約、紐約到洛杉磯。但是，如果不能進行任何一個獨立的飛機預訂，則客戶應用需要取消對那個點做出的所有飛機預定的方式。客戶應用需要與由伺服器應用管理的對象進行對話，並且客戶應用需要對特定的對象實例做出多個調用。所述對話的特徵在於下面的一個或多個在每個連續的調用期間或之後，數據被緩存在存儲器中或被寫入到資料庫中，在會話結束時將數據寫入資料庫，客戶應用需要對象來在每個調用之間保持一個在存儲器中的環境；即，每個連續的調用使用在整個會話中一直保持在存儲器中的數據，在會話結束時，客戶應用需要能夠取消可能已經在會話期間或之後發生的所有資料庫寫入操作。
作為一個替代的實例，考慮基於網際網路的在線購物小車(cart)應用。客戶應用的用戶通過在線目錄瀏覽並且進行多個購買選擇。當用戶完成選擇他們要購買的多個項目的時候，它們結帳並且輸入它們的信用卡信息來進行購買。如果信用卡結帳失敗，則購物應用需要取消在購物小車中的所有待決的購買選項的機制，或者退回在會話期間進行的任何購買事務。在對於一個對象的單個客戶調用的範圍內，所述對象對在資料庫中的數據執行多個編輯。如果編輯之一失敗，則所述對象需要將所有的編輯退回。(在這個情況下，獨立的資料庫編輯不是必要的EJB或RMI調用。諸如小應用程式之類的客戶可以使用JNDI獲得對Transaction和TransactionManager對象的引用，並且開始一個事務)。作為另一個示例，考慮銀行業應用。客戶在出納對象上調用傳送操作。所述傳送操作需要出納對象對銀行資料庫進行下列調用調用對一個帳戶的借款方法；以及調用對另一個帳戶的貸款方法。如果對銀行資料庫的貸款調用失敗，則銀行業應用需要將前一個借款調用退回的機制。
對於如上所述的事務管理的傳統方法的一個問題是，它們不允許無足輕重的客戶可靠地參與事務處理中。在此使用的無足輕重的客戶通常是在單用戶的、難管理的臺式系統上運行的客戶，而所述臺式系統具有不規範的可利用性。例如，PC(個人計算機)或臺式擁有者可以當它們的臺式系統不在使用時關斷它們的臺式系統。理想情況下，應當不要求這些單用戶的、難管理的臺式系統來執行複雜和必要的網絡功能，諸如事務協調。具體地說，難管理的系統應當不負責保證期望涉及伺服器資源的事務的原子性、一致性、隔離和耐久性(ACID)屬性。需要這樣一種機制，它從客戶去除這樣的責任的負擔，並且輔助事務承諾過程，同時保證整體的事務完整性。
發明內容
本發明允許客戶在事務處理系統中執行委託的承諾，即向通常是伺服器的另一個實體委託事務的承諾階段。委託的承諾使得無足輕重的客戶開始事務，管理活動部分，然後終止事務，而用於事務承諾處理的實際責任被委託到在伺服器上運行的事務管理器過程。以這種方式，客戶應用不需要本地的事務伺服器。相反，客戶使用的UserTransaction的遠程實現將事務協調的實際責任委託到在伺服器上的事務管理器。
這樣的機制的益處包括允許客戶在事務的活動階段期間直接涉及多個伺服器，而原子地承諾事務的重要任務被委託給通常比客戶本身更可靠的被管理的伺服器。
在典型的事務的生存期期間，存在幾個狀態轉換，包括在活動、交接、預備、準備、記錄和承諾狀態之間的轉換。按照本發明，在活動狀態期間，運行在客戶上的應用代碼在事務的執行期間接觸幾個伺服器。客戶負責記住接觸了那些伺服器。在一個實施例中，所接觸的第一伺服器被指定為「承諾」伺服器。當客戶要求「承諾」時，向承諾伺服器委託(即交接)用於承諾事務的責任。所述承諾伺服器通過預備、準備、記錄和委託步驟來移動事務。當承諾處理完成時，承諾伺服器返回客戶。除了承諾伺服器負責處理承諾之外，它還可以是正常的伺服器，並且在許多情況下，任何一個伺服器都可以承擔委託伺服器的角色。哪個伺服器實際上結束於(end up with)所述責任(因此變為「承諾伺服器」)依賴於實際的實現方式。
客戶可以使用JNDI來獲得對UserTransaction和TransactionManager對象的引用，並且可以使用任何一個對象引用來開始事務。為了獲得當前線程的Transaction(事務)對象，客戶程序調用getTransaction方法。從JNDI返回的Transaction對象支持UserTransaction和TransactionManager接口。
本發明通過下述方式來保證事務完整性保證承諾將不成功，除非在事務中涉及的所有事務對象已經完成了它們相應的事務請求的處理。事務服務提供等效於由標準請求/響應過程間通信模型所提供的被查看事務行為，所述標準請求/響應過程間通信模型由OpenGroup(OMG)規範定義。
本發明的一個實施例包括用於事務處理的系統，它委託對客戶和伺服器之間的事務委託過程的責任，所述伺服器包括一個事務接口，它從客戶接收要在伺服器中承諾的事務；多個接收所述事務的伺服器，其中包括至少一個要參與到所述事務中的參與伺服器和從所述多個伺服器中選擇為承諾伺服器的一個伺服器，所述作為承諾伺服器的伺服器在所述至少一個參與伺服器上承諾所述事務，並且向所述客戶處理傳達所述事務承諾處理結果。本發明的另一個實施例包括一種用於客戶和伺服器之間的事務處理的方法，它允許將在客戶和伺服器之間的事務的責任委託給承諾伺服器，所述方法包括步驟從客戶接收要在伺服器中承諾的事務；從多個伺服器中確定一個承諾伺服器，所述承諾伺服器負責承諾所述事務；並且在參與伺服器上承諾所述事務，並且將所述承諾結果向所述客戶傳達。
圖1示出了在現有技術中已知的J2EE結構的圖解。
圖2示出了按照本發明的一個實施例的委託承諾特徵的圖解。
圖3示出了用於本發明的典型客戶-伺服器系統的圖解。
圖4示出了按照本發明的一個實施例的各種事務狀態的圖解。
圖5示出了包括承諾伺服器的、按照本發明的一個實施例的事務委託承諾系統的第一圖解。
圖6示出了包括承諾伺服器的、按照本發明的一個實施例的事務委託承諾系統的第二圖解。
圖7示出了按照本發明的一個實施例的事務委託承諾處理的流程圖。
圖8示出了按照本發明的一個實施例的兩階段承諾處理的示意圖。
圖9a和9b示出了按照本發明的一個實施例的客戶事務狀態機的示意圖。
圖10示出了按照本發明一個實施例的協調狀態機的示意圖。
圖11a和11b示出了按照本發明的一個實施例的子協調器狀態機的示意圖。
圖12示出了按照本發明的一個實施例的開始事務生存期的圖解。
圖13示出了按照本發明的一個實施例的事務傳播生存期的圖解。
圖14示出了按照本發明的一個實施例的委託生存期的圖解。
具體說明本發明提供了一種系統和方法，用於允許客戶或客戶應用在一個事務或事務處理系統中執行委託的承諾。這個處理允許客戶開始和終止事務，而對事務委託處理的實際責任被委託到在伺服器上運行的事務管理器。因此，客戶應用不需要作為當客戶是無足輕重的客戶時的重要特徵的本地事務伺服器。由客戶使用的用戶事務的遠程實現將事務協調的責任委託給在所選擇的伺服器上的事務管理器。
這樣的機制的益處包括在事務的活動階段期間允許客戶直接涉及多個伺服器，同時原子地(atomically)承諾事務的關鍵工作被委託給通常比客戶更可靠的被管理伺服器。當客戶是無足輕重的客戶時尤其是這樣，所述無足輕重的客戶諸如用戶的臺式機，它比企業級伺服器更易於出現故障或差錯。
圖2圖解了本發明的一個實施例的示意圖，其中客戶應用向多個伺服器之一委託用於協調事務的責任。如圖2所示，包括客戶應用104的客戶102啟動或開始涉及至少一個或多個伺服器的事務，所述伺服器包括伺服器A106、伺服器B 108、伺服器C 110和伺服器D 112。在活動階段120期間，客戶可以在事務委託階段之前從事務處理增加一個伺服器。因此，例如，事務可以首先包括一個伺服器A 122或在那個伺服器上的資源，但是在活動階段期間的稍後的時間，客戶應用可以指定所述事務應當也包括伺服器A和B124。每個獨立的事務被從可能的伺服器/協調器的池中分配到事務協調器或「承諾伺服器」。在圖2所示的示例中，伺服器A 106被選作事務協調器/承諾伺服器，儘管伺服器A、B、C或D中的任何一個顯然可以被等效地選作事務協調器。當最後承諾事務時，事務協調器將負責協調實際事務，從客戶去除這個負擔。如圖2所示，在事務被承諾時，如此被選作事務協調器的伺服器保存準備狀態信息126，所述準備狀態信息126將啟動事務協調器承諾事務。在開始委託階段130期間，客戶應用向事務協調器或作為事務協調器的伺服器發送承諾請求132。在委託承諾階段140期間，作為事務協調器的伺服器(在這種情況下是伺服器A 106)負責向被指定為事務環境的一部分的伺服器承諾事務142(在這種情況下是伺服器A 106和B 108)。不需要客戶或客戶應用來參與承諾處理。以這種方式，客戶可以是無足輕重的客戶，因為它不必參與任何承諾處理。事務協調器具有用於承諾事務所需要的所有信息。
雖然在圖2中可以看出伺服器A被選作事務協調器，但在實際中存在可用於選擇或指定伺服器來作為事務協調器的許多技術。在一些實現情況中，客戶可以選擇與事務協調器連接的第一伺服器。在其他實現方式和實施例中，可以按照特定的規則或算法來從多個伺服器之一選擇事務協調器。在活動階段期間，客戶向事務協調器傳送關於哪個伺服器應當參與事務的信息，以便可以隨後在委託階段期間使用所述信息。在一個實現方式中，每個伺服器實質是相同的，並且任何伺服器可以作為事務協調器。在其他實現方式中，一些伺服器可以被指定為事務協調器。在Java事務應用(JTA)的環境中，JTA可以在被稱為事務環境的數據結構中記住事務數據。這個事務環境被傳播到所選擇的事務協調器。數據結構/事務環境包括在承諾階段中隨後使用的所有必要信息，其中包括事務協調器ID。
圖3示出了用於本發明的典型客戶-伺服器系統的圖解。遠程設備或應用202——通常被稱為客戶應用——與應用伺服器204通信，或更典型的是與在應用伺服器駐留的應用通信。在客戶端，事務管理器206被客戶應用用來向伺服器(或向許多伺服器)發送和接收事務208。類似地，在伺服器端，事務管理器210被用於管理客戶的事務。在一個實施例中，伺服器也可以邏輯地包括用於啟動事務的事務協調器處理214、用於監控事務狀態的子協調器處理216和用於記錄事務的事務記錄器處理218。當事務發生時，它們可以被記錄到資料庫220上的事務日誌中以用於以後的審察、引用或退回目的。需要「事務日誌」來用於事務恢復，以保證事務通過系統故障被原子地承諾。顯然事務協調器、子協調器和記錄器處理器中的每個全部可以運行在同一伺服器或不同的伺服器上。在一個實施例中，由客戶達到的第一伺服器自動擔當協調器的角色。其他實現和其他實施例可以使用不同的用於選擇協調器的方法。
圖4示出了在事務生存期上的各種狀態或階段，包括活動302、交接(hahdoff)304、預備(pre-preparing)306、準備(preparing)308、記錄310和承諾312狀態。因此，在任何事務的生存期期間，存在幾個狀態轉換，包括在活動、交接、預備、記錄和委託狀態之間的轉換。在活動狀態中，在客戶上運行的應用或應用代碼被設計來在事務的實際執行期間接觸幾個伺服器。客戶負責記住接觸那些伺服器，並且有時負責記住關於事務的其他細節。按照本發明的一個實施例，所接觸的第一伺服器被指定為承諾伺服器或事務協調器。當客戶調用「承諾」時，用於承諾事務的實際責任被委託或交接到承諾伺服器。除了承諾伺服器負責處理所述承諾之外，它還可以是正常的伺服器，並且在許多情況下，任何伺服器可以擔當承諾伺服器的角色。哪一個實際上結束於所述責任(因此變為「承諾伺服器」)依賴於實際的實現方式。
圖5示出了按照本發明的一個實施例的事務委託承諾系統的第一圖解。當客戶402試圖與處理事務通信時，可以將408、410接觸多個伺服器(404，406)以確定哪個將實際處理所述事務。在一些實施例中，在多個伺服器內的每個伺服器(404，406)可以作為承諾伺服器或參與伺服器。由本發明提供的系統在所使用的伺服器的數量和類型上是靈活的。在一個實施例中，所接觸的第一伺服器(在圖5的示例中伺服器A404)變為承諾伺服器和協調器。其他伺服器(即圖5中的伺服器B406)因而僅僅被當作參與伺服器。其他實現可以使用替代機制來選擇承諾伺服器。
圖6示出了按照本發明的一個實施例的同一事務委託承諾系統的第二圖解。在前一個步驟中選擇的承諾伺服器現在負責處理承諾處理。事務處理由客戶402和承諾伺服器404之間的通信412單獨處理，而不需要該客戶和參與伺服器406之間的進一步通信。承諾伺服器處理一個參與伺服器406(如果事務涉及多個參與伺服器則為多個伺服器)的所有事務處理414。承諾伺服器通過在那些參與伺服器上的預備、準備、記錄和承諾步驟來移動事務。當承諾處理完成時，承諾伺服器向客戶返回承諾。
圖7示出了按照本發明的一個實施例的事務委託承諾處理的流程圖。如圖7所示，客戶或客戶應用接觸多個事務或應用(步驟502)伺服器。一個承諾伺服器被指派來執行特定的事務，按照一個實施例，所述伺服器通常是客戶進行第一調用的伺服器。在一些點(步驟506)，客戶應用將調用委託處理。所述承諾伺服器在所述一個參與伺服器或多個參與伺服器上處理事務(步驟508)。當委託處理完成時，承諾伺服器返回客戶。
客戶處理(例如一個小應用程式)可以使用標準JNDI接口來獲得對UserTransaction和TransactionManager對象的引用。客戶可以使用任一個對象引用來開始事務。
被查看的事務行為通過下列方式來提供事務完整性保證一個承諾將不成功，除非在事務中涉及的所有事務對象已經完成了它們的事務請求的處理。事務服務提供與由Open Group(開口組)定義的請求/響應處理間通信模型所提供的等效的被查看事務行為。
圖8示出了按照本發明的一個實施例的、可以使用兩階段承諾處理的系統的示意圖。客戶或客戶應用602使用例如承諾功能來調用事務承諾604。事務請求被傳達到多個伺服器606。這些伺服器610之一被選作用於這個特定事務的承諾伺服器。對於事務承諾的責任被交接到那個承諾伺服器610。在一個實施例中，承諾伺服器向盤614寫入這個事務，在此其他伺服器(參與伺服器)可以將其拾取或對其操作。記錄事務是兩階段委託協議的一部分，並且目的是在存在系統故障時保證事務的原子性。例如，如果在第二承諾階段期間協調伺服器崩潰，則在所述伺服器重啟後，可以利用所記錄的事務來完成所述第二階段。如果必要的話，如果事務失敗，則承諾伺服器也處理任何退回功能616。當完全承諾事務時，承諾伺服器將承諾618返回客戶或調用應用602。
圖9-11示出了本發明的一個實施例的狀態機圖。這些狀態圖表示可能在事務承諾生存期期間在一個事務上發生的各種操作。在圖9-11中，實線指示成功的操作，而虛線指示不成功的(並且最後被退回重來的)操作。
圖9a和9b示出了按照本發明的一個實施例的客戶事務狀態機的示意圖。在圖9a中，從客戶或客戶應用來看，事務通過活動階段702並且被承諾708或者被退回710。預備階段704和準備階段706對於客戶基本上是不可見的。圖9b從全局的角度圖解了類似的處理，並且包括幾個事務分支。在這個示例中，準備階段716查看準備事務的幾個分支。如果它們全被準備，則事務被記錄或寫入盤(718)。否則，作為整體的事務被退回710。
圖10示出了按照本發明的一個實施例的事務協調器狀態機的示意圖。從事務協調器的角度來看，必須將事務交接到兩階段或委託承諾處理，或者它必須被退回。在活動階段802期間，應當被退回的事務被標註804以退回806，並且最終被退回808。應當承諾的事務被發送到兩階段承諾處理810，並且最後被承諾812。在兩階段承諾處理期間，任何失敗的事務被加到退回列表中，並且最終被退回。
圖11a和11b示出了按照本發明的一個實施例的子協調狀態機的示意圖。子協調器負責通過預備902、準備906、已準備好910和承諾階段912來看見事務。附加步驟可以在一些實施例中用於確認事務正在被準備904，並且用於向事務日誌908記錄這個已準備好狀態。
圖12-14圖解了按照本發明的一個實施例的事務相關聯的生存期。圖12示出了按照本發明的一個實施例的開始事務生存期的圖解。事務管理器1002使用協調器定位器1004來找到用於這個特定事務的事務協調器1006，並且獲得事務ID。這個事務ID隨後被簡單的函數用來產生事務1008。在本發明的其他實施例中，取消getCoordinator 1004和獲得事務(reservedXID)1006步驟，並且事務管理器1002分配它自己使用偽隨機數構造的事務標識符。
圖13示出了按照本發明的一個實施例的事務傳播生存期的圖解。客戶應用1102利用事務管理器1104來向客戶Java虛擬機1106傳送一個事務，所述客戶Java虛擬機1106處理向在遠程伺服器的相應或類似伺服器Java虛擬機1108的事務的通信。遠程伺服器包括與伺服器應用1112通信的事務管理器1110。伺服器事務管理器1110負責發送事務承諾請求，並且向客戶發送回答。
圖14示出了按照本發明的一個實施例的承諾生存期的圖解。在接收到事務承諾請求時，伺服器事務管理器1202向事務協調器1204傳送承諾請求。當承諾被處理時，事務管理器1202向客戶或客戶應用返回承諾。
本發明的上述說明是為了圖解和說明目的提供的。它不意欲是窮盡的或將本發明限定到所公開的精確形式。顯然，許多修改和變化形式對於本領域技術人員是顯然的。所述實施例被選擇和說明以便最好地說明本發明的原理和其實際應用，因此使得本領域技術人員能夠明白各種實施例和適合於所考慮的特定用途的各種修改的本發明。意欲可以通過所附的權利要求和它們的等同物限定本發明的範圍。
權利要求
1.一種用於事務處理的系統，它用於在客戶和伺服器之間委託事務承諾處理的責任，包括事務接口，它從客戶接收要在伺服器承諾的事務；多個伺服器，它接收所述事務，包括至少一個要參與所述事務的參與伺服器；伺服器，它從多個伺服器被選擇為承諾伺服器，它在所述至少一個參與伺服器上承諾所述事務，並且向所述客戶處理傳達所述事務承諾處理結果。
2.按照權利要求1的系統，其中所述客戶包括活動階段，在此活動階段期間，系統監控和記錄參與事務的伺服器的子集。
3.按照權利要求2的系統，其中所述多個伺服器中被接觸的第一伺服器被選作承諾伺服器。
4.按照權利要求1的系統，其中所述承諾伺服器在所述參與伺服器中通過準備、記錄和承諾階段來移動所述事務。
5.按照權利要求1的系統，其中承諾伺服器向客戶處理返回承諾。
6.按照權利要求1的系統，其中承諾伺服器包括用於在承諾之前存儲所述事務的事務存儲器。
7.按照權利要求6的系統，還包括退回處理器，用於在所述事務未能在所述參與伺服器承諾時將所述事務退回。
8.按照權利要求1的系統，其中所述多個伺服器中的任何一個包括事務協調器。
9.按照權利要求1的系統，其中所述事務接口擴展Java事務接口。
10.按照權利要求1的系統，其中所述客戶包括活動階段，在所述活動階段期間，系統保存一個限制所述事務的活動階段的計時器，如果所述事務在指定的超時間隔內未結束則退回所述事務。
11.按照權利要求1的系統，其中所述客戶包括活動階段，在所述活動階段期間，系統跟蹤與伺服器的所有通信，並且保證當承諾所述事務時沒有任何未完結的通信請求。
12.一種用於客戶和伺服器之間的事務處理的方法，它允許向承諾伺服器委託對客戶和伺服器之間的事務的責任，包括步驟從客戶接收要在伺服器承諾的事務；從多個伺服器確定一個承諾伺服器，所述承諾伺服器負責承諾所述事務；在一個參與伺服器上承諾所述事務，並且向所述客戶傳達所述承諾的結果。
13.按照權利要求12的方法，其中所述客戶包括活動階段，在此活動階段期間，管理器定位器接觸所述多個伺服器的子集。
14.按照權利要求13的方法，其中所述多個伺服器中被接觸的第一伺服器被指定為承諾伺服器。
15.按照權利要求12的方法，其中所述承諾伺服器在所述參與伺服器中通過準備、記錄和承諾階段來移動所述事務。
16.按照權利要求12的方法，其中所述承諾伺服器向客戶返回承諾。
17.按照權利要求12的方法，其中所述承諾伺服器包括用於在承諾之前存儲所述事務的事務存儲器。
18.按照權利要求17的方法，還包括退回處理器，用於在所述事務未能在所述參與伺服器承諾時將所述事務退回。
19.按照權利要求12的方法，其中所述多個伺服器中的每個都擔任事務協調器。
20.按照權利要求12的方法，其中所述事務接口擴展Java事務接口。
21.按照權利要求12的方法，其中所述客戶包括活動階段，在所述活動階段期間，系統保存一個限制所述事務的活動階段的計時器，如果所述事務在指定的超時間隔內未結束則退回所述事務。
22.按照權利要求12的方法，其中所述客戶包括活動階段，在所述活動階段期間，系統跟蹤與伺服器的所有通信，並且保證當承諾所述事務時沒有任何未完結的通信請求。
23.按照權利要求1的方法，其中參與伺服器也是承諾伺服器。
24.按照權利要求1的方法，其中參與伺服器不是事務協調器。
25.按照權利要求12的方法，其中參與伺服器也是事務協調器。
26.按照權利要求12的方法，其中參與伺服器不是事務協調器。
27.按照權利要求26的方法，其中所述參與伺服器是所述多個伺服器中的另一個。
全文摘要
本發明提供了一種事務(transaction)業務，它使得無足輕重的客戶可以在伺服器(106－112)上執行委託的承諾(delegated commit)(140)。這個處理使得無足輕重的客戶(102)可以開始和終止事務，同時將用於事務承諾處理的實際責任委託(delegate)給事務協調器和在位於所述伺服器上的機器上運行的事務管理器。客戶應用(102)不需要本地的事務伺服器。可以從客戶可訪問的多個伺服器中選擇承諾伺服器，並且承諾伺服器負責向參加所述事務的其他(參與)伺服器承諾事務。
文檔編號G06F12/00GK1606738SQ02816834
公開日2005年4月13日 申請日期2002年7月16日 優先權日2001年7月17日
發明者愛德華·P·費爾特, 普裡西拉·馮, 亞歷山大·J·索莫吉, 斯裡拉姆·斯裡尼範桑 申請人:Bea系統公司