交易處理的定義

來源:互聯網
上載者:User
交易處理


     在許多大型、關鍵的應用程式中,電腦每秒鐘都在執行大量的任務。更為經常的不是這些任務本身,而是將這些任務結合在一起完成一個業務要求,稱為事務。如果能成功地執行一個任務,而在第二個或第三個相關的任務中出現錯誤,將會發生什嗎?這個錯誤很可能使系統處於不一致狀態。這時事務變得非常重要,它能使系統擺脫這種不一致的狀態。
    Microsoft最初使用Microsoft事務伺服器(MTS)來處理事務。隨著Windows 2000的發布,Microsoft進一步改進了MTS,使其成為COM+的一部分或元件服務。
    本章講述元件服務的事務性特性。瞭解它們如何用於支援在I I S上開發的應用程式的事務。
    本章的主要內容包括:
    ? 交易處理的定義。
    ? 交易處理的目的。
    ? 在COM+中的交易處理如何工作。
    ? 事務性A S P頁面。
    首先,讓我們看一看什麼是交易處理。
19.1 交易處理的定義
    本書已經介紹了許多涉及交易處理的概念,但是交易處理到底是什麼。在大型主機時代,就有交易處理。使用者資訊控制系統(CICS)、Tuxedo和TopEnd等產品都是交易處理系統的例子,它們為應用程式提供事務服務。
    為了討論交易處理,必須首先定義事務。
    事務是一個最小的工作單元,不論成功與否都作為一個整體進行工作。
    不會有部分完成的事務。由於事務是由幾個工作群組成的,因此如果一個事務作為一個整體是成功的,則事務中的每個任務都必須成功。如果事務中有一部分失敗,則整修事務失敗。
    當事務失敗時,系統返回到事務開始前的狀態。這個取消所有變化的過程稱為“復原”( rollback )。例如,如果一個事務成功更新了兩個表,在更新第三個表時失敗,則系統將兩次更新恢複原狀,並返回到原始的狀態。
19.1.1 保持應用程式的完整性
    任何應用程式的關鍵是要確保它所執行的所有操作都是正確的,如果應用程式僅僅是部分地完成操作,那麼應用程式中的資料,甚至整個系統將會處於不一致狀態。例如,看一下銀行轉賬的例子,如果從一個帳戶中提出錢,而在錢到達另一個帳戶前出錯,那麼在此應用
程式中的資料是錯誤的,而且失去了它的完整性,也就是說錢會莫名其妙地消失。
    克服這種錯誤有兩種方法:
    ? 在傳統的編程模型中,開發人員必須防止任何方式的操作失敗。對任何失敗點,開發人員必須加上支援應用程式返回到這一操作開始前的狀態的措施。換句話說,開發人員必須加入代碼使系統能夠在操作出現錯誤時恢複原狀(撤消)。
    ? 更為簡單的方法是在交易處理系統的環境之內進行操作,交易處理系統的任務就是保證整個事務或者完全成功,或者什麼也不做。如果事務的所有任務都成功地完成,那麼在應用程式中的變化就提交給系統,系統就處理下一個事務或任務。如果操作中某一部分不能成功地完成,這將使系統處於無效的狀態,應復原系統的變化,並使應用程式返回到原來的狀態。
    交易處理系統的能力就是將完成這些操作的知識嵌入到系統本身。開發人員不必為將系統復原原狀編寫代碼,需要做的只是告訴系統執行任務是否成功,剩下的事情由交易處理系統自動完成。
    在協助開發人員解決複雜的問題時,交易處理系統的另一好處是其ACID屬性。
