Can you summarize the following document?
        
  事務處理是被設計用來維持系統的完整性(通常是一個資料庫或是一些現代的檔案系統)在一個已知的,一致的狀態。具體過程是通過確保系統中的獨立操作全部成功完成或是全部成功取消。  例如,有一個典型的銀行事務要把$700從一個顧客的存款中移動到顧客的支票賬戶中。這個事務包括兩個單獨的計算機操作:從存款賬戶中取出$700,在支票賬戶中存入$700。如果一個操作成功,另一個沒有,那銀行的賬目到最後也不會平衡。因此必須有一種方法來確保兩個操作都成功或者都失敗,這樣銀行的資料庫中就沒有任何的不一致性。  事務處理連線單個不可分割的事務中的多個單獨的操作,並且確保事務中的所有操作都沒有錯誤或是沒有操作。如果一些操作完成但其他操作在完成時發生了錯誤,事務處理系統會“回滾”事務的所有操作(包括成功的那些),從而消除所有事務的痕跡並將系統恢復到之前處理事務開始時的一致,已知的狀態。如果事務的所有操作被成功完成,事務會被系統提交,所有資料庫中的改變變為永久性的;一旦這個操作完成事務不能再被回滾。  預防硬體和軟體錯誤的事務處理可能會讓一個事務部分完成,如果計算機系統在事務中間崩潰,事務處理系統會保證所有未被提交的事務中的操作會被中止。 通常來說,事務併發發行的。如果他們重疊(例如需要接觸資料庫的同一部分),就會導致衝突。例如,如果上述銀行例子中的顧客在他的存款賬戶中有$150並嘗試在同時將$100轉賬給另一個人和將$100轉到支票賬戶,只有其中的一個行為能夠成立。然而,迫使事務順序處理是低效的。因此,事務處理的併發實施被程式設計保證最終結果反映了一個沒有衝突的結局,如果以任何順序執行事務也能得到同樣的結果(一種叫做[可序列性]的屬性)。在我們的例子中,它表明無論哪個事務第一個發生,轉賬給另一個人成功或是將錢轉到支票賬戶成功,則另一個將會失敗。

  所有事務處理系統的基本原理都是一樣的。然而術語可以從一個事務處理系統到另一個事務處理系統而變化。下面所用的術語未必都是通用的。

  事務處理系統通過記錄資料庫改動時的中間狀態來確保資料庫的完整性,然後用這些將資料庫恢復到已知的狀態如果事務沒有成功提交。例如,資料中資訊的副本的優先順序高於它的改動資訊因為在事務做出任何改動之前會被系統晾在一邊(這有時被叫做前映像)。如果在事務被提交之前,他的任一部分出現了問題,那些副本將會被用來恢復資料庫到事務剛剛開始的狀態。

  為所有對資料庫管理系統的改動持續記錄成為一份單獨的日誌也是可能的(有時被稱為後映像)。他對於失敗事務的回滾來說不是必需的,但是在資料庫故障事件中對修正資料庫管理系統很有用,所以一些事務處理系統也支援。如果資料庫管理系統出現了整體故障,需要從最近的備份恢復。備份不會反映事備份之後提交的事務。然而,一旦資料庫管理系統被恢復,後映像的日誌就能使資料庫管理系統到最新狀態。任何程序中的事務在失敗的同時能被回滾。結果就是資料庫處於一個一致,已知的狀態包括到故障時刻提交的所有事務的結果。

  在一些案例中,兩個事務可能在他們處理的過程中,試圖同時接入資料庫的同一區域,某種程度上阻礙了他們的繼續進行。例如,事務A可能接入資料庫的區域X,事務B接入資料庫的區域Y。如果在那時,事務A嘗試接入資料庫的區域Y而事務B嘗試接入資料庫的區域X,死鎖就發生了,兩個事務都不能繼續進行。事務處理系統的設計能夠在死鎖發生時檢測到這些死鎖。通常兩個事務將會被取消和回滾,然後以不同的順序自動啟動,所以死鎖不再會發生。有時,死鎖中的一個事務會被取消,回滾,然後在一小段延遲之後自動啟動。  死鎖也會在三個或多個事務之間發生。涉及越多的事務,他們就越難被偵測到。簡要的說就是事務處理系統對檢測死鎖有一個實際的限制。

  在提交和回滾機制不可用或不可取的系統中,通常使用補償事務來撤銷失敗的事務並將系統恢復到先前的狀態。

  Jim Gray定義了一個可靠的事務系統的屬性,首字母縮寫為"ACID":atomicity(原子性),consistency(一致性),isolation(隔離性),durability(耐久性)。

  一個事務對狀態的改變是基元的,所有發生的或是不發生的。這些變化包括資料庫更改,訊息和感測器上的行為。

  一致性:事務是對狀態的正確轉換,以組為單位採取的行動不違反與狀態相關聯的完整性約束。

  即使事務併發執行,對於每個事務T來看,其他的事務都是在T之前或之後執行,但不是兩者都執行。

  一旦事務成功完成(提交),對狀態的改變從故障中倖存並被保留。

  事務處理有以下好處:

  標準的事務處理軟體,特別是IBM的資訊管理系統,最早是在20世紀60年代開發的,並且經常與特定的資料庫管理系統緊密耦合。客戶端-服務端計算在20世紀80年代實現類似的原則,取得了成功。然而,在最近幾年中,分散式客戶端-服務端計算已經變得相當難以去維護。隨著相應各種線上服務(特別是Web)的事務增長,單個分散式的資料庫已經不是一個實用的解決方案。另外,大多數包含一系列程式的線上系統一起操作,而不是單個伺服器可以處理事務的嚴格的客戶端-服務端模型。現在,大多數事務處理系統可用於程式級別工作和擴充套件到大型系統,包括大型機。 一個眾所周知的(開放)的行業標準是 X/Open分散式事務處理(DTP)(參見JTA,Java事務API)。然而,專利事務處理環境中,例如IBM的CICS還十分流行,雖然CICS也已經升級到包含行業標準了。 術語“極端事務處理”(XTP)已經被用來描述具有極其挑戰性要求的事務處理系統,特別是吞吐量要求(每秒鐘的事務)。這樣的系統可以通過分散式或叢集式架構來實現。
在電腦科學中,"事務"是無法被分割的操作,事務處理就是被分割為個體的資訊處理。事務必須作為一個完整的單元成功或失敗,不可能存在部分完成的事務。