事務(transaction)對於軟體工程師來說是乙個非常重要的概念。按照非正式的表述方式，事務是指一組作為同一單元的活動，要麼全部成功，要麼全部失敗。這種「全部或者沒有」的語義是資料庫訪問的基礎。按照正式的表述，事務包括如下屬性：原子性、一致性、隔離性和永續性(atomic、consistent、isolated和durable)——acid。
事務對於業務互動來說至關重要，為了保證一致性，乙個acid事務用到的資料庫條目通常會在處理過程中被鎖定。如果事務失敗，資料庫將會回退到之前的狀態。這一功能由資料庫提供商提供。
對於一組被呼叫的web服務，bpel也可以採用類似的思路，使用web服務的相應規範來實現業務流程的事務支援。wps 6.0提供了ws-atomic標準的支援。
但是，通常我們無法鎖定跨越企業的資源。當進行酒店預訂時，您的旅行**無法在預定過程中(或者在打預定**的過程中)鎖定酒店的預定資料庫或者讓系統主動停下來。取而代之的操作是，連鎖酒店資料庫的本地acid事務作為乙個整體，包括以下幾個任務：更新房間總量，新增資訊到預訂表和生成乙個確認號。如果旅行**需要取消預定操作，乙個補償動作將被完成。某些時候補償需要一定的代價。例如，如果預定取消得太晚，可能需要收取一定費用。
由於乙個業務流程可能需要執行幾天、幾個月甚至幾年，而且流程可能涉及外部服務。在流程完成前，單個活動有可能已經完成，如果隨後某個事件或錯誤發生而導致流程取消，已經完成的活動需要被復原。這種情況下，我們無法使用簡單的事務處理機制來實現回退，我們需要補償支援來完成這一任務。
補償是管理業務資料的一種特定方式，它總是業務邏輯的一部分。補償與資料庫為acid事務提供的原子性回滾不同。補償可以避免另外乙個問題;internet上的任何人都可以鎖定公司的資料可能會引發的拒絕服務攻擊。採用補償方案意味著資料不會被長時間鎖定，但同時也失去了acid事務，至少隔離性保證無法滿足，因為資料在最初的修改和補償操作之間是可見的。在bpel中，compensation(補償)用來還原已經完成的活動。一旦進行補償，它就要流程中已經執行完成的所有活動都會依照特定的邏輯進行補償。
在工作流中，每個invoke活動的呼叫都被稱為乙個**服務(forward service)，用於執行特定的服務呼叫。相關聯用於補償呼叫行為的服務被稱為補償服務。補償服務僅當**服務完成時才能夠被呼叫。當流程中發生故障時，執行可選的補償服務來補償**服務的行為。當乙個服務活動完成時，如果已經定義了補償服務，那麼就向工作流的補償域(compensation sphere)註冊補償服務及其輸入資料。在流程例項結束時，補償域檢視是否丟擲了故障。如果這個流程成功地完成，那麼就不需要補償任何活動。另一方面，如果這個流程失敗了，那麼您就需要執行補償。如果需要流程補償，補償域就會呼叫它在後進先出(last-in first-out)佇列(與**服務完成的次序相反)中註冊的補償服務。
如圖1所示是乙個結合了錯誤處理與補償機制的例子。第1個和第2個請求服務在同乙個作用域中，它們都成功完成呼叫，作用域成功結束。屬於流程作用域的第3個請求也成功完成。然而第4個請求呼叫卻失敗了，觸發了錯誤處理程式。在第6步，錯誤處理程式執行補償活動，將依次呼叫已註冊的補償處理程式，參見第7至第10步。
圖1 錯誤處理與補償機制示例
BPEL事務與補償機制
事務 transaction 對於軟體工程師來說是乙個非常重要的概念。按照非正式的表述方式，事務是指一組作為同一單元的活動，要麼全部成功，要麼全部失敗。這種 全部或者沒有 的語義是資料庫訪問的基礎。按照正式的表述，事務包括如下屬性 原子性 一致性 隔離性和永續性 atomic consistent ...
分布式事務 TCC補償機制
tcc事務是try commit cancel三種指令的縮寫，其邏輯模式類似於xa兩階段提交，但是實現方式是在 層面來人為實現。tcc開源框架bytetcc，tcc transaction，himly 1 先來try一下，不要把業務邏輯完成，先試試看，看各個服務能不能基本正常運轉，能不能先凍結我需要...
BPEL中的原子事務和補償服務區別和聯絡
錯誤報告 其他資訊以及批評 請郵寄到 jeffery.lee at gmail.com 或者訪問我的個人blog同我交流 本文遵從 gnu 的自由文件許可證 free document license bpel中的原子事務和補償服務區別和聯絡 原子事務實現了常見的提交和回滾特性，以促進對跨服務事務的...