19.1.2 ACID屬性
    當交易處理系統建立事務時,將確保事務有某些特性。組件的開發人員們假設事務的特性應該是一些不需要他們親自管理的特性。這些特性稱為ACID特性。
    ACID就是:原子性(Atomicity )、一致性( Consistency )、隔離性( Isolation)和持久性(Durabilily)。
    1. 原子性
    原子性屬性用於標識事務是否完全地完成,一個事務的任何更新要在系統上完全完成,如果由於某種原因出錯,事務不能完成它的全部任務,系統將返回到事務開始前的狀態。
    讓我們再看一下銀行轉帳的例子。如果在轉帳的過程中出現錯誤,整個事務將會復原。只有當事務中的所有部分都成功執行了,才將事務寫入磁碟並使變化永久化。
    為了提供復原或者撤消未提交的變化的能力,許多資料來源採用日誌機制。例如,SQL Server使用一個預寫交易記錄,在將資料應用於(或提交到)實際資料頁面前,先寫在交易記錄上。但是,其他一些資料來源不是關係型資料庫管理系統(RDBMS),它們管理未提交事務的方式完全不同。只要交易回復時,資料來源可以撤消所有未提交的改變,那麼這種技術應該可用於管理事務。
    2. 一致性
    事務在系統完整性中實施一致性,這通過保證系統的任何事務最後都處於有效狀態來實現。如果事務成功地完成,那麼系統中所有變化將正確地應用,系統處於有效狀態。如果在事務中出現錯誤,那麼系統中的所有變化將自動地復原,系統返回到原始狀態。因為事務開
始時系統處於一致狀態,所以現在系統仍然處於一致狀態。
    再讓我們回頭看一下銀行轉帳的例子,在帳戶轉換和資金轉移前,帳戶處於有效狀態。如果事務成功地完成,並且提交事務,則帳戶處於新的有效狀態。如果事務出錯,終止後,帳戶返回到原先的有效狀態。
    記住,事務不負責實施資料完整性,而僅僅負責在事務提交或終止以後確保資料返回到一致狀態。理解資料完整性規則並寫代碼實現完整性的重任通常落在開發人員肩上,他們根據業務要求進行設計。
    當許多使用者同時使用和修改同樣的資料時,事務必須保持其資料的完整性和一致性。因此我們進一步研究A C I D特性中的下一個特性:隔離性。
    3. 隔離性
    在隔離狀態執行事務,使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務,運行在相同的時間內,執行相同的功能,事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。
    這種屬性有時稱為序列化,為了防止事務操作間的混淆,必須序列化或序列化請求,使得在同一時間僅有一個請求用於同一資料。
    重要的是,在隔離狀態執行事務,系統的狀態有可能是不一致的,在結束事務前,應確保系統處於一致狀態。但是在每個單獨的事務中,系統的狀態可能會發生變化。如果事務不是在隔離狀態運行,它就可能從系統中訪問資料,而系統可能處於不一致狀態。通過提供事
務隔離,可以阻止這類事件的發生。
    在銀行的樣本中,這意味著在這個系統內,其他過程和事務在我們的事務完成前看不到我們的事務引起的任何變化,這對於終止的情況非常重要。如果有另一個過程根據帳戶餘額進行相應處理,而它在我們的事務完成前就能看到它造成的變化,那麼這個過程的決策可能
建立在錯誤的資料之上,因為我們的事務可能終止。這就是說明了為什麼事務產生的變化,直到事務完成,才對系統的其他部分可見。
    隔離性不僅僅保證多個事務不能同時修改相同資料,而且能夠保證事務操作產生的變化直到變化被提交或終止時才能對另一個事務可見,並發的事務彼此之間毫無影響。這就意味著所有要求修改或讀取的資料已經被鎖定在事務中,直到事務完成才能釋放。大多數資料庫,例如SQL Server以及其他的RDBMS,通過使用鎖定來實現隔離,事務中涉及的各個資料項目或資料集使用鎖定來防止並發訪問。
    4. 持久性
    持久性意味著一旦事務執行成功,在系統中產生的所有變化將是永久的。應該存在一些檢查點防止在系統失敗時丟失資訊。甚至硬體本身失敗,系統的狀態仍能通過在日誌中記錄事務完成的任務進行重建。持久性的概念允許開發人員認為不管系統以後發生了什麼變化,完
成的事務是系統永久的部分。
    在銀行的例子中,資金的轉移是永久的,一直保持在系統中。這聽起來似乎簡單,但這,依賴於將資料寫入磁碟,特別需要指出的是,在事務完全完成並提交後才寫入磁碟的。
    所有這些事務特性,不管其內部如何關聯,僅僅是保證從事務開始到事務完成,不管事務成功與否,都能正確地管理事務涉及的資料。




相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。