To manage long transactions in the database, the geodatabase adopts an optimistic concurrency approach to data management. This means that when features and objects are modified, no locks are applied to the data; other editors may edit the same features, at the same time, in the same or another version of the database. This will inevitably introduce the potential for feature conflicts when versions are reconciled.

The absence of feature locks delegates the responsibility for safeguarding against version conflicts to workflow managers. Structuring the workflow in such a manner to avoid overlapping edits will reduce the likelihood of feature conflicts. A conflict will occur when a comparison of two version state lineages highlights features or rows that are found in both lineages but are different in some way. This situation can happen when:

• Two editors are editing the same data in the same version at the same time.
• The same feature is modified in two different versions.

There are two categories of conflicts:

1. The same feature has been updated in each version.
   
   
    
2. The same feature has been updated in one version and deleted in the other.
   
   

When conflicts are detected, the default behavior is for the target version's feature representation to take precedence over the edit session's representation. All conflicting features in the current edit session are initially replaced by their representation in the target version.

If multiple users are editing the same version and conflicts are detected, the feature or row that was first saved becomes the target version's representation and takes precedence over the second edit session's representation.

If the editor wishes to undo the results of the reconcile, the current edit session will revert to the prereconcile configuration of the data. If the editor opts to continue the process and resolve the conflicts, the features in conflict will be highlighted and a list of alternatives will be provided for selecting the required representation of the data.

Options for dealing with conflicts include:

• Replacing the features in conflict with the target version?s representation
• Replacing the features in conflict with the current edit version?s representation
• Replacing the features in conflict with the pre-edit version?that is, reverting to the representation of the data in the current edit session before the conflicting edit was made.