Tip

Changing attributes to an object: Last writes don't always win

This tip was submitted to the SearchWin2000.com Tip Exchange by member Mark Bagley. Let other users know how useful it is by rating the tip below.


What happens if two people change the same attribute of the same object on different domain controllers prior to replication occurring? A popular belief is that the person who makes the last change to the attribute will win. However, this isn't necessarily so.

When a change is made to an attribute of an object, the attribute is "stamped" with the following information:

  • The change version number
  • The date and time at which the change was made (to the nearest second)
  • The GUID of the DC at which the change was made

    The change version number is a counter that keeps track of the number of times the attribute has been changed. If I change a user's first name 10 times, then this counter will be 11 (assuming that the user was given a first name when it was created).

    When replication occurs between two domain controllers where the same attribute of the same object has been changed on both, the stamps are compared to determine which change will win. The change version number is the most significant field within the stamp. It is checked before the time field in deciding which change will win. If the version numbers are identical, the times are compared. If the times are identical, then the DC GUIDs are compared. The GUIDs can never be equal, so this field is guaranteed to break the deadlock (usually the last DC promoted to the network will have the highest GUID).

    So, we have three scenarios to consider. Say we have two domain controllers with an administrator at each DC making a change to the same user object's first name (Fred).

    If both admins make a single change to Fred's first name at exactly the same time, and then replication occurs, the administrator at the DC with the highest GUID will win.

    If both admins make a single change to Fred's first name one second apart (or more), and then replication occurs, the admin who made his/her change last will win.

    If the first admin changes Fred's name, then realizes that he/she made an error and changes it again; then the second admin changes Fred's name, and then replication occurs, the first admin will win, regardless of whether the second admin made his/her change after the first admin's.

    Does all of this matter?

    In a well connected, highly available network, this will probably rarely be an issue. But it may help to explain the odd unexpected result when multiple admins are making changes to the same object.

    However, in a network where there is significant delay in replication, or a limited replication window, this effect may well need to be considered in determining day to day change processes.

    This was first published in February 2003

  • Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.

      Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.