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.
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:
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:
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):
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.
Once the lock has been removed, the detail view of the object is displayed again, with a feedback message at the top
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') |