事務處理

在許多大型、關鍵的應用程序中，計算機每秒鐘都在執行大量的任務。更為經常的不是這些任務本身，而是將這些任務結合在一起完成一個業務要求，稱為事務。如果能成功地執行一個任務，而在第二個或第三個相關的任務中出現錯誤，將會發生什麼？這個錯誤很可能使系統處於不一致狀態。這時事務變得非常重要，它能使系統擺脱這種不一致的狀態。

用户信息控制系統(CICS)、Tuxedo和TopEnd等產品都是事務處理系統的例子，它們為應用程序提供事務服務。

為了討論事務處理，必須首先定義事務。

事務是一個最小的工作單元，不論成功與否都作為一個整體進行工作。

不會有部分完成的事務。由於事務是由幾個任務組成的，因此如果一個事務作為一個整體是成功的，則事務中的每個任務都必須成功。如果事務中有一部分失敗，則整個事務失敗。

當事務失敗時，系統返回到事務開始時的狀態。這個取消所有變化的過程稱為“回滾”( rollback )。例如，如果一個事務成功更新了兩個表，在更新第三個表時失敗，則系統將兩次更新恢復原狀，並返回到原始的狀態。

保持應用程序的完整性

任何應用程序的關鍵是要確保它所執行的所有操作都是正確的，如果應用程序僅僅是部分地完成操作，那麼應用程序中的數據，甚至整個系統將會處於不一致狀態。例如，看一下銀行轉賬的例子，如果從一個帳户中提出錢，而在錢到達另一個帳户前出錯，那麼在此應用程序中的數據是錯誤的，而且失去了它的完整性，也就是説錢會莫名其妙地消失。

克服這種錯誤有兩種方法：

在傳統的編程模型中，開發者必須防止任何方式的操作失敗。對任何失敗點，開發者必須加上支持應用程序返回到這一操作開始時的狀態的措施。換句話説，開發者必須加入代碼使系統能夠在操作出現錯誤時恢復原狀(撤消)。

更為簡單的方法是在事務處理系統的環境之內進行操作，事務處理系統的任務就是保證整個事務或者完全成功，或者什麼也不做。如果事務的所有任務都成功地完成，那麼在應用程序中的變化就提交給系統，系統就處理下一個事務或任務。如果操作中某一部分不能成功地完成，這將使系統處於無效的狀態，應回滾系統的變化，並使應用程序返回到原來的狀態。

事務處理系統的能力就是將完成這些操作的知識嵌入到系統本身。開發者不必為將系統恢復原狀編寫代碼，需要做的只是告訴系統執行任務是否成功，剩下的事情由事務處理系統自動完成。

在幫助開發人員解決複雜的問題時，事務處理系統的另一好處是其ACID屬性。

ACID屬性

當事務處理系統創建事務時，將確保事務有某些特性。組件的開發者們假設事務的特性應該是一些不需要他們親自管理的特性。這些特性稱為ACID特性。

ACID就是：原子性(Atomicity )、一致性( Consistency )、隔離性( Isolation)和持久性(Durabilily)。

1. 原子性

原子性屬性用於標識事務是否完全地完成，一個事務的任何更新要在系統上完全完成，如果由於某種原因出錯，事務不能完成它的全部任務，系統將返回到事務未開始的狀態。

讓我們再看一下銀行轉帳的例子。如果在轉帳的過程中出現錯誤，整個事務將會回滾。只有當事務中的所有部分都成功執行了，才將事務寫入磁盤並使變化永久化。

為了提供回滾或者撤消未提交的變化的能力，許多數據源採用日誌機制。例如，SQL Server使用一個預寫事務日誌，在將數據應用於(或提交到)實際數據頁面前，先寫在事務日誌上。但是，其他一些數據源不是關係型數據庫管理系統(RDBMS)，它們管理未提交事務的方式完全不同。只要事務回滾時，數據源可以撤消所有未提交的改變，那麼這種技術應該可用於管理事務。

2. 一致性

事務在系統完整性中實施一致性，這通過保證系統的任何事務最後都處於有效狀態來實現。如果事務成功地完成，那麼系統中所有變化將正確地應用，系統處於有效狀態。如果在事務中出現錯誤，那麼系統中的所有變化將自動地回滾，系統返回到原始狀態。因為事務開始時系統處於一致狀態，所以現在系統仍然處於一致狀態。

再讓我們回頭看一下銀行轉帳的例子，在帳户轉換和資金轉移前，帳户處於有效狀態。如果事務成功地完成，並且提交事務，則帳户處於新的有效的狀態。如果事務出錯，終止後，帳户返回到原先的有效狀態。

