Optimistic and pessimistic record locking
Overview of optimistic and pessimistic locking implementations in HCL Compass.
- Optimistic locking, where a record is locked only when changes are committed to the database
- Pessimistic locking, where a record is locked while it is edited
In both data-locking models, the lock is released after the changes are committed to the database.
By default, HCL Compass uses optimistic locking.
HCL Compass has support for pessimistic locking, which provides a mechanism to prevent situations where multiple users may edit a record at the same time. By enforcing sequential record modification, the pessimistic locking model ensures that users who attempt to update the same record simultaneously will be locked out. To enable pessimistic locking, you must create or upgrade the schema repository and associated user databases to feature level 7, and the schema developer must add hook code to the desired record types in the schema. For more information about modifying the schema, see the Help for developing schemas with the HCL Compassand the HCL Compass API reference.
The following sections describe the differences between optimistic locking and pessimistic locking in more detail.
Optimistic locking
The optimistic locking model, also referred to as optimistic concurrency control, is a concurrency control method used in relational databases that does not use record locking. Optimistic locking allows multiple users to attempt to update the same record without informing the users that others are also attempting to update the record. The record changes are validated only when the record is committed. If one user successfully updates the record, the other users attempting to commit their concurrent updates are informed that a conflict exists.
An advantage of the optimistic locking model is that it avoids the overhead of locking a record for the duration of the action. If there are no simultaneous updates, then this model provides fast updates.
Optimistic locking is a useful approach when concurrent record updates are expected to be infrequent or the locking overhead is high. In the HCL Compass implementation of optimistic locking, when multiple users edit a record concurrently, after one user's changes are committed, the other users' changes are rejected and data conflicts must be saved and manually merged.
Pessimistic locking
The pessimistic locking model prevents simultaneous updates to records. As soon as one user starts to update a record, a lock is placed on it. Other users who attempt to update this record are informed that another user has an update in progress. The other users must wait until the first user has finished committing their changes, thereby releasing the record lock. Only then can another user make changes based on the previous user's changes.
An advantage of the pessimistic locking model is that it avoids the issue of conflict resolution by preventing conflicts. Updates are serialized and each subsequent update starts with the committed record changes from the previous user.
Pessimistic locking is a useful approach when subsequent updates can be delayed until a previous update is completed. This usually implies that updates occur in a short time interval.