Replication is based on an eventual-consistency model where the updates propagated through a connected network of servers will eventually be consistent on all servers over a short period of time.
In a typical update operation, a client application updates an entry or group of entries on a PingDirectory server with an ADD, DELETE, MODIFY, or MODIFY DN operation. After processing the operation, the PingDirectory server returns an LDAP response while simultaneously propagating the update to the other servers in the replicated topology. This simultaneous processing model allows the client to continue submitting update requests without waiting for a replication completion response from the server.
To support this processing model, replication never locks the targeted entries at the other PingDirectory server instances before an update can be made locally. This means that the replicated servers might have an inconsistent view of the targeted entry for a short period of time, but will catch up as the propagated changes are applied.
The eventual-consistency model also allows clients to complete update operations faster because clients can propagate a change without having to wait for replication. The rate of update operations remains the same no matter how many PingDirectory servers participate in replication.
Alternatively, you can configure assured replication for specific write requests to require local or global consistency, across data center locations, before a response is returned to the client. For more information, see Configuring assured replication.