Editing objects with pessimistic locking
Pessimistic concurrency involves locking objects in order to prevent other users from modifying the data. Other users cannot perform actions that would conflict with the lock until it is released. See also the Locking Modes chapter in the Object Type Customizer documentation.
When an object is opened for editing by a user, a lock for the object is created. As long as the lock exists, the object is locked for all other users. For better user experience, the following improvements in the pessimistic locking mechanism have been implemented:
 |
General use case scenario:
User B opens a ticket (INC1) and starts working on it. User C also tries to open the same INC1 ticket but he finds out that the INC1 ticket has already been locked by the User B. For this reason, he contacts User A who is already logged in as an administrator. The User A is able to release the lock so that the User C can finally work on the INC1 ticket.
Note: All tickets are set to the pessimistic locking by default.
See also Other locking scenarios.
The following actions and GUI elements are involved in the process:
Lock conflict
User B and User C are going to work on the same ticket:
User B opens the INC1 ticket.
The INC1 locks up.
If the User A, who is logged in as an administrator, opens the Pessimistic lock catalog, he can see a record of the User B locking the INC1 ticket.
Now User C also tries to open the same INC1 ticket.
The info message about the INC1 ticked being currently locked by the User B appears.
Note: The content of the message can be controlled in Global Settings and the Release lock editor.
User C notifies User B
The info message which appears to User C has the following options:
Notify
Select this option to notify the User B that you request the INC1 ticket.
If selected, an info message about your request appears to User B immediately.
Yes
If selected, you can check the INC1 ticket in the read-only mode.
No
Closes the info message.
Note: Depending on the role assignment, the users can also see the Show more details button in the message dialog box.
User C decides to notify the User B.
The info message about the request appears to User B.
As the User B is unwilling to release the ticket, nor does he get in touch with the requestor, the User C sends a request to User A to release the User's B lock.
User A (admin) releases the lock
Note that the User C must contact User A in a traditional way by phone or email, there is not a special request action available.
User A goes to the Pessimistic lock catalog and locates the User's B record.
User A selects Release lock from the right-click menu.
The Release lock editor opens.
User A checks and possibly edits the messages for the locking and requesting users and clicks OK.
Now the lock has been released and the predefined messages are sent to User B and User C.
Finally the User C can take over the INC1 ticket.
User C opens the INC1 ticket.
The INC1 locks up.