Understanding Scenario Locks

Different locks can be set on a scenario. For more details, please refer to Sections Understanding the Scenario Service Document Properties and Using the Scenario List Widget.

A user lock can be either a persistent lock or a session lock. The only difference is that a persistent lock remains present on the scenario until explicitly removed, while the session lock is automatically removed at the end of the user session, that is, when the user logs out of all his/her sessions, or when these sessions expire.

  • The user lock can be set by a user.

  • Once the lock is set, only the user who locked the scenario can modify the locked scenario.

  • When a scenario is locked with a persistent user lock, setting a session user lock replaces the persistent lock with a session lock, and vice versa.

  • Both persistent and session locks can be removed manually at any time.

A system lock is set by a job, that is, the execution of a task. Once the lock is set by a job, modifying operations on the scenario can only be performed in the scope of this job. For more details, please refer to Chapter Understanding the Execution Service.

  • The system lock is automatically removed when the job terminates. Should a crash prevent the lock from being removed, the user who launched the job and users with the PERMISSIONS_ADMIN role can remove it from the web client.

  • When a system lock is added or removed on a given scenario, a read-only lock is also added or removed on any visible scenario of this scenario. By doing so, the system ensures that the visible scenarios will not be modified during the execution of the job. However, since the data of these scenarios will not be modified by this job, the read-only locks do not prevent from running some jobs on the referencing scenarios of the scenarios locked with read-only locks.

  • The read-only lock is a type of system lock set by any job running on a referencing scenario. Once a read-only lock is set, any modification of the scenario will be refused. On the other hand, the scenario can still be visualized in dashboards and jobs can be launched on any referencing scenarios. The read-only locks are automatically removed when the job terminates. Like a normal system lock, should a crash prevent the read-only lock from being removed, the user who launched the job and users with the PERMISSIONS_ADMIN role can remove it from the web client.

A lock access requirement is emitted by a MODIFY operation on a scenario. This operation, performed by a given user, may be performed in the scope of a job, or not. For instance, a system lock can be put on a scenario by the Platform when using it in a job. The lock is owned by the job. In contrast, a user lock is put by a user, typically using the web client; In this case, the lock is owned by the user.

Such a requirement is decided using the following rules:

  • If the scenario holds a read-only lock, then the operation is refused.

  • If the scenario holds a user lock, then the lock must be owned by the user who performs the operation.

  • If the scenario holds a system lock, then the operation must be performed in the scope of the job that owns the lock.

As a few exceptions, lock access is additionally granted on some lock and unlock operations, so that:

  • A user may put or remove a user lock from the web client on a scenario on which s/he is currently executing a job.

  • A user may remove a system lock from the web client from a scenario on which s/he is currently executing a job.

  • A user with the PERMISSIONS_ADMIN role may remove any user, read-only or system lock.