2.5.4 防止并发修改
防止并发修改
为了使同一对象的防止并发修改导致意外结果，iTop（从版本2.2.0开始）实现了锁定机制。
原则和局限性
该机制旨在防止由两个不同的用户，或者由Herrhis浏览器的两个不同选项卡中的相同用户进行的相同对象交互式修改的并发交互保护。
该机制不会阻止后台中发生批量修改（批量修改，CSV导入，数据同步…）。它仅防止两个交互用户覆盖彼此的修改。
如果浏览器崩溃或连接丢失，则每个锁都有到期延迟（可配置，默认为120秒）。
在不太可能的用户的事态获得对象上的锁并让浏览器仍处于活动状态的情况下（去吃午餐！），管理员（允许的简档（角色）的列表是可配置的）可以“杀死”该锁，以使另一个用户采取该锁。对象的所有权并对其进行修改。
默认情况下，此特性是禁用的。要激活它，请在iTop配置文件中将配置参数并发 concurrent_lock_enabled to true
'concurrent_lock_enabled' => true,
用户界面
对象的“详细信息”页面顶部，当另一个对象修改对象时，显示警告消息：
消息中指出了标识符（登录名）和编辑对象的流程中的用户的名称。如果您需要编辑对象，则可以等待该人完成修改（按“刷新”图标以更新对象的对象），或者与该人联系以了解发生了什么。 “锁定”时，所有用于修改对象的状况均被禁用，“状况”菜单中仅剩余的状况是导出。
如果在修改对象期间锁失效（由于连接中断或计算机进入睡眠节能模式的时间太长），则会通过弹出消息警告用户：该锁已丢失：
当用户关闭此弹出消息时，通知保留在页面顶部，并且“功能”按钮被禁用（“取消”按钮除外）：
在单击“取消”按钮或打开新选项卡并重试对象的修改之前，用户仍可以复制粘贴对象的当前值。
覆盖锁
具有特定（可配置）简档的用户可以“杀死”该“锁”。请注意，在这种情况下，当前正在编辑对象的用户可能不再能够提交痔疮修改。仅在紧急情况下提供此特性，当紧急情况时必须更新对象，而锁的“对象”不可用。
取下锁之后，将再次显示对象的详细视图，并在顶部显示一条反馈消息。
修改对象的用户可能直到一分钟之前都不会被警告锁已被杀死。因此，建议在“杀死”该锁之后至少等待一分钟，然后再编辑对象。
配置
三个参数配置确定行为的机制：
| 参数 | 类型 | 可见吗？ | 描述 | 默认价值 | ||
| concurrent_lock_enabled | 布尔 | 是 | 2.2.0中的新增功能是否启用锁定机制以防止并发交互式修改 | 假 | ||
| concurrent_lock_expiration_delayint | 整型 | 没有 | 2.2.0中的新增功能锁定到期的延迟时间（以秒为单位）（如果Web浏览器崩溃或连接断开）。在编辑对象时，浏览器将在此间隔内两次调用服务器。最小价值为15s。较低的值可提供更灵敏的用户界面，但会增加服务器的负载和网络流量。 | 120 | ||
| 数组 | 没有 | 2.2.0中的新增功能允许“杀死”锁的简档（角色）列表。价值是简档名称的数组 | 数组（'管理员'） |
原贴链接：https://www.itophub.io/wiki/page?id=2_7_0%3Aadmin%3Alocking
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 parameterconcurrent_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
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') |