Conflict Resolution


Mastership restrictions prevent most inconsistent changes in different replicas, but some are unavoidable. To avoid many naming conflicts, the administrators for a family must create and enforce naming rules for objects. A use model that is enforced consistently across sites reduces the potential for conflicts. For example, the administrators for a family follow these rules:

Resolving Conflicts Among Type Objects

Two objects of the same type in the same VOB cannot have identical names. Accordingly, the syncreplica –import command detects a conflict when an update packet includes an operation that would create a type object with the same name as an existing object at the current replica. It resolves the conflict by creating the new type object with a different name.

For example, in Figure 3, two types created at two different replicas have the same name but are different objects. When the type created at the boston_hub replica is imported at the bangalore replica, it is not renamed because the bangalore replica does not contain a type with that name. However, when the type created at the sanfran_hub replica is imported at the bangalore replica, it is renamed because the bangalore replica already has a type with that name.

Figure 3 Resolving Conflicts in Names of Type Objects

syncreplica generates a warning message when it renames an object during import. To resolve the conflict, the Bangalore administrator must inform the Boston and San Francisco administrators of the name conflict, and they must take one of the following actions:

For more information, see Automatic Renaming of Type Objects and Replica Objects.