Depending on the synchronization topology you have configured, an Access server may receive multiple updates from different sources at short time intervals. Successive updates may even conflict. For example, in a full mesh topology, an Access server may have a user's password updated to one value sync'ed over from one source, but that same user's password may be updated to a different value synced over from another source.
To resolve such conflicts, an Access server will finalize upon the update that has the latest timestamp. However, since synchronization of server clocks may not always be completely accurate, there could still be an inconsistency when an Access server receives conflicting updates. To overcome the possible inaccuracy in the synchronization of server clocks, an Access server uses a time buffer specified in the maximum-future-time-diff-millis parameter. Access will not update an entity if the update arrives sooner than maximum-future-time-diff-millis milliseconds from the previous update.
Consider the following example using the default value of maximum-future-time-diff-millis = 60000.
On Access Service 1, the password for User1 is changed to "abc" at time 09:02:00:000.
However, at approximately the same time, User1 is synchronized over to Access Service 1 from Access Service 2 which has set the password to be "def".
If the change synchronized over from Access Service 2 has a timestamp that is between 09:02:00:000 and 09:02:59:999, then User1's password will be "abc" because the password synchronized from Access Service 2 is ignored.
If the change synchronized over from Access Service 2 has a timestamp that is 09:03:00:000 or later, then User1's password will be "def" because the password synchronized from Access Service 2 is deemed to be later than the one set directly on Access Server 1 so it will be accepted.