1、 本科畢業(yè)（設計）論文（二五）屆題目：數(shù)據(jù)庫事務處理的設計分院系部 計算機與信息科學系 專 業(yè) 計算機科學與技術 學生姓名 導師姓名 導師職稱 講 師 副 教 授 二五年六月一日數(shù)據(jù)庫事務處理的設計 摘要：本文主要介紹了關系數(shù)據(jù)庫系統(tǒng)事務處理的基本設計思想，并介紹事務處理系統(tǒng)中各組件的基本功能和核心服務。以此為基礎設計了一個簡單的事務處理系統(tǒng)模型，對部分細節(jié)進行了詳細設計。關鍵字：事務；事務處理；事務模型The Design of Transaction Processing in Database Abstract This article mainly introduced relatio

2、nal database system transaction processes the basic design thought, and introduction transaction processes in the system various modules basic function and the core service. Designed a simple transaction take this as the foundation to process the system model, has carried on the detailed design to t

3、he partial details.Keywords Transaction; Transaction Processing; Transaction Processing Model目 錄前言11數(shù)據(jù)庫中的事務處理11.1研究的意義11.2研究的背景及目的12事務22.1事務的概念與其特性22.2事務的必要性22.3事務的模型32.3.1扁平事務32.3.2帶保存點的扁平事務32.3.3鏈事務32.3.4嵌套事務32.3.5分布事務42.3.6長事務42.3.7多級別事務42.4事務處理系統(tǒng)的定義53事務處理系統(tǒng)的各模塊的核心服務和功能63.1一個事務的執(zhí)行過程63.2事務處理系統(tǒng)重要組件

4、必要功能的說明73.2.1事務處理監(jiān)控器的服務73.2.2日志管理器的功能說明93.2.3鎖管理器的功能說明93.2.4事務管理器的功能說明104設計與實現(xiàn)104.1事務處理的簡單模型104.2具體的設計與細節(jié)124.2.1事務標識符的設計124.2.2事務處理監(jiān)控器的設計134.2.3日志管理器的設計134.2.4鎖管理器的設計164.2.5事務管理器的設計165結論21前言事務處理的發(fā)展已經(jīng)有了上千年的歷史了。從5000年前的殷人開始使用烏龜?shù)耐鈿び浭乱詠恚呀?jīng)經(jīng)過了幾千年的歷史了。20世紀后半葉在事務處理方面出現(xiàn)了兩個主要的發(fā)展：基于磁性存儲介質（磁帶和磁盤）的成批事務處理以及基于電子存

5、儲和計算機網(wǎng)絡的聯(lián)機事務處理。在數(shù)據(jù)庫管理系統(tǒng)中附加上事務處理子系統(tǒng)會使系統(tǒng)有更好的可靠性。1數(shù)據(jù)庫中的事務處理1.1研究的意義在修改數(shù)據(jù)庫中的數(shù)據(jù)時，要使它里面的數(shù)據(jù)正確一致的被更新，這是事務處理的工作。當數(shù)據(jù)庫系統(tǒng)出現(xiàn)更新故障時，為了將損失減少到最低，一般來使用事務處理來恢復數(shù)據(jù)。事務處理的發(fā)展已經(jīng)很久了，其理論和技術相對來說是比較成熟的。1.2研究的背景及目的國外的數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，現(xiàn)在幾乎壟斷了整個市場。數(shù)據(jù)庫技術是整個信息產業(yè)的核心。即使數(shù)據(jù)庫的存儲介質發(fā)生了改變，數(shù)據(jù)庫的概念并不會有所變化。中國已經(jīng)有四家企業(yè)開發(fā)了自己的數(shù)據(jù)庫（不包括臺灣省）。這些數(shù)據(jù)庫基本能夠勝任中等強度與

6、規(guī)模的數(shù)據(jù)庫系統(tǒng)應用。對于那些核心業(yè)務應用，國產數(shù)據(jù)庫的應用案例十分有限。同時在對圖形工具的支持方面，國際主流數(shù)據(jù)庫管理系統(tǒng)提供好的圖形管理工具，而且還提供豐富的應用構件和套件，比如應用服務器、系統(tǒng)調優(yōu)與分析工具、企業(yè)應用套件等。國產數(shù)據(jù)庫的要趕上國外的數(shù)據(jù)庫，還要很長時間。研究的目的是：通過對事務處理的研究設計出數(shù)據(jù)庫所需要的事務處理系統(tǒng)。2事務2.1事務的概念與其特性事務是對物理和抽象的應用狀態(tài)上的操作集合。事務作為單個邏輯工作單元執(zhí)行一系列操作。一個邏輯工作單元必須有四個屬性，稱為ACID（原子性、一致性、隔離性和持久性）屬性，只有這樣才能成為一個事務。保證數(shù)據(jù)一致性的關鍵是要明確數(shù)據(jù)訪

