具有備份恢復功能的ＯＴＳ設計與實現

摘要：提出一種對象事務服務器備份恢復模型，并結合CORBA的OTS標準實現了一個具有恢復管理功能的CORBA對象事務服務器。結果表明，該事務服務器除了具有OMG規范規定的功能外，還具有事務數據在線備份及意外失敗后恢復的功能。

關鍵詞：分布式計算； 公共對象請求代理體系結構； 對象事務服務； 備份與恢復； 事務； 兩階段提交協議

中圖分類號：TP311文獻標志碼：A

文章編號：1001-3695(2007)12-0220-03

CORBA是由對象管理組所提出的一種規范^[1]。OMG的COSS標準^[2]定義了大約16種公共對象服務。這些服務是CORBA為使用和維護對象系統而提供的基本服務集合。它們獨立于應用領域，是分布式對象程序使用的接口。OTS^[3]是OMG組織推出的一種COSS服務，它保證了企業應用中事務性操作的原子性和持久性，對構建高可靠性應用，特別是要求并發訪問共享數據的分布式應用起著關鍵作用。

在事務服務器處理事務的過程中，可能會因為斷電等故障而導致事務服務器的崩潰。為了維護數據的一致性，就應該有一種完善的機制保證事務的重新啟動和恢復。文獻[4~6]實現了幾種不同特點的事務服務器，但是實現的事務服務器沒有考慮恢復功能；文獻[7]討論了分布式事務處理中的事務失敗恢復，但是沒有給出具體的實現。本文提出了一種事務服務器意外失敗恢復模型，并且結合OTS規范在Orbas^[8]的ORB上實現了一個具有恢復管理功能的事務服務器。

1總體設計

如圖1所示，org.omg.CosTransactions包中是OTS各接口的POA框架類和碼根類。Orbas.OTS中的類均繼承自該包的POA框架類。Orbas.OTS包還要調用org.omg.CORBA包和orb內核子系統。Orbas.TransRecovery包是備份恢復管理模塊，事務服務器在進行事務處理的過程中須與該模塊聯系進行事務數據的動態備份；同樣，當事務服務器失敗后重啟時，備份恢復模塊主導整個事務服務器的恢復過程，在此過程要頻繁地與OTS模塊交換信息。

2OTS模塊的設計與實現

2．1OTS接口定義

圖2描述了OTS接口：

Current 接口中定義了控制和管理事務的操作，可以開始和結束一個事務，通過Current 可以獲得當前事務的相關信息。

TransactionFactory 接口中定義了兩個操作，即create和recreate。前者可以生成一個新的頂層事務；后者可以生成一個PropagationContext，定義已存在事務的新代表，并返回一個Control 對象。

Control 接口允許一個程序顯式地管理或者隱式地傳播一個事務上下文。該接口定義了兩種操作，即get_terminator和get_coordinator。前者返回一個Terminator對象，該對象支持結束事務的操作；后者返回一個Coordinator 對象，以支持相關資源參與到事務所需要的操作。

Terminator接口提供提交和回退事務的操作。一般由事務的發起者調用這些操作。

Coordinator接口提供一個分布式對象參與到事務所需要的操作。這些參與者既可以是可恢復對象，又可以是可恢復對象的代理。

RecoveryCoordinator提供了可恢復對象恢復自身的接口。

Resource接口是資源接口，可恢復服務器繼承此接口，以參與兩階段提交協議。

Synchronization接口是繼承自TransactionalObject接口，因此它是個特殊的事務對象，它的某些數據依賴資源對象。如果一個事務對象的數據本身雖然不是資源，但是它需要在資源中改變數據時得到通知，這時，該事務對象可以實現Synchronization接口，并將自己注冊在Coordinator上。這樣在兩階段協議開始或者結束時，分別調用Synchronization中的before_completion和after_completion操作進行相應的處理。

2．2OTS實現

OTS靜態類圖如圖3所示。

CurrentImpl是事務型應用程序和OTS交互的橋梁。它提供了事務服務中常用的API，是對事務進行直接管理的基礎。它包括發起和終止一個事務，獲得當前的事務狀態，獲得與設置事務的上下文、設置事務的超時、掛起和恢復一個事務等。TransactionFactoryImpl用于創建ControlImpl，這樣就構建起整個事務處理的上下文。ControlImpl在其構造函數中根據傳入的time_out等各個參數創建CoordinatorImpl和TerminatorImpl。CoordinatorImpl用來登記資源和同步對象，用兩個向量分別存儲注冊到該Coordinator的資源和同步對象。

TerminatorImpl是兩階段提交協議的具體執行者。當事務型應用程序發出commit操作時，將使所有與事務相關的資源執行兩階段提交協議。圖4展示了兩階段提交的整個過程。

TimeOutControl用于控制事務的超時，它繼承于java.lang.Thread。在事務上下文被創建時設置啟動，然后線程休眠time_out設定的時間。如果在規定的時間內事務還沒有對其進行提交，定時器將執行回退操作。

org.omg.CosTransactions.Resource和org.omg.CosTransactions.Synchronizations是資源對象和同步對象在其客戶端的對象引用，它們注冊到CoordinatorImpl上并被其管理。

