Replicas belonging to the same replication group on a replication client node are said to be consistent, if all of them have the same "age", i.e. all of them have been updated at the same time (it's assumed that replication updates contain complete groups). Replication protocol tries as hard as possible to keep replication groups in the consistent state. However, this is not always possible. Replicas may sometimes become inconsistent if a replication group is split into two or more parts, part of the group migrates to another server and a replication update of one of the parts is received before an update of other parts.
Example of an inconsistency: Assume there is a replication group consisting of two objects, A and B, on server node Server1. There is a pointer from B to A which defines the replication group. The client node Client has replicas of the replication group. Then:
The pointer from B to A is changed and the replication group is split into two groups on Server1.
The object B migrates to the server node Server2. The object A stays on the server Server1.
In the next replication update, Client receives an update of the object A from the server Server1.
In this case we say that the replica of the object B is in an inconsistent state on the Client, because it's in an older state than object A, has a pointer defining a replication group to A, but the objects should no longer be in the same replication group.
![[Note]](images/note.png) | Note |
|---|---|
A and B may also be groups of objects of course. | |
Inconsistencies can cause nasty problems. When working with inconsistent replicas, nothing can be assumed about objects the replicas reference. In this case, the pointer references a more recent version of the object replicas (which can be fatal if the objects mentioned are part of a dynamic data structure such as list). Pointers of inconsistent replicas could also reference non-local or non-existing objects.
This can't be prevented on replication servers and can't be fixed by replication client. The replication client can only detect this situation, and report it to the programmer.
For the programmer only one thing is important - some replicas may be marked as inconsistent for a while. How this can be detected is shown in Section 7.4, “Accessing Object Replicas”. If a replica is inconsistent, you can't trust its replication-group-defining pointers. They may point to another inconsistent replica, to a replica in a more recent state, to a local object (obviously in a more recent state too), or to a non-existing object.
Any automatic or semi-automatic optimizations, performed by the Core on replicas, require replicas to be consistent. If they are not, the optimization will not take place. For example, the replica-optimized const SRPC will not be optimized if the replica is inconsistent and the regular SRPC will be performed instead.