7、問和更新的序列。這一序列稱為事務。它是并發(fā)和恢復的基本單位。下面分別對事務的四個特性進行敘述:原子性：一個事務對狀態(tài)的改變是原子的。要么都發(fā)生，要么都不發(fā)生。原子性是從操作調用者的角度來定義，因為幾乎沒有任何原子操作（包括機器指令）在所有的實現(xiàn)層次上保持真正的原子性。一致性：一個事務是對狀態(tài)的一個正確改變。作為一組操作沒有違反任何與狀態(tài)相關的完整性約束。這要求事務是一個正確的程序。隔離性：盡管事務是并發(fā)執(zhí)行的，但看起來是單個執(zhí)行的，即對于一個事務T，任何其他事務要么在T之前執(zhí)行，要么在T之后執(zhí)行，但不會既在T之前，又在T之后執(zhí)行。持久性：一旦一個事務成功完成（提交），它對狀態(tài)的改變不會受到其他

8、失敗事務的影響。2.2事務的必要性事務是為了實現(xiàn)軟件容錯的。現(xiàn)在沒有一直都能運行而不出錯的軟件，當一個產品化的計算機系統(tǒng)由于軟件問題崩潰，它的使用者并不會等到軟件開發(fā)者來將此問題更正之后，才使用它，而是重啟系統(tǒng)，希望這它下一次能運行起來，原因是因為它畢竟昨天被使用過。而系統(tǒng)通過用事務，系統(tǒng)恢復到最近的一個狀態(tài)。軟件故障是系統(tǒng)失敗的主要來源，因為其他硬件上的故障都是被軟件屏蔽掉的。軟件故障是一個沒有解決的問題。軟件容錯主要有兩種方法：N版本程序設計和事務。兩種方法一般可結合起來使用。數(shù)據(jù)庫是用來管理大量數(shù)據(jù)的，它肯定會存在軟件上的故障，此時只能是通過事務來使它內部的數(shù)據(jù)不會因為軟件故障而被全部破

9、壞掉。用N版本程序設計，它的實現(xiàn)和維護是昂貴的。這是因為要得到占大多數(shù)的結果，N至少是3。2.3事務的模型2.3.1扁平事務該模型是所有事務類型中最簡單的一種。扁平事務中的所有操作是處于同一平面的，由一個Begin_Work()來標志開始，Commit_Work結束。這個原因使這種事務在執(zhí)行之后的結果只有兩種，除此之外沒有其它的結果。一是全做，二是全不做。對于后者來說，原因有兩個：一是事務放棄，一是外界的事件使其不能完成。因此它具有“要么全做，要么全不做”的特性。2.3.2帶保存點的扁平事務系統(tǒng)在執(zhí)行過程出錯了，但是在一些情況下并不是所有的操作都無效的，如果使用前面的扁平事務，所有的操作都將回

10、滾，這樣做帶來的結果是，一些不需要回滾的操作也被回滾了，代價也較大。如果是回到同一事務里面的較早狀態(tài)，就能較好的支持了這類應用。所以在這種模型中設置保存點。2.3.3鏈事務鏈事務是保存點模式的一種變種。由前一個事務來觸發(fā)后一個事務發(fā)生。2.3.4嵌套事務嵌套事務的定義有五點：1)嵌套事務是若干事務組成的一棵樹，子樹既可以是嵌套的，也可以是扁平事務。2)處在葉節(jié)點的事務是扁平事務。從根節(jié)點到葉節(jié)點通過的路徑不同所經(jīng)過的距離也是不同的。3)位于要節(jié)點的事務稱為頂層事務，其他的事務稱為子事務。事務的前驅被稱為父（事務），事務的后繼被稱為子（事務）。4)子事務既可以提交，也可以回滾。直到父事務提交后，

11、子事務的提交才會生效。所以，任何子事務只有在根事務提交后才能最終提交。5)樹中的任意一個事務的回滾會引起它的所有子事務一同回滾。正是因為這一點，子事務僅保留了A、C、I特性，而不具有D特性。2.3.5分布事務分布事務一般是扁平事務，它應用于分布環(huán)境下，因此必須根據(jù)數(shù)據(jù)的位置來訪問網(wǎng)絡中的節(jié)點。2.3.6長事務以上所有介紹的事務模型都存在一個問題，一個比較大的批事務在前面幾個事務模型里不能完美的解決掉。解決這個典型問題的方法一般是由執(zhí)行一系列更新少量數(shù)據(jù)的事務構成，整個事務的原子性通過在數(shù)據(jù)庫中的事務上下文數(shù)據(jù)來維持。上下文是空集的程序被稱為上下文無關，其他的被稱為上下文相關。影響了數(shù)據(jù)庫的上下

