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). ArcGIS Location Referencing coordinates edits by enforcing a set of conditions and behaviors that require editors to acquire a lock before editing a route or event.

If a route or an event is locked for editing by an editor in a version, that route or event cannot be edited by the same person in another version or by others in any version. This is the main principle of Location Referencing conflict prevention.

Enable conflict prevention

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

Once the dataset is branch versioned, run the Modify LRS tool with the Conflict Prevention parameter set to Enable.

If conflict prevention is enabled, each editing tool automatically acquires locks, if locks are available, or alerts you when locks cannot be acquired.

Edit a route and create a lock for conflict prevention

The following conflict prevention workflow example uses the Retire Route tool. RouteX, RouteY, and RouteZ are part of LineXYZ. RouteX will be retired.

Routes are part of LineXYZ.

1. On the Location Referencing tab, in the Tools group, click Identify Routes and click RouteX.

   The Identify Routes pop-up appears.

   

   The Identify Routes pop-up shows that no locks exist.

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

   The previous example shows no locks exist for RouteX.

3. On the Location Referencing tab, in the Routes group, click Retire .

   The Retire Route pane appears.

4. Click Choose route from map 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 are confirmed in the Retire Route pane.

   The locking message provides the following information:

   • The lock has been acquired on LineXYZ.

     Note:

     RouteX is part of LineXYZ.

     Since RouteY and RouteZ are part of LineXYZ, they are also locked for editing.

   • The lock has been acquired by the portal user, User11.
   • The lock on LineXYZ for the named version, Version1, has been acquired by User11.

   Note:

   You will automatically transfer an existing route or line lock from another person to yourself if all of the following conditions are met:

   • The version that is owned by another person is public.
   • You are making the request in the same version in which another person has the lock.
   • If the lock version is a named version, the lock owner does not currently have an edit session open in that version. If the lock version is the default version, the lock owner does not currently have a read session open in the default version.

5. To ensure that the lock exists, click Identify Routes , and click and RouteX again.

   

   The Identify Routes pop-up shows that the route is locked.

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

6. Optionally, on the Location Referencing, in the Conflict Prevention group, identify existing locks using the LRS Locks button .

   The LRS Locks table appears.

   

   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 or line and an event only by a single person in a single version at a time.

For example, if User22 tries to retire RouteX while the same RouteX 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:

• LineXYZ cannot be edited because the lock belongs to someone else.

  Note:

  RouteX is part of LineXYZ.

• The lock has already been acquired by the portal user, User11.
• The lock on LineXYZ for the named version, Version1, has already been acquired by User11.

The Identify Routes pop-up shows the following result:

The route is not editable due to existing locks.

The LRS Locks table appears with the locks listed.

The LRS Locks table appears with the locks listed.

Ensure that the most recent version of the dataset is edited

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

Reconcile with the default version.

Clicking Yes when Acquire Locks appears reconciles the named version with the default version.

Note:

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

Learn more about reconciling and posting edits to a branch version, resolving conflicts, and posting changes

You can automatically reconcile prior to acquiring locks. With automatic reconciliation enabled, you can acquire a lock without reconciling unless conflicts are detected during reconciliation.

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

Types of locks

Conflict prevention in Location Referencing has the following lock types:

• Route and line locks
• Event locks

Route and line locks

Route and line locks prevent other people from editing a route and events on that route while the route is being edited.

Route and line locks have the following properties:

• A lock is referred to a route lock when a route in a continuous network is edited.
• A line lock is acquired when a route in an engineering network that supports lines is being edited. The complete line and all its routes are locked. A line lock means that if one person is editing one of the several routes that make up a line, no one else can edit any other route on that line.
• A locked route means that only the person with the lock can edit the route and its events in the version in which the lock was acquired, unless lock transfer conditions are met.

Event locks

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

If User1 has locked Event Layer1 for Route1 in Version1, the following apply:

• No one else 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 (point or line) that is registered to a network that supports lines, an event lock is acquired on a line.
• If editing an event (point or line) that is registered to a network that doesn't support lines, an event lock is acquired on a route.

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 during centerline editing

Where concurrent routes exist, routes are locked based on common centerlines. The following figure demonstrates this concept:

Locking concurrent routes is shown.

• If Route X is edited, the lock is 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 is 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 is locked.
• If centerline C3 is edited, only Route Y is locked.
• If centerline C2 is edited, both Route X and Route Y are locked as C2 is a shared centerline between those two routes.

Release locks

The locks are released automatically when the following occur:

• The version containing the locks is posted to the default version.
• The version containing the locks is deleted.
• Locks acquired in the default version as a result of using the route editing, centerline editing, or geoprocessing tools are released after the process is complete.

You can manually release locks based on their releasable status.

If the releasable status value is Yes, you can release the lock by doing the following:

• Click the Release Locks button on the Location Referencing tab.
• Click the Release Locks button 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.

Note:

You will automatically transfer an existing route lock from another person to yourself if all of the following conditions are met:

• The version that is owned by another person is public.
• You are making the request in the same version in which another person has the lock.
• If the lock version is a named version, the lock owner does not currently have an edit session open in that version. If the lock version is the default version, the lock owner does not currently have a read session open in the default version.

Summary of conflict prevention rules

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

• No one has a lock on that route in any version.
• The same person already has a route lock on that route present in the same version.

When conflict prevention is enabled, and the provided lock transfer conditions aren't met, you can't edit a route under the following conditions:

• Reconciliation with the default version has not been done.
• Geodatabase conflicts exist in the current version.
• The route is already locked by another person.
• The same person already has a route lock on that route in another version.
• Another person has event locks on that route (provided that the lock transfer conditions aren't met).
• The same person has event locks on that route in another version.

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

• No one has a lock on that event layer for the route on which the event is located in any version (provided that the lock transfer conditions aren't met).
• The same person already has an event lock in the same version in which they are currently working (for the route on which the event is located).
• The same person already has a route or line lock in the same version (for the route or line on which the event is located).

When conflict prevention is enabled, you can't edit an event under the following conditions:

• Reconciliation with the default version has not been done.
• Geodatabase conflicts exist in the current version.
• The event layer is already locked by another person for the route on which the event is located (provided that the lock transfer conditions aren't met).
• The event layer is already locked by the same person 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 person (provided that the lock transfer conditions aren't met).
• The route on which the event is located is already locked by the same person but in a different version.