對已啟用目錄的應用程式的影響

版本扭曲

當應用程式在復寫變更之前，從不同的複本讀取相同的物件時，就會發生版本扭曲。 讀取遠端複本的應用程式會辨識未變更的物件。 當指定的應用程式或一組應用程式使用目錄中的數據進行互操作時，版本扭曲是個問題。

例如，RPC 服務可以使用標準 RPC API 在目錄中發佈其端點（例如 RpcNsBindingExport）。 用戶端會藉由查閱目錄中所需的端點來連線到服務（RpcNsBindingLookupBegin、RpcNsBindingLookupNext 等等），並系結至該服務。

假設 RPC 服務 S₁發佈端點 Es₁，然後移至不同的電腦。 原始端點 Es₁ 會變更為 E_s2， 反映新計算機的位址。 讀取目錄服務的遠端複本的用戶端無法連線到服務，直到復寫更新的端點為止。 不過，將服務從一部計算機移至另一部計算機是罕見的：因此，很少遇到此中斷/延遲，特別是如果服務移動是妥善規劃的。

部分更新

一般而言，當某個應用程式讀取一組數據時，另一個應用程式正在寫入同一組數據時，就會發生部分更新。 這是多宿主系統中任何應用程式可能發生的情況。 有許多方式可以發生這種情況。 您一次可以有多個應用程式寫入相同的數據集。 如果您以這種方式查看，目錄複寫服務只是另一個可能寫入另一個應用程式可能寫入另一個應用程式可能讀取的相同數據集。 這可能是應用程式的潛在問題。 不過，部分更新可能會影響應用程式的時間範圍相對較小。 如果應用程式不相依於多個物件的同步處理，這應該很少發生問題。 如果您的應用程式高度相依於一組相關物件的同步處理，您應該考慮應用程式設計中部分更新的效果。

就目錄複寫而言，當應用程式在復寫進行時，從不同複本讀取相同的物件集時，就會發生部分更新。 遠端複本上的應用程式會看到部分但並非全部的變更。

注意

部分更新可能會影響應用程式的視窗很小：應用程式必須在輸入複寫進行時開始讀取物件，在收到一或多個相關變更的對象之後，但在收到所有物件之前。 來源複本更新之間的時間直接影響到此視窗的大小—時間點會同時復寫在一起的更新。 當應用程式使用一組相關的物件時，部分更新可能會發生問題。

 

例如，遠端訪問服務可以使用 目錄來儲存原則和配置文件數據。 原則數據會儲存在一組物件中，而配置檔則儲存在另一個集合中。 當使用者連線到遠端訪問服務時，遠端訪問服務會讀取原則，以判斷使用者是否允許連線，以及是否要套用至使用者會話的配置檔。 部分更新可透過數種方式影響遠端訪問服務：

• 如果原則很複雜，且由多個物件所組成，遠端訪問服務可能會讀取部分更新的原則，而導致不正確的拒絕或授與服務給使用者、因內部不一致而無法處理原則等等。
• 如果原則和配置檔都已更新，服務可能會正確處理原則，但套用過時的配置檔，因為原則對象已復寫，但配置檔對象沒有。
• 如果配置檔很複雜，而且由多個對象所組成，服務可能會正確處理原則，但因為原則對象已復寫，但只有部分配置檔物件已這麼做。

衝突

當相同復寫間隔期間變更指定物件之兩個或多個複本的相同屬性時，就會發生衝突。 複寫程式會協調衝突;因為對帳，使用者或應用程式可能會「看到」他們所撰寫的值以外的值。

簡單的範例是使用者位址資訊：使用者變更復本 R1 上的郵件位址，而系統管理員變更復本 R2 的相同郵件位址。 寫入的值會傳播到衝突對帳機制從該值上選取另一個值為止。 只要值繼續對衝突解析程式中的其他值「獲勝」，值就會繼續傳播。 最後，如果沒有任何其他變更，此「獲勝」值將會傳播至 R1、R2 和所有其他複本。

衝突解決是應用程式的問題，這些應用程式會假設物件或物件集的內部一致性。 例如，網路頻寬配置管理服務會將指定網路區段的網路頻寬數據儲存在物件 O1 的目錄中。 物件包含每秒位可用的頻寬，以及任何單一使用者可以保留的最大頻寬。 服務預期用戶可保留的頻寬一律小於或等於可用的頻寬。

請考慮下列事件順序：

• 初始完全復寫狀態中的 物件會提供每秒 56 KB 的可用頻寬，而使用者可保留的頻寬為每秒 9,600 位。
• 復本 R₁的系統管理員會分別將值變更為 64k 和 19,200。
• 復本 Rー 的系統管理員會在 R₁更新送達之前，分別將值變更為 1000 萬和 100 萬。

假設有問題的屬性在更新發生時具有相等的版本號碼，則如果應用程式以個別的寫入作業執行更新，則對象最終會有最大頻寬為 64k，且使用者可保留的上限為 100 萬。 應用程式應該一律在單一作業中更新這兩個屬性。