12、文的原因是因為其他的事務更新了數(shù)據(jù)庫。2.3.7多級別事務Tselectinsertupdateselect插入元組插入B樹項更新頁插入地址表項定位插入項圖1一個多級別事務的模型圖多級別事務是嵌套事務的一般化和更自由化的版本。它們允許了子事務先提交，這使單獨回滾子事務的修改是可能的。然而為了保證事務的四個特性。最終會假設存在一個補償事務，如果父事務決定（或被迫）回滾，補償事務就可以取消子事務已經(jīng)完成的。的補償事務可以是另外的嵌套事務和多級事務。因為這些補償事務可以在所有嵌套層次被執(zhí)行，這樣就保證了所有的更新都可以被撤消，即使是在根節(jié)點失敗之前所有子事務已經(jīng)提交了的操作。因為這種模型使層次化對象

13、實現(xiàn)模式允許通過隔離高層對象來保護較低層次上的修改，所以它具有所有的ACID特性。這樣實現(xiàn)了對根事務的隔離，因此使原子地執(zhí)行根事務成為可能。在數(shù)據(jù)庫系統(tǒng)限制的情況下，這種多級別事務足夠用了。雖然回滾時，執(zhí)行補償操作的代價要比僅僅存儲舊值昂貴，但是回滾并不是一個頻繁的操作，擁有更小的提交控制單元的好處就會遠遠超過補償?shù)拇鷥r。2.4事務處理系統(tǒng)的定義從不同的角度來認識事務處理系統(tǒng)，因為每一個角度看到的系統(tǒng)都是很不同的，很難對事務處理系統(tǒng)做一個定義。給出一個綜合的定義是：事務處理系統(tǒng)提供工具使廣泛應用的編程、執(zhí)行和管理更加容易或者自動化。事務處理應用一般都支持多個設備組成的網(wǎng)絡，這些設備可以把查詢和

14、更新請求提交給應用。在這些輸入的基礎上，應用維護著一些表示現(xiàn)實世界特定狀態(tài)的數(shù)據(jù)庫。應用研究的響應和輸出總是驅使著現(xiàn)實世界的傳動器和轉換器，而它們改變和控制著這些狀態(tài)。3事務處理系統(tǒng)的各模塊的核心服務和功能首先來看一下，一個事務的執(zhí)行過程:3.1一個事務的執(zhí)行過程 圖2事務執(zhí)行過程中的核心服務當一個事務發(fā)出了Begin_Work()命令時，將在事務管理器中注冊該事務并產生一個唯一的事務標識符。一個應用一旦開始了一個事務，它就可以開始調用數(shù)據(jù)庫，并且把請求發(fā)送給本地和遠程服務。當一個資源管理器得到該事務的第一個請求時，它就加入到事務中，告知本地的事務管理器它想?yún)⑴c此事務的提交和回滾。參與一個事務

15、的資源管理器通常有多個。由于這些資源管理器代表著事務執(zhí)行操作，所以它們把自已對對象所做的改變都記下來。作為一個規(guī)則，資源管理器記錄新舊對象值。事務處理系統(tǒng)提供了一個日志服務記錄這些改變。日志管理器有效地實施了一個順序文件，里面記錄了事務對對象的所有更新。當然，其他的資源管理器要告訴日志管理器這些更新是什么。為了提供隔離，資源管理器將封鎖事務存取的對象；這防止了其他事務看到本事務沒有提交的更新，也防止它們更改該未提交的事務所讀寫的數(shù)據(jù)。事務處理系統(tǒng)提供了一個封鎖管理器供其他資源管理器使用。當事務發(fā)出Commit_Work()命令時，事務管理器將執(zhí)行兩階段提交協(xié)議。首先它查詢所有參與該事務的資源管

16、理器，問它們是否認為該事務是一個一致的和完整的轉變。當任一個資源管理器加以否決時，提交就失敗了。但是如果所有的資源管理器都贊同，事務管理器將在日志中記錄下這個事實，通知每一個資源管理器事務是完整的。這時，資源管理器才可以放鎖，執(zhí)行一些其他的完成該事務所需的操作。如果事務在執(zhí)行中出錯了，或者有一個資源管理器在兩階段提交的第一個階段否決，那么事務管理器就要指揮這個事務回滾。這種情況下，事務管理器讀事務日志，對每一個日志記錄調用寫該記錄的資源管理理，讓其撤消操作。一旦所有撤消都完成以后，事務管理器調用每一個參與該事務的資源管理器，告知它們事務被終止了。遠程調用事務的過程是本地先要對調用處理，找到調用

17、的種類和調用的目的。如果調用 的不是本地的，通過通信管理器向另一端發(fā)送消息。接收到另外一個節(jié)點的TPRC（遠程事務處理）到達的時候，就將它傳送給一個本地進程。在正確的處理完畢之后返回結果。3.2事務處理系統(tǒng)重要組件必要功能的說明由前面的圖1可以知道一個典型的事務處理系統(tǒng)至少應該具有四個部分：事務處理監(jiān)控器、事務管理器、日志管理器、鎖管理器。下面是各個部分的核心的服務和功能：。3.2.1事務處理監(jiān)控器的服務事務處理監(jiān)控器是為了引入事務型完程過程調用（TPRC）。事務處理監(jiān)控器其實是一個管理其他資源管理器和處理器資源（比如，進程、線程、訪問權限、程序、上下文等）的資源管理器。TP監(jiān)控器在這個意義上