3備份恢復模塊設計與實現

在OTS服務器進行事務處理的過程中，可能會出現斷電等故障而導致意外失敗。為了維護數據的一致性，OTS服務器應具有意外失敗后自我恢復的能力。本文提出了OTS服務器的一種備份恢復模型，如圖5所示。具體分為兩個階段：a)在OTS服務器運行過程中，OTS模塊與備份模塊協作，采用事務日志的方式動態地記錄事務運行的過程，即OTS的動態備份階段；b)當事務服務器意外失敗而重啟后，恢復管理模塊根據動態備份的事務日志信息與OTS模塊協作進行事務的恢復，即OTS的恢復階段。

3．1事務數據的動態備份

事務在運行的過程中，每當進行狀態的轉換和其他重要的事件，如注冊資源、提交資源、準備好資源等時都將必要的信息通過LogWriter寫入日志。如圖5所示，OTS在適當的時機調用LogWriter寫入日志。問題的關鍵是寫入日志的時機及日志的格式。

3．1．1日志寫入時機

要確定日志寫入的時機，需要分析事務服務器運行過程中的重要的狀態點。事務的九種狀態及其變遷過程如圖6所示。

應用程序開始一個事務，創建事務上下文，事務的狀態變為StatusActive；OTS和參與事務的各個資源聯系，進入兩階段提交協議的prepare階段，事務的狀態轉變為StatusPreparing；如果各個資源投票通過，事務狀態轉變為StatusPrepared；接著將進入兩階段提交協議的commit階段，事務狀態轉變為StatusCommitting；如果提交成功，事務狀態變為StatusCommitted；在準備階段出現某個資源投票未通過，事務狀態變為StatusRollingBack；回退結束，事務狀態變為StatusRolledBack；如果事務標記為回退，事務狀態變為StatusMarkedRollback。

參照以上事務的狀態變遷過程，根據各個狀態點，給出事務日志記錄的時機如表1所示。

3．1．2日志格式

事務日志的格式如下：transcation_id，nested_trans_id，phase，resource，vote，status，time。其中，phase是表1中的14個可能值中的一個；而transaction_id是事務的惟一性標志；nes－ted_trans_id為嵌套事務的惟一性標志；resource是該事務涉及的資源對象的IOR(interoperable object reference，可互操作對象引用)；vote為事務投票的結果；status為事務相應的狀態，取值為圖6中九種狀態中的一種；time為日志記錄的時間。

3．2事務的恢復

當事務服務器意外失敗而重新啟動后，RecoveryManager負責判斷OTS在失敗時的狀態，而進行相應的回退或者繼續提交的操作。RecoveryManager與LogMonitor聯系得以決定是否進行事務恢復。如果需要恢復，LogMonitor與LogReader聯系從Logs中讀出并解析相應的信息。RecoveryManager在實施恢復的過程中需要與OTS模塊進行交互。例如根據日志中得到的資源IOR調用CoordinatorImpl中的register_resource操作進行注冊等。RecoveryManager進行恢復的具體過程如圖7所示。它描述了恢復事務的整個過程。從圖7中可以看出，只要當事務服務器崩潰時，事務的狀態是_StatusPrepared或者_StatusCommitting， 并且日志記錄沒有回退的資源時，恢復管理器

才執行事務的繼續提交。因為此時能肯定事務已經成功完成了兩階段提交協議，在別的情況下要執行事務的回退。

4結束語

事務處理是分布式應用中特別是企業應用中需要處理的一個重要問題。在開發機械第九設計院協同設計管理系統的過程中，一個重要的問題就是解決事務的處理。要求在整個系統所應用的事務處理模塊不僅能保證事務的ACID準則，并且應具有事務服務意外失敗后能進行自我恢復的能力。本文所實現的具有失敗恢復能力的OTS系統能很好地應用在協同設計管理系統中，作為一個分布式事務處理中間件，承擔著在整個系統中協調分布式對象之間的事務處理的功能。

參考文獻：

[1]Object Management Group. The common object request broker: architecture and specification: 3.0 edition[EB/OL].[2006-08-27].http://www.omg.org.

[2]Object Management Group. CORBAServices: common object services specification[EB/OL].[2006-08-27].http://www.omg.org.

[3]Object Management Group. Object transaction service specification: 1.3 edition[EB/OL].[2006-08-27].http://www.omg.org.

[4]陳良銀，李志蜀，鄧麗華，等.CORBA對象事務服務的實現[J].計算機應用與軟件，2005，22(2):57-58，87.

[5]徐海淵，吳泉源.基于StarBus的對象事務服務的設計與實現[J].國防科技大學學報，1999，21(1):76-79.

[6]楊濤，鄭曉霞，劉錦德.CORBA中對象事務服務研究與實現[J].電子科技大學學報，2001，30(6):590-595.

[7]齊勇，馬莉，趙季中，等.分布式事務處理技術及其模型[J].計算機工程與應用，2001，37(9):60-62.

[8]王克波.The orbas project: CORBA implementation project[EB/OL].[2006-08-27].http://labs.huihoo.com/orbas/index.html.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”