在正常運作中，伺服器應用程式進程中運行的應用程式元件會透過建立一個 CRM 工作元件來使用 COM+ CRM。 CRM 工作者實作針對其設計任務的 COM 介面。 應用程式元件必須在交易下執行，這樣CRM工作者才能繼承應用程式元件的交易。 CRM 人員始終需要交易。
若要存取 COM+ CRM，CRM 背景工作角色會先取得 ICrmLogControl 介面，讓 CRM 背景工作角色能夠將記錄寫入長期記錄。 CRM 工作人員會藉由建立 CRM 職員元件來取得此介面。
接下來，CRM 工作人員必須告訴 CRM 職員其要使用的 CRM 補償器名稱。 它會藉由呼叫 ICrmLogControl：：RegisterCompensator 方法來執行這項作業。 呼叫此方法之後，CRM Compensator 會在交易完成時由CRM基礎結構建立。
在CRM工作者註冊其CRM Compensator之後，可以使用ICrmLogControl將記錄寫入CRM日誌。 CRM 背景工作角色必須事先 寫;也就是說，它必須將記錄寫入記錄，描述動作實際執行動作之前，以防在完成動作之後立即發生當機。 如果沒有這些預先寫入的記錄檔記錄，就無法更正動作。
此外，「提前寫入」表示 CRM Compensator 是接收復原記錄檔的元件，必須處理這樣的情況：雖然記錄檔已寫入，但實際動作並未發生。 CRM 補償器的動作必須 等冪;也就是說，它們應該能夠執行多次，但應該會導致相同的結果。 例如，將帳戶餘額設定為 $100 的值是等冪動作;將 $100 新增至帳戶餘額不是。
ICrmLogControl 介面提供下列兩種方法來寫入記錄檔記錄：
- WriteLogRecordVariants 用於寫入由 Variants 組成的集合的結構化日誌記錄。 主要用於在 Microsoft Visual Basic 中開發客戶管理系統。
- WriteLogRecord 用於將非結構化日誌記錄寫入為位元組的 BLOB。 主要用於在 Microsoft Visual C++ 中開發 CRM。 由於 C 中的記錄結構通常是由一組可能散佈在記憶體中的標頭和欄位所組成，因此 writeLogRecord 方法會實作可減少數據複製的收集功能。
注意
您不應該在日誌紀錄的資料結構中使用指標類型。 指標變數在復原階段不再有效，因為CRM補償器是在與記錄日誌的CRM工作者不同的進程中運行的。 在記錄檔中包含指標類型可能會導致應用程式在復原期間崩潰或損毀。
這兩種寫入方法都會將記錄檔記錄寫入磁碟，但不保證記錄的持久性。 在允許延遲寫入在強制寫入磁碟之前累積以提升效能的同時，您可以改用 ICrmLogControl::ForceLog 方法，以確保 CRM 完成的所有寫入在磁碟上都是永久性的，這對故障復原非常重要。
當 CRM 背景工作角色執行其動作並完成寫入並強制記錄到記錄檔時，它必須釋放 ICrmLogControl。 當交易完成時（通常是因為呼叫 SetComplete 或 SetAbort的應用程式元件），CRM 基礎結構會建立 CRM Compensator 元件，該元件會實作 ICrmCompensator 介面或 ICrmCompensatorVariants 介面。 這些介面可用來將非結構化 （Visual C++） 或結構化 （Visual Basic） 記錄傳遞至 CRM 補償器，以及交易結果通知。
CRM Compensator 會首先收到交易完成準備階段的通知，並可以對準備要求投下贊成票或反對票。 如果CRM補償器投票反對，則不會收到任何進一步的中止通知。 如果對準備要求投票贊成，則會收到認可或中止通知。 在用戶端終止的情況下，不會收到任何準備通知，只會收到中止通知。 CRM 補償器必須準備好處理所有這些情況，此外還必須能夠應對 CRM 工作線程未成功寫入記錄的情況。 CRM Compensator 不得假設相同的 CRM 補償器實例會收到階段 1 （prepare） 和階段 2 （認可或中止） 通知，因為這些通知可能會因復原而中斷。
一般而言，CRM Compensator 會使用中止通知來反轉 CRM 工作人員所執行的動作。 如果CRM員工需要反轉其動作，可能會保留一些狀態以備使用。 該狀態可能會完全記錄在日誌中，如果不是，則在交易提交時，CRM 補償器需要清除該狀態。 這是CRM補償器收到認可通知的原因。 CRM Compensator 不在 DTC 交易中運行。
CRM Compensator 可以在需要時使用 ICrmLogControl來記錄新紀錄，此命令會在建立時被接收到。 CRM 工作人員和 CRM 補償器也可以遺忘他們撰寫的最後一筆日誌記錄，這可能是為了避免不必要的復原。
相關主題