18、說很像一個操作系統(tǒng)，但是還好跟操作系統(tǒng)有很大不同，通常來說操作系統(tǒng)根據(jù)一個長期的基準給請求分配資源，而TP監(jiān)控器必須根據(jù)每個請求的分配資源。其次在每創(chuàng)建一個會話時，操作系統(tǒng)所帶的所有管理任務必須在每個請求上由TP監(jiān)控器執(zhí)行。最后TP監(jiān)控器在崩潰之后進行重啟時，必須支持所有的應用程序和所有的資源管理器，操作系統(tǒng)通常只要關心自己的系統(tǒng)文件。它的基本功能為：1)調度 從客戶端來的請求必須放到實現(xiàn)應用服務的服務器程序中。并且正確的執(zhí)行完畢，回滾也是屬于正確的執(zhí)行完畢。因為回滾并沒有破壞系統(tǒng)的一致性。它首先確定處理請求的服務。若服務是遠程的，那么請求將通RPC發(fā)送到那兒。若服務位于本地，檢查是否有一個為

19、其服務的服務器已啟動。苦沒有，調用負載平衡的組件來決定是為其建立一個新的服務器，還是請求應該等到下一個服務器可用。最終，調度器將請法度發(fā)給服務器。2)服務器類管理 TP監(jiān)控器負責啟動服務器類，負責負載平等和所有相關的任務。在這里它負責的是啟動數(shù)據(jù)庫的服務器及其它重要的事務資源管理器。要確保對于每個應用程序，有一個服務器類被建立和處于激活狀態(tài)。3)認證和授權 在執(zhí)行請求服務前，TP監(jiān)控器必須了解請求。用戶并沒有登錄到了操作系統(tǒng)，只是注冊到了TP監(jiān)控器。但是，因為操作系統(tǒng)并不經(jīng)常執(zhí)行授權動作，因而TP監(jiān)控器不得不對每個請求進行授權，它主要是基于如事務程序名、遠程主機名、時間等一系列參數(shù)的原則。所有

20、這些都在請求時根據(jù)用戶配置文件進行檢查。4)資源管理 TP監(jiān)控器負責管理終端、數(shù)據(jù)庫、用戶和所有事務處理系統(tǒng)中的其他組件。它們的信息被保存在系統(tǒng)中心庫中，然而應用訪問中心庫的唯一方式是通過TP監(jiān)控器的管理接口來進行。定義了應用程序和其要交互的設備間的接口。現(xiàn)實的做法是，有一組資源管理器實現(xiàn)各種表示對象，通過事務RPC向TP監(jiān)控器提供接口來表示服務。5)系統(tǒng)操作 TP監(jiān)控器必須向操作者提供足夠的信息來調整系統(tǒng)，在普通操作過程中產生問題（終端斷開、服務器類的問題和其他很多的情況）時通知他們。6)恢復 系統(tǒng)崩潰后，TP監(jiān)控器負責重建進程配置。7)隊列管理 支持隊列事務處理。隊列的主要功能是接受請求并

21、將其傳給相應的服務器，接受響應結果并將其發(fā)送給相應客戶機。當且僅客戶事務提交請求時，請求被放在一個請求隊列中。一旦一個請求位于請求隊列中時，它將很快得到執(zhí)行。僅當服務器事務提交時結果才放到響應隊列中。隊列中的每個響應結果將由通過TP監(jiān)控器被發(fā)送給客戶端。根據(jù)不同的應用和消息的不同內容，要求有不同的發(fā)送保證（要和事務的ACID特性一致）。8)上下文管理 是一個TP監(jiān)控器服務，它能用于所有的事務程序。它包括兩個功能：第一個功能是保存處理上下文，第二個功能和正在運行的事務的上下文有關。3.2.2日志管理器的功能說明日志管理器是從資源管理的角度來描述的，而日志管理程序是從程序角度來描述的。在實質上的理

22、解應該是一樣的，沒有分別的。首先要說明一下為什么需要日志管理程序，日志本身的設計實際上是一個順序存取類型的SQL表，然而在寫日志方面由于具有以下特殊的性質，日志管理器的設置就成為了必要。1)封裝性 日志管理器對日志記錄頭的封裝只是為了確保正確地填寫這些頭字段信息。日志管理器為其他資源管理器提供接口，用以寫日志記錄體的內容，而日志頭是日志管理器私有的。2)啟動 系統(tǒng)重啟時，日志管理器用于重構那些永久的系統(tǒng)狀態(tài)。3)謹慎寫 日志通常是雙工的，并依據(jù)某種協(xié)議寫日志。這是因為，已經(jīng)提交的事務更新的數(shù)據(jù)的唯一永久副本是日志。日志管理程序的基本功能：1)日志管理程序為所有其它資源管理器和事務管理器提供對日

