Check to verify that the optimistic lock can be set, that is, there is no external exclusive lock.
When there are other exclusive locks for the same record, O locks cannot be acquired.
The lock does not protect against external changes to data, but it does help to identify them.
O locks cannot guarantee that the currently accessed data is modified by other processes or users, but it can help detect such external change situations.
Upgrade of O lock:
-
Check the consistency of read data and optimistic locking.
-
Check and verify that the transition from an optimistic lock to an exclusive lock does not conflict with existing locks.
-
Sets all optimistic locks currently held externally as invalid (a so-called invalidation operation), propagating this change to external owners of optimistic locks.
-
The current optimistic lock is converted to an exclusive lock.
-
Modify the current data, after this modification is visible to all.
-
The lock is released.
The above steps 1-4 must be atomic operations.
Possible Lock Conflict Scenarios
- If the resource has been locked by user A with E lock, other users' requests for O lock on the same resource will fail.
As a result, other users cannot switch to Change mode.
- User A has successfully added an O lock, that is, switched to change mode, but when user A tries to save the modified data, the O lock held by another user has been upgraded to an E lock in advance.
In conflicts, an optimistic lock (lock mode O) behaves like a shared lock (type S hared), which means it conflicts with type E or type X locks.
When conflicts occur, O locks behave the same as shared locks.
Optimistic locking cannot be set if there are E locks belonging to other owners. It doesn't matter whether this E lock is directly assigned by other users or upgraded through a traditional O lock.
Existing optimistic locks also prevent other owners from taking E or X locks directly.
The figure below shows a situation where an optimistic lock cannot be set because an exclusive lock is already set on the object.
Optimistic locks belonging to different owners are compatible with each other. The first owner to attempt to convert an optimistic lock to an exclusive lock can do so successfully (provided no other ordinary shared locks are set). Other optimistic locks become invalid (removed from the lock table). You cannot set an exclusive lock if you try to change them.
The figure below is an example:
Transaction 1 converts optimistic locks to E locks. This invalidates the O-lock of transaction 2 (locking the same object). This means that transaction 2 cannot convert the O lock and the conflict must be resolved by the programmer.
