Advanced types and causes of mesh conflicts

This section describes some causes and types of multimaster mesh conflicts.

• User overlap conflicts
• Conflicts from user duplication of actions
• Conflicts from out of order transactions
• Database conflicts

User overlap conflicts

Conflicts occur when a user concurrently makes a change using the SA Client in one facility at the same time another user makes a change to the same object in another facility.

For example:

1. Alice removes Node A from a server in the Atlanta facility.
2. Bob removes Node A from the same server in the Boston facility.
3. SA propagates the change from the Atlanta facility to the Boston facility; however, Bob has already removed Node A from the server in the Boston facility. SA generates a Model Repository Multimaster Component conflict alert, because now it appears that Alice is requesting that a node that does not exist be removed.
4. SA also propagates Bob’s update in Step 2 from the Boston facility to the Atlanta facility; however, Alice has already removed Node A from the server in the Atlanta facility. SA generates a second Model Repository Multimaster Component conflict alert.

Conflicts from user duplication of actions

Conflicts can also occur when a user, for various reasons, attempts make an update to a Model Repository, does not wait long enough for the update to propagate to the other Model repositories in the Mesh, thinks the update failed, and so attempts to make the update again, thus creating duplicate updates.

For example, this sequence of events could occur:

1. From a server in the Seattle facility, Carol uses the SA command line interface (CLI) to upload the package carol.conf.
2. Carol immediately logs in to the SA Client in the Phoenix facility and searches for the package. She does not see the package, because that data has not yet propagated from Seattle to Phoenix. Carol allowed enough time for data propagation between facilities.
3. Carol uploads the package carol.conf by using the SA Client in Phoenix.
4. When the data eventually propagates from Seattle, SA generates a conflict because the data already exists in Phoenix.

Conflicts from out of order transactions

Transactions between two facilities usually arrive in the order in which they were sent. However, if a third facility is involved in the transactions, the correct ordering is not guaranteed. For example:

1. A user changes or inserts data at Facility A (Model Repository A).
2. The transaction for that change propagates to Facility B (Model Repository B) and to Facility C (Model Repository C).
3. However, the data is modified again or referenced at Facility B (Model Repository B) and then propagated to Facilities A and C.
4. If the transaction from Facility B (Step 3) reaches Facility C (Model Repository C) before the transaction from Facility A (Step 1), a conflict occurs.

This conflict typically occurs when a user uploads a package using the SA CLI in one facility, and immediately uses the SA Client to add the package to a Software Policy in a different facility.

The occurrence of out of order transactions can be aggravated by concurrent updates in different facilities or problems with inter-facility network connections.

For example:

1. Henry uses the SA CLI on a server in the Denver Facility to upload the package henry.conf.
2. SA propagates data about the package to all facilities in the mesh; however, it cannot propagate the data to the Paris Facility because the network connection is down.
3. Henry logs on to a server in the Miami Facility and uses the SA Client to update the description of the package henry.conf.
4. SA propagates data about the updated package description to all other facilities in the mesh; however, it cannot propagate the data to the Paris Facility, because the network connection is still down.
5. Network connectivity to the Paris Facility is restored, and the delayed transactions from Steps 2 and 4 are propagated to the Paris Facility.
6. The transaction for the updated package description arrives at the Paris Facility before the transaction that uploaded henry.conf. Therefore, the Model Repository in the Paris Facility does not contain data about henry.conf, so SA generates a conflict alert.
7. The transaction uploading henry.conf arrives at the Paris Facility and is processed without error. The package data exists in the Paris Model Repository, but the package description differs from all the other facilities in the mesh.

Database conflicts

This section provides basic information about identifying the kind of conflicts you may have and the steps you can take to resolve them. See your Oracle database administration documentation for more information about identifying and resolving data and transaction conflicts.

The following table shows some types of conflicts:

Types of Conflicts