23、志表的讀寫訪問。2)日志管理程序為日志表提供面向記錄的讀接口和插入-刷新接口，資源管理器使用這些接口記載關于持久（可恢復）對象的改變信息。如果某個事務需要被撤消或重做，這個事務管理器使用這些接口讀回這些日志記錄交給資源管理器去處理。日志表中順序地存放著日志記錄，每個記錄都有一個頭，頭中包含了資源管理程序的名字、對該記錄進行寫操作的事務的名字和日志管理程序所能理解的日常信息。每個日志記錄中的大部分是日志體，它包含了所有的UNDO-REDO信息，這些信息是由寫這個日志記錄的資源管理器生成的。日志管理程序并不理解日志體的內容，僅僅是將它們看成字符串。日志記錄體通常有幾百個字節(jié)，但也可能是幾百兆字節(jié)。

24、3.2.3鎖管理器的功能說明這部分是為了實現(xiàn)并發(fā)，由另一位同學研究和設計的。最后的目的是為了實現(xiàn)事務處理中的隔離。這里就不進行說明。3.2.4事務管理器的功能說明事務管理器除了能夠正常的標識、開始、執(zhí)行一個事務。當有失敗的情況出現(xiàn)時，也要由事務管理器來協(xié)調恢復，根據(jù)不同的情況具體的實現(xiàn)也就不同：1)事務回滾 事務管理器協(xié)調事務回滾到一個保存點或干脆取消（中止）該事務，這種回滾和中止可以由任何參與者發(fā)起。2)資源管理器重啟 如果一個資源管理器失敗并重啟，則由事務管理器提供給它回到最近提交狀態(tài)所需要的日志記錄。3)系統(tǒng)重啟 計算機系統(tǒng)重啟時，事務管理器幫助局部資源管理器恢復其永久性狀態(tài)，同時，也解

25、決在系統(tǒng)崩潰或關機時處于不確定狀態(tài)的所有分布式事務，這種機制也能實現(xiàn)事務管理器的重啟。4)介質恢復 如果一個對象被破壞，通過使用這個對象的歸檔副本和自從這個對象歸檔以來的所有對其更改的日志，事務管理器可以幫助資源管理器重建該對象。現(xiàn)在只考慮單一事務管理器的事務和數(shù)據(jù)。如果是涉及到幾個機群的事務可能涉及到幾個事務管理器。如果對一個聯(lián)網(wǎng)的數(shù)據(jù)庫系統(tǒng)來說的話，情況也應該是這樣的。4設計與實現(xiàn)4.1事務處理的簡單模型因為要設計的事務處理是為數(shù)據(jù)庫服務的，所以用到多級事務模型。首先來看事務監(jiān)控器對一個遠程事務的處理流程：入隊隊列事務請求判斷權限有成功事務計算出隊隊列發(fā)送到客戶錯誤消息圖3事務監(jiān)控器對一個

26、遠程事務的處理一個遠程事務請求開始，事務監(jiān)控器判斷其權限，然后把事務放到永久隊列中，從隊列中取出事務進行事務計算。將計算的結果放到另一個隊列中，發(fā)送到客戶端去。事務管理器對事務的控制過程：事務請求分配事務標識符資源分配第一階段提交第二階段提交成功失敗事務結束事務回滾成功失敗圖4事務管理器對事務的控制過程發(fā)起一個事務請求，事務管理器為該事務分配一個唯一的事務標識符，事務管理器在正常情況下只是維護事務的ACD特性。參與事物的所有資源管理器將進行第一次表決時，這是第一階段提交，如果第一階段提交通過，那么進行第二階段提交，事務管理器強制寫日志表。標識事務已經(jīng)完了。第二階段提交后，事務管理器向各個資源管

27、理器通知事務已經(jīng)結束，資源管理器將調用鎖管理器，釋放鎖。如果在第一階段有資源管理器不同意，事務回滾。進行補償事務的調用，補償事務是一定會成功的。（如果失敗，表示系統(tǒng)的設計與實現(xiàn)有問題）。如果是遠端的，事務監(jiān)控器將把請求通過通信管理器發(fā)送出去。接收到一個遠程處理，首先由事務監(jiān)控器來判斷是否有權限，然后把這個事務請求放入一個永久的隊列中，從隊列中取出進行計算，將結果放到一個永久隊列中，由通信管理器將一定策略來發(fā)送，這里的策略是向終端連續(xù)發(fā)生三次。如果事務回滾將回滾的信息通過通信管理器來發(fā)送回終端。在一個事務的提交過程中都是要寫日志的，后面的回滾和恢復數(shù)據(jù)根據(jù)日志來的。它是很重要的。下一節(jié)的內容是各

