Administer > Multimaster Mesh administration > Best practices for preventing mesh conflicts

Best practices for preventing mesh conflicts

This section lists measures you can take to minimize multimaster mesh conflicts.

The probability of multimaster conflicts varies depending on the following factors:

  • The number of servers under management—the more servers, the more likely that conflicts can occur.
  • The number of cores in the multimaster mesh.
  • The number of SA Clients being used by your SA users—the more users making updates, the more opportunities for conflicts.
  • The propensity for users to make changes in more than one facility by using different SA Clients.

Users

Your users should be aware of the following:

  • Users in multiple facilities are able to modify the same data at the same time, so when possible coordinate updates to avoid conflicts.
  • Users should not change data in one facility and immediately make the same change in another facility, because SA automatically propagates changes. Making the same change in multiple facilities will usually result in mesh conflicts.
  • A slight time delay occurs before changes that a user makes can propagate to other SA facilities. The length of delay varies depending on a number of factors, including network connectivity and bandwidth. If an update has not yet propagated to all the other Model Repositories in the mesh, wait a reasonable period of time to insure that the transaction has not been delayed before attempting to redo the transaction or perform another update that depends on other recent transactions.

Administrators

Implement the following best practices to reduce the chance of data conflicts:

  • Ensure that your network connections are reliable and there is sufficient network bandwidth between facilities in the mesh. The risk of conflicts increases as bandwidth decreases.

    See Network administration for a Multimaster Mesh for more information.
    See the SA Install section for information about network connectivity when running SA in a Multimaster Mesh.

  • When possible, partition your data space so that only one user can change the same object in different facilities concurrently.
  • Have a user, or a small group of coordinated users, manage a given set of servers. Partitioning the data space ensures accountability of server ownership and prevents users from changing each others data.

    The SA Client facilitates this by allowing you to set permissions by customer, facility, and user group types.

    See Permissions reference for more information about user groups and SA permissions.