記住，事務不負責實施數據完整性，而僅僅負責在事務提交或終止以後確保數據返回到一致狀態。理解數據完整性規則並寫代碼實現完整性的重任通常落在開發者肩上，他們根據業務要求進行設計。

當許多用户同時使用和修改同樣的數據時，事務必須保持其數據的完整性和一致性。

3. 隔離性

在隔離狀態執行事務，使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。

這種屬性有時稱為串行化，為了防止事務操作間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用於同一數據。

重要的是，在隔離狀態執行事務，系統的狀態有可能是不一致的，在結束事務前，應確保系統處於一致狀態。但是在每個單獨的事務中，系統的狀態可能會發生變化。如果事務不是在隔離狀態運行，它就可能從系統中訪問數據，而系統可能處於不一致狀態。通過提供事務隔離，可以阻止這類事件的發生。

在銀行的示例中，這意味着在這個系統內，其他過程和事務在我們的事務完成前看不到我們的事務引起的任何變化，這對於終止的情況非常重要。如果有另一個過程根據帳户餘額進行相應處理，而它在我們的事務完成前就能看到它造成的變化，那麼這個過程的決策可能建立在錯誤的數據之上，因為我們的事務可能終止。這就是説明了為什麼事務產生的變化，直到事務完成，才對系統的其他部分可見。

隔離性不僅僅保證多個事務不能同時修改相同數據，而且能夠保證事務操作產生的變化直到變化被提交或終止時才能對另一個事務可見，併發的事務彼此之間毫無影響。這就意味着所有要求修改或讀取的數據已經被鎖定在事務中，直到事務完成才能釋放。大多數數據庫，例如SQL Server以及其他的RDBMS，通過使用鎖定來實現隔離，事務中涉及的各個數據項或數據集使用鎖定來防止併發訪問。

4. 持久性

持久性意味着一旦事務執行成功，在系統中產生的所有變化將是永久的。應該存在一些檢查點防止在系統失敗時丟失信息。甚至硬件本身失敗，系統的狀態仍能通過在日誌中記錄事務完成的任務進行重建。持久性的概念允許開發者認為不管系統以後發生了什麼變化，完成的事務是系統永久的部分。

在銀行的例子中，資金的轉移是永久的，一直保持在系統中。這聽起來似乎簡單，但這，依賴於將數據寫入磁盤，特別需要指出的是，在事務完全完成並提交後才寫入磁盤的。

所有這些事務特性，不管其內部如何關聯，僅僅是保證從事務開始到事務完成，不管事務成功與否，都能正確地管理事務涉及的數據。

數據庫的更新通常都是由客觀世界的所發生的事件引起的。為保證數據庫內容的一致，就要將數據庫的一組操作作為一個整體來進行，要麼全部成功完成，要麼全部失敗退出。如果由於故障或其它原因而使一組操作中有一些完成，有一些未完成，則必然會使得數據庫中的數據出現不一致，從而使得數據庫的完整性受到破壞。因此，更新操作序列必須作為一個整體在DBMS執行時出現，即“要麼全做，要麼全不做”。SQL提供了事務處理的機制，來幫助DBMS實現上述的功能。

事務處理（TRANSACTION）是由一個或多個SQL語句序列結合在一起所形成的一個邏輯處理單元。事務處理中的每個語句都是完成整個任務的一部分工作，所有的語句組織在一起能夠完成某一特定的任務。DBMS在對事務處理中的語句進行處理時，是按照下面的約定來進行的，這就是“事務處理中的所有語句被作為一個原子工作單位，所有的語句既可成功地被執行，也可以沒有任何一個語句被執行”。DBMS負責完成這種約定，即使在事務處理中應用程序異常退出，或者是硬件出現故障等各種意外情況下，也是如此。在任何意外情況下，DBMS都負責確保在系統恢復正常後，數據庫內容決不會出現“部分事務處理中的語句被執行完”的情況。

sql語言為事務處理提供了兩個重要的語句，它們是COMMIT和ROLLBACK語句。它們的使用格式是：

COMMIT WORK

ROLLBACK WORK

COMMIT語句用於告訴DBMS，事務處理中的語句被成功執行完成了。被成功執行完成後，數據庫內容將是完整的。而ROLLBACK語句則是用於告訴DBMS，事務處理中的語句不能被成功執行。這時候，DBMS將恢復本次事務處理期間對數據庫所進行的修改，使之恢復到本次事務未處理的狀態。