28、個組件的具體設計。4.2具體的設計與細節(jié)4.2.1事務標識符的設計事務標識符是很重要的對于事務處理來說。對于一個事務處理，事務標識符必須始終是唯一的，每一個事務標識符（trid）標識一個具有ACID屬性的工作單元。此外trid能方便地表示出創(chuàng)建它的事務管理器，事務管理器也必須要記住有多少事務，有可能會丟失事務，就得由事務本身來標識自己在事務管理器中是第幾個事務。所以事務標識符的數(shù)據(jù)結構由一個三元組組成組成第一個元素birthday是事務產生的時間，第二個元素TMID是事務管理器的標識符，對于在網(wǎng)絡上的事務處理是很有用處的，對于本地機的事務處理這個編號是沒有作用的。第三個元素counter是事務

29、在事務管理器中建立的序號。一般來說事務標識是由一個可變的整型數(shù)組來表示。對于多級事務的標識來說，頂層事務，標識事務標識的整型數(shù)組由一個元素構成，隨著事務層次的逐漸降低，表示事務標識的整型數(shù)組的元素個數(shù)逐漸，這是因為新的子事務的標識由其父事務標識和一個區(qū)別兄弟事務區(qū)分的新元素構成。這個策略簡單，也能滿足事務的大部分需求，但是空間開銷大。所以在具體的設計與編碼時是考慮用位段來存其標識的。下面是一個事務標識的結構Typedef structTIMESTAMP birthday; /TM能記憶的最前的時間 TMID tmid; /事務管理器標識符，在網(wǎng)絡中唯一 unsigned a:8TRID4.2.

30、2事務處理監(jiān)控器的設計當一個事務從終端發(fā)送過來，并沒有直接發(fā)送給服務器。事務處理監(jiān)控器獲得這一信息，對其權限進行檢查之后。通過一定的策略啟動服務，有時并不是馬上啟動服務。判斷請求的類型，如果請求是一個立即的，馬上執(zhí)行，結果迅速返回，如果請求不是一個立即的，一般就要將它放到一個持久的隊列中，如果在執(zhí)行立即事務時，服務器為請求服務時出現(xiàn)了一個峰值一般的解決方法是建立一個臨時的隊列，峰值消失的時候該隊列也就消失了。用異步方式高度事務處理請求需要使用隊列。原因是有以下兩個方面：在直接的聯(lián)機事務處理中，暫時性的系統(tǒng)過載會導致對某一資源管理的請求在相應的服務器類前等待。這時構造的隊列是揮發(fā)的。TP監(jiān)控器把

31、它們作為臨時控制塊在自己共享數(shù)據(jù)結構池中維護。第二類型的隊列是用于隊列事務處理的，這種事務處理的特點就是異步。請求被發(fā)送到永久的請求隊列中去，而不是通過TRPC從請求的一方直接發(fā)送到服務器上的。4.2.3日志管理器的設計日志管理程序把日志作為SQL表來實現(xiàn)，因此通過SQL查詢可以讀日志表。日志管理程序用一組操作來封裝日志的寫操作。對日志表的設計，在日志表中，每個記錄都有唯一的碼，稱做日志序號。下面是用SQL語言表示的日志表定義：create domain LSN unsigned interger(64);-日志序號（文件號，rba）create domain RMID unsigned in

32、terger(64);-資源管理程序標識符create domain TRID unsigned interger(64);-事務標識符create table log_table(lsn LSN, -記錄的日志序號prev_lsn LSN, -日志中前一個記錄的lsntimestamp TIMESTAMP, -日志記錄的創(chuàng)建時間resource_manager RMID, -寫這個日志記錄的資源管理器trid TRID, -寫這個記錄的事務tran_prev_lsn LSN, -該事務的前一個日志記錄（或0）body varchar, -日志數(shù)據(jù)。primary key (lsn) -lsn

33、為主碼foreign key(prev_lsn) -前一個日志記錄在這個表中 references log_table(lsn), -foreign key(tran_prev_lsn) -該事務的前一個日志記錄也在這表中 refernces log_table(lsn), -)entry sequenced; -在文件尾進行插入日志文件通常是雙工的，以免單個日志文件的存儲失敗造成日志破壞。而且這兩個物理文件序列通常被分別存放在不同的目錄空間中，這主要是為了降低日志被破壞的風險。系統(tǒng)初始化后，首先為日志分配兩個物理文件，隨著日志的增長，這些文件被寫滿之后，系統(tǒng)會再分配另外的兩個物理文件來登記下

34、個日志記錄。這個過程是可一直持續(xù)下去的。雙工的兩個日志文件將使用標準的文件名，并分別以LOGA和LOGB格式結尾，這里的0用該文件在日志目錄中的文件索引來填寫。由于可用算法計算出第n個日志文件的名字，所以日志管理程序只要維護一個記錄就可以描述每個日志（這個記錄只需要存儲日志文件名的公共前綴和當前日志文件的索引）：如下偽代碼所示：struct log_files filename a_prefix;/”a”日志文件的目錄 filename b_prefix;/“b”日志文件的目錄 long index;/當前文件的索引這個信息構成日志錨點這種數(shù)據(jù)結構的核心內容，日志錨點在主存中緩存，且至少被記錄

