You are browsing the documentation for iTop 2.4 which is not the current version.

Consider browsing to iTop 2.6 documentation

Locking to prevent concurrent modifications

In order to prevent concurrent modifications of the same object, which leads to unexpected results, iTop (starting with version 2.2.0) implements a locking mechanism.

Principles and limitations

The mechanism is designed to protect from concurrent interactive modifications of the same object, either by two different users, or by the same user in two different tabs of her/his browser.

The mechanism does not prevent bulk modifications (bulk modify, CSV import, data synchronization…) to occur in the background. It only prevents two interactive users to overwrite each other's modifications.

In case of either a crash of the browser or a loss of connection, each lock has an expiration delay (configurable, by default 120 seconds).

In the unlikely event of a user acquiring the lock on a object and leaving with her/his browser still active (gone for lunch !), an administrator (the list of allowed profiles is configurable) can “kill” the lock to let another user take the ownership of the object and modify it.

This feature is disabled by default. To active it set the configuration parameter concurrent_lock_enabled to true in the iTop configuration file
'concurrent_lock_enabled' => true,

User interface

At the top of the “details” page of an object, a warning message is displayed when the object is being modified by another user:

Object locked by another user

The identifier (login) and the name of the user who is in the process of editing the object is indicated in the message. Shall you need to edit the object, you can either wait for the person to complete the modifications (press the 'refresh“ icon to update the status of the object) or get in touch with the person to understand what's happening. While the object is “locked”, all the actions to modify the object are disabled. The only remaining actions in the “actions” menu are the exports.

If the lock expires during the modification of the object (because of a loss of the connection or if the computer was put into sleep/power saving mode for too long a time) the user is warned that the lock has been lost by a popup message:

Lock lost, popup message

When the user closes this popup message, a notification remains at the top of the page and the “action” buttons are disabled (except the “Cancel” button):

Lock lost, buttons are disabled

The user can still copy/paste the current values of the object, before either hitting the “Cancel” button or opening a new tab and retrying the modification of the object.

Overriding the lock

Users with a specific (configurable) profile can “kill” this “lock”. Be aware that in such a case, the user currently editing the object may no longer be able to submit her/his modifications. This feature is provided only for emergency cases when the object must be updated while the “owner” of the lock is unreachable.

"Kill lock" menu

Once the lock has been removed, the detail view of the object is displayed again, with a feedback message at the top

Lock "killed"

The user who was modifying the object may not be warned that the lock has been killed until one minute. Therefore it is recommended to wait at least one minute after “killing” the lock, before editing the object.

Configuration

Three configuration parameters determine the behavior of the mechanism:

Parameter Type Visible ? Description Default Value
concurrent_lock_enabled bool Yes new in 2.2.0 Whether or not to enable the locking mechanism to prevent concurrent interactive modifications false
concurrent_lock_expiration_delay int No new in 2.2.0 The delay (in seconds) for a lock to expire (in case of a crash of the web browser or a loss of connection). While editing an object, the browser will call the server twice during this interval. Minimum value is 15s. Lower values provide a more responsive user interface but increase the load on the server and the network traffic. 120
concurrent_lock_override_profiles array No new in 2.2.0 The list of profiles which are allowed to “kill” a lock. The value is an array of profile names array('Administrator')
2_4_0/admin/locking.txt · Last modified: 2018/12/19 11:40 (external edit)
Back to top
Contact us