Principle
With the network version, concurrent accesses to objects can be checked using locks.
Preventing conflicts
As soon as a user modifies an object, a lock is placed on this object. Another user can thus only view this object. This user cannot access a new update until the first user dispatches his/her private workspace, and he/she refreshes his/her private workspace. This prevents conflicts between the state of the object in the repository and the obsolete view of the second user.
Deleting a lock or unlocking an object
Lock management is automatic. You do not normally need to delete locks or unlock objects.
The few exceptions are due to abnormal operations, for example when a private workspace has been deleted from the private Workspace management window, or at desynchronization of clocks.
When a lock is deleted, another user can modify the object without dispatching or refreshing his/her private workspace.
A user can delete locks placed on his/her private workspace since its creation.When a user dispatches his/her work, the lock (his/she had placed on an object) is unlocked but not deleted. The lock is deleted only when all other private workspaces, which were created before the lock was unlocked, are closed. A private workspace is closed when it is dispatched, discarded, or refreshed.
Details on the operating method of the locks
HOPEX only indicates that objects are locked when their attributes are modified (unlike links for example).
Warning on unlocking
If you attempted to use an object that was locked, a message alerts you as soon as the object is freed for you to use again.
Diagrams
There are two types of locking applied to diagrams
• The diagram has simply been viewed and not modified: as soon as the first user closes the diagram it can be opened by a second user.
• The diagram has been modified: as for classical locking, the second user must wait until the diagram has been dispatched by the first user and therefore unlocked.