Conflict	Description
Identical Data Conflict	The Multimaster Tools show a conflicting transaction, but the data is the same between facilities. The data is the same, because users made the same change in different facilities.
Simple Transaction Conflict	The row exists in all facilities, but some columns have different values or the row does not exist in some facilities (missing objects).
Unique-Key Constraint Conflict	The object does not exist in a facility and cannot be inserted there, because inserting it would violate a unique-key constraint.
Foreign-Key Constraint Conflict	The row does not exist in some facilities and cannot be inserted, because the data contains a foreign key to another object that also does not exist in that facility.
Linked object conflict	A type of conflict encountered in rare cases. SA includes business logic that links specific related objects in SA, such as a custom attribute name and value, and a customer created in the SA Client (appears in lists) and the associated node for the customer in the node hierarchy. SA ensures that links between related objects are maintained. Resolving a linked object conflict can be complex, because you must attempt to preserve the intent of the transaction that caused the conflict. Contact your HPE Server Automation Support Representative to help you resolve linked object conflicts.

When you cannot follow one of the preceding guidelines, attempt to preserve the intent of the transaction. Contact the users who are generating the transactions and determine what types of changes in the managed environment each user was trying to make.

Identical Data Conflict

All objects in a transaction contain exactly the same data across all facilities. This type of conflict includes the case where the objects do not exist in all facilities.

To resolve an identical data conflict, simply mark the conflict resolved.

Identical Data Conflict (Locked)

All objects in a transaction contain exactly the same data across all facilities, but the objects in the transaction are still locked (marked conflicting).

To resolve this type of conflict, pick an arbitrary facility and synchronize all objects from it. Performing this action unlocks the objects. After synchronizing the data, mark the conflict resolved.

Simple Transaction Conflict

The data is different between facilities or some objects are missing from some facilities. None of the objects depends on the actions of other conflicting transactions. The results of synchronizing the objects does not result in a database foreign-key or unique-key constraint violation.

To resolve a simple transaction conflict, choose the facility that contains the correct data and synchronize from it. How you determine which facility contains the correct data varies depending on the type of transaction:

• If the conflict is the result of two users overriding each others work, talk to the users and determine which user’s change should be correct.
• If the conflict is the result of automated processes overriding each others data, the most recent change is usually correct.
• If the conflict is the result of out-of-order transactions, the most recent change is usually correct.

After synchronizing the data, mark the conflict resolved.

Unique-Key Constraint Conflict

Resolving these conflicts results in a unique-key constraint violation.

For example, this sequence of events occurs:

1. From the SA Client in the London Facility, John creates Node A1 as a subordinate node of Node A.
2. From the SA Client in the San Francisco Facility, Ann performs the same action. She creates Node A1 as a subordinate node of Node A.
3. Node names must be unique in each branch of the node hierarchy.
4. SA propagates the node changes from the London and San Francisco facilities to the other facilities. Inserting the rows into the Model Repository databases at other facilities causes a unique-key constraint violation and a conflict.

Resolving this conflict by inserting the updates from the London Facility in all facilities would fail with the same unique-key constraint violation.

Perform the following steps to resolve a unique-key constraint conflict:

1. Locate all the involved transactions, and synchronize one transaction from a facility where the object does not exist, thereby deleting it in all facilities.
2. Synchronize the other transaction from a facility where the object exists, thereby inserting the object in all facilities. One of the two uniquely conflicting objects will take the place of the other.

Foreign-Key Constraint Conflict

Resolving these conflicts results in a foreign-key constraint violation.

For example, this sequence of events occurs:

1. Jerry creates Node B in Facility 1.
2. Before that transaction has time to propagate to other facilities, Jerry creates Node C as a subordinate node of Node B.
3. When the first transaction arrives at Facility 2, it generates a conflict for unrelated reasons.
4. When the second transaction arrives at Facility 2, inserting the row for Node C causes a foreign-key constraint conflict, because the parent Node (Node B) does not exist.

Resolving the second conflict first by inserting the update for Node C into all facilities would fail with the same foreign-key constraint violation.

Perform the following steps to resolve a foreign-key constraint conflict:

1. Resolve the conflicting transaction for Node B (the parent Node) by synchronizing the first transaction from the facility where the object exists.
2. Synchronize the second transaction (the Node C update) from the facility where the object exists.

Generally, resolving conflicts in the order in which they were created avoids generating foreign-key constraint conflicts.