35、到持久存儲器的兩個不同的地方，通常是在兩個文件中，這樣是考慮到系統(tǒng)重新啟動時可以找到日志錨點。日志序號如前所述，每個記錄都有一個唯一的標識符，將這個標識符稱為日志序號（LSN）。LSN是由記錄的文件號和這個記錄在文件中的相對字節(jié)偏移量組成的。LSN的定義如下：typedef structlong file; /在日志目錄中日志文件號 long rba; /記錄（第1個字節(jié)）在文件中的相對字節(jié)地址 LSN；/日志序號定義日志讀寫的細節(jié)設計:讀日志問題相對比較簡單。除了最后一個日志記錄外，不用加鎖就可讀取所有日志記錄，但是最后一個日志記錄正在被更新時，它是不能被讀取時。日志管理程序對大多數(shù)日志頁采

36、用樂觀讀取方式：只讀雙工日志的一個副本。當然有一定危險性的。可以通過維護一個標志來檢測這種情況：在每個日志頁上設置一個標志量，標志量的什用來指示這個頁是否已滿。因為日志是順序寫入的，所以除了最后一頁外所有的頁都是滿期的，標志量值都置為真。由于最后一頁大多數(shù)都江堰市緩沖在內存中，因而其存取不需要I/O操作。這樣便可以進行安全的樂觀讀。在寫日志時，要謹慎寫：串行寫和乒乓寫，雙工日志表可以屏蔽絕大多數(shù)介質故障，但是有一種情況則不行。最后一個日志頁的信息未滿期，下一個日志記錄將被加到這個日志頁上。如果在寫的過程中斷電，或處理器錯誤，這種簡單的寫操作會損壞原來頁中已有的信息。處理這個問題的辦法有兩個，一

37、個是串行寫，先寫一份日志（副本），當這個日志寫完后，再寫另一個日志（副本）。串行寫花費的時間是原來的兩倍。另一個辦法是乒乓寫算法。假設日志的最后一頁稱為pagej，pagej非空，并且打算用新增的數(shù)據(jù)覆蓋pagej。這種情況下，先將新增加的數(shù)據(jù)寫入pagej+1，而后在pagej+1和pagej之間乒乓式來回重寫。當從磁盤讀入的時候，必須讀最后兩頁（j和j+1）并且接受時間戳較大的那頁。4.2.4鎖管理器的設計鎖管理器的設計由另一位同學設計。此處不再提出。在這里事務管理器只是負責了事務特性的A（原子性）、C（一致性）、D（永久性），I（隔離性）由鎖管理器去負責。4.2.5事務管理器的設計在正常

38、處理中，資源管理器和系統(tǒng)都不會失敗。應用程序通過Begin_Wrok()、Save_Work()、Prepare_Work()、Commit_Work()、Rollback_Work()及Read_Context()調用事務管理器，此外資源管理器通過ldentify()和Join_Work()調用事務管理器。事務管理器數(shù)據(jù)結構是這樣的：事務管理器連同TP監(jiān)控器一起保存了一個數(shù)據(jù)結構，用以描述已調用ldentify()的每個資源管理器。同時，事務管理器為每一個活的事務也保存一個數(shù)據(jù)結構，這個結構包括該事務的狀態(tài)、日志記錄、參與這個事務的資源管理器以有分配給該事務的會話。作為應用接口，所設計事務管

39、理器提供了如下的命令以供調用：TRID Begin_Work(context *);/開始一個事務Bool Commit_Work(context *);/提交該事務void Abord_Work(void);/回滾到保存點0savepoint Save_Work(context *);/建立一個保存點savepoint Rollback_Work(savepoint);/返回到保存點（返回到保存點0即中止）Bool Prepare_Work(savepoint);/將事務置為準備就緒狀態(tài)context Read_Context(void);/返回到當前保存點上下文TRID Chain_Wor

40、k(context *);/結束當前事務，開始下一事務TRID My_Trid(void);/返回當前事務標識符TRID Leave_Transaction(void);/設置進程TRID為空，返回當前標識符Bool Resume_Transaction(TRID);/設置進程TRID為期望TRIDenum tran_statusACTIVE,PREPARED,ABORTING,COMMITTING,ABORTED,COMMITTED;tran_status Status_Transaction(TRID);/返回一個事務標識符狀態(tài)關于Begin_Work()它的邏輯是：分配一個新的事務標識符

41、，在事務表中加一個入口項（entry），對該入口項進行格式化以反映保存點1。然后，事務管理器寫一條開始事務日志記錄，這會引起日志管理程序對那個日志記錄在該事務入口項中設置min LSN和max LSN指針，日志管理程序維護該LSN字段，鎖管理器維護translock_list。事務可以建立一個持久的保存點（意思是重啟時仍然存在），則Begin_Work()請求把日志記錄強制寫入持久性存儲器。最后，設置該里程事務標識符為該trid，從這類保存點直到進程提交、中止或離開該事務，該進程的一切工作和它發(fā)出的所有RPC都用這個trid來標識。下面是有關這個處理的偽代碼：TRID Begin_Work(c

42、ontext * it,Bool soft)TransCB * trans;/事務描述符TRID him;/新的tridTM_savepoint save;/被寫入的保存點記錄if(MyTrid()!=NULLTrid) return (NULLTrid);/保持其為空Him=TM_anchor.next_trid;/賦值給它的下一個tridTM_anchor.next_trid.sequence+;/使下一個trid加1(MyProccess()-trid=him;/令其為該進程的trid/分配，格式化事務控制塊Trans=malloc(sizeof(TransCB);/分配一個事務入口Tr

43、ans-next=TM_anchor.tran_list;/將事務加入到事務列表中TM_anchor.tran_list=trans;trans-trid=him;/設置它的tridtrans-status=ACTIVE;/設置它的狀態(tài)為“活動的”trans-save_pt=1;trans-next_save_pt=2;/當前保存點為1，下個保存點為2trans-RM_list=trans-lock_list=trans-ses_list=NULL;/還有會話、鎖及資源/格式化，寫開始事務（保存點1）日志記錄save.record_type=begin;/設置日志記錄體類型save.save_

44、pt_num=1;save.soft=soft;/格式化保存點記錄save.num_RM=save.sessions=0;/僅僅是現(xiàn)在參與的事務管理器copy(save.it,it,it.length);/加入它的上下文trans-save_pt_lsn=log_insert(save,sizeof(save);/寫開始事務日志記錄/給出log_insert()如何更新min lsn和max lsnif(!soft)log_flush(trans-max_lsn,FALSE);/如果是持久化的開始，強制寫入日志return (him);/返回trid給him;提交事務很簡單。通過調用 資源管理

45、器的Prepare()回調請求，資源管理器投票，；通過發(fā)送Prepare()TRPC，進行投票表決，然后，可以投贊同票也可以投反對票。若都為贊成票那么事務準備提交。此時，提交調用 寫一條提交記錄（保存點記錄），并強制其寫入持久存儲器。然后，提交操作向局部資源管理器及通過Commit() TRPC向遠程會話廣播這個提交決定。當它們都做出響應時，事務管理器就在日志中寫一條完成記錄，釋放事務控制塊。整個Commit_Work()邏輯大致如下：Bool Commit_Work(context *it ,Bool lazy)if Prepare_Work()/嘗試準備事務commit();/如果準備成功

46、，那么做第2階段工作elseRollback_Work(0);一般來說問題都出在提交的階段1，如果在提交的階段2出現(xiàn)了錯誤，事務管理器最終必須發(fā)送該消息并從資源管理器或遠程事務管理器處得到響應。下面是這種情況下的大致代碼：void session_failure(SECB* session)/向遠程TM持久發(fā)送Commit()TRPCTransCB* trans=MyTransP();/指向進程的事務描述符的指針Bool timeout=TRUE;/表明TRPC超時的標志TM_savepoint save;/被格式化的完成記錄RMID TM=session-him;/接受commit()回調的

47、遠程TM的名字while(timeout)/重復TRPC直到有確認TM.Commit();/通知遠程事務管理器提交free session;/如果有確認，則從事務中釋放會話if(trans-RM_list=NULL & trans-ses_list=NULL)/如果所有的資源管理器都完成（被釋放）而且如果所有的聯(lián)出會話已提交trans_status=COMMITTED;/進入committed狀態(tài)save.record_type=commit_complete;/設置日志記錄類型為已完成log_insert(save,sizeof(save);/惰性寫完成記錄dequeue and free

48、frans structure;/釋放事務控制塊，已完成exit();/進程完成，結束進程;事務的回滾邏輯：UNDO掃描程序反向掃描日志，回滾能返回到以前的任一個保存點。當UNDO掃描程序到達要求的保存點時，事務管理器輪詢每個資源管理器，請它重新實例化該保存點。最終，UNDO掃描程序找到一個所有資源管理器都同意的保存點，或到保存點0（事務全部撤消），資源管理器無論如何是不允許否決保存點0。代碼如下：long Rollback_Work(long target_savepoint)TransCB * trans=MyTransP();/指向進程事務描述符的指針TM_savepoint save;

49、/被格式化的保存點記錄LSN lsn;/用于撤消掃描的lsnRMID rmid;/從日志記錄中抽取出的rmidlog_record_header header;/保存日志記錄頭的緩沖區(qū)bool abort=FALSE;/表明UNDO失敗，以便中止該事務if(MyTrid()=NULLTrid)return (0);/事務已經(jīng)中止lsn=trans-max_lsn;/得到最后一條日志記錄的lsn/UNDO掃描程序反向掃描日志while(lsn!=NULLLSN)/在日志中進行撤消掃描log_read(lsn,&header,save,sizeof(save);/讀日志記錄頭rmid=header.rmid;/提取資源管理器標識符rmid.undo(lsn);/調用它撤消日志記錄if(timeout