Conflict prevention

Available with Location Referencing license.

Conflict prevention improves support for multiuser editing by coordinating route and event edits in an enterprise geodatabase linear referencing system (LRS). To facilitate coordinated editing, ArcGIS Location Referencing enforces a set of conditions and behaviors that prevents users from editing a route or event without acquiring a lock.

The main principle of Location Referencing conflict prevention is: If a route or an event is locked for editing by a user in a database version, those routes or events cannot be edited by the same user in another database version or other users in any version.

Enable conflict prevention

Conflict prevention is supported only on an LRS dataset that is branch versioned.

Traditional versioning is supported in Location Referencing, but conflict prevention is not available in traditionally-versioned datasets.

Once your dataset is branch versioned, you need to run the Modify LRS geoprocessing tool with the Conflict Prevention option set to Enable.

Enable the Conflict Prevention option.

If conflict prevention is enabled, each editing tool will automatically acquire locks if available or alert you when locks cannot be acquired.

Route editing workflow for conflict prevention

An example conflict prevention workflow is shown using Retire Route. RouteY will be retired.

1. Click the Identify Route button and click RouteY.

   The Identify Route dialog box appears.

   

   The route identifier shows that no locks exist.

2. Verify that no locks exist on the selected route.

   Since the results do not show any locks, we know that no locks exist for that route.

3. After verifying that no locks exist on the route, click Retire on the Location Referencing tab.

   The Retire Route pane appears.

4. In the Retire Route pane, click the From Route Name button and click the route you want to retire.

   Once a route name is selected, an acquire lock message appears at the top of the pane.

   

   Acquired routes confirmation appears in the Retire Route pane.

   The locking message provides the following information:

   • The lock has been successfully acquired on RouteY.
   • The lock has been acquired by the portal user, user11.
   • The lock on RouteY for the database version, Version1, has been acquired by user11.

5. You can also confirm the existence of the lock by clicking Identify Route and RouteY again.

   

   The route identifier shows that the route has been locked.

   The Locked by you icon also confirms that you have locks for the identified route and can edit that route.

6. You can also identify existing locks using the LRS Locks button on the Location Referencing tab.

   Clicking this button displays the LRS Locks table.

   

   The Locks table shows the existence of the recently acquired lock.

Prevent conflicts

As described previously, the conflict prevention logic allows editing of a route and an event only by a single user in a single version at a time.

For example, if user22 tries to retire RouteY while the same RouteY is locked by user11, the following message appears:

The route cannot be edited by user22 when user11 has the locks.

The message provides the following information:

• RouteY cannot be edited because the lock belongs to someone else.
• The lock has already been acquired by the portal user, user11.
• The lock on RouteY for the database version, Version 1, has already been acquired by user11.

The route identifier shows the following result:

The Route Identifier shows the route is not editable due to existing locks.

The LRS Locks table shows the following information:

The locks table shows the lock on the route.

Ensure that the most recent version of the dataset gets edited

Edit the most recent version of the database so that all recent changes to the data are present in the version being edited. To confirm the most recent version, Location Referencing checks if a reconciliation with the default version is needed before acquiring a lock. When a version needs to be reconciled with the default, the following message appears:

The Acquire Locks dialog box Reconcile with the default version.

Clicking Yes when Acquire Locks appears will reconcile the editor version with the default version.

Note:

Make sure that any conflicts with the default version are reconciled before you edit the routes or events.

Learn more about how to reconcile and post edits to a branch version, resolve conflicts, and post changes.

You can choose to automatically reconcile prior to acquiring locks. With automatic reconciliation enabled, you can acquire a lock without reconciling unless conflicts are detected during reconciliation. To enable automatic reconciliation, see Set Location Referencing options.

The overall conflict prevention logic when editing a route is shown in the following chart:

The conflict prevention flowchart shows a typical version reconciliation workflow.

Types of locks

Conflict prevention inLocation Referencing has two lock types:

• Route locks
• Event locks

Route locks

Route locks prevent other users from editing a route and events on that route while the route is being edited. Route locks have the following properties:

• A lock is referred to as a route lock when a route in a network is edited.
• When a route is locked, only the user with the lock can edit the route and events on the route in the version in which the lock was acquired.

Event locks

Event locks prevent other users from editing an event layer for a specific route. An event lock is acquired for the event layer for a route.

If User1 has locked Event Layer1 for Route1 in Version1, then:

• No other user can edit Event Layer1 for Route1 in any versions.
• User1 cannot edit Event Layer1 for Route1 in any other versions except in Version1.
• Other people can acquire locks on other event layers (except Event Layer1) for Route1 or for any other route if a route lock doesn't exist for that route.
• No one can acquire a route lock if more than one person has event locks for that route.
• Other people can acquire locks on Event Layer1 for any other routes for which locks can be acquired.
• If editing an event requires an event lock on a route, it will be acquired.

Note:

• If multiple time slices of a route or an event exist, the acquired lock is valid for all the time slices.
• Locks are acquired by geoprocessing tools as needed.

The conflict prevention logic when events exist for a route is shown in the following chart:

Conflict prevention workflow when events exist on a route.

Conflict prevention during centerline editing

Where concurrent routes exist, routes are locked based on common centerlines. This concept can be explained using the following figure:

Locking concurrent routes.

• If Route X is edited, the lock will be acquired on Route X and no one else can acquire a lock on Route Y as they share a common centerline, C2.
• If Route Y is edited, the lock will be acquired on Route Y and no one else can acquire a lock on Route X as they share a common centerline, C2.
• If centerline C1 is edited (cartographic realignment or split centerline), only Route X will be locked.
• If centerline C3 is edited, only Route Y will be locked.
• If centerline C2 is edited, both Route X and Route Y will be locked as C2 is a shared centerline between those two routes.

Release locks

The locks are released automatically when:

• The version containing the locks is posted to the default version.
• The version containing the locks is deleted.

Locks can be manually released based on their releasable status.

If the releasable status value is Yes, the lock can be released by doing the following:

• Click the Release Locks button on the Location Referencing tab.
• Click the Release Locks button available in the LRS Locks table.

If the releasable status value is No, the lock can't be released.

If the releasable status value is On Post, the lock can be released only after posting to the default version.

Summary of conflict prevention rules

When conflict prevention is enabled, a user can edit a route after acquiring a lock on that route under these conditions:

• No one has a lock on that route in any versions of the database.
• The same user already has a route lock on that route present in the same version of the database in which they are currently working.

When conflict prevention is enabled, a user can't edit a route under these conditions:

• Reconciliation with default is necessary.
• Geodatabase conflicts exist in the current version.
• The route is already locked by another user.
• The same user already has a route lock on that route in another version of the database in which they are currently working.
• Another user has event locks on that route.
• The same user has event locks on that route in another version of the database.

When conflict prevention is enabled, a user can edit an event after acquiring a lock on that event layer under these conditions:

• No one has a lock on that event layer (for the route on which the event is located) in any database versions.
• The same user already has an event lock (for the route on which the event is located) in the same version of the database in which they are currently working.
• The same user already has a route lock (for the route on which the event is located) in the same version.

When conflict prevention is enabled, a user can't edit an event under these conditions:

• Reconciliation with default is necessary.
• Geodatabase conflicts exist in the current version.
• The event layer is already locked by another user for the route on which the event is located.
• The event layer is already locked by the same user for the route on which the event is located but in a different version.
• The route on which the event is located is already locked by another user.
• The route on which the event is located is already locked by the same user but in a different version.