Show TOC

Background documentationHow Optimistic Locks Work Locate this document in the navigation structure


What distinguishes optimistic locks from other locks is that competing optimistic locks are at first compatible with each other and do not exclude each other. If there is a lock collision, it will not be verified until later. For the lock owner a lock collision manifests itself in an external change (noticeable by the current lock user) to the lock, whereby the optimistic lock becomes invalidated.

Process Flow

With optimistic locks data is changed in two phases:

Phase 1
  1. Check to verify that the optimistic lock can be set, that is, there is no external exclusive lock.

  2. Optimistic lock is set

  3. Data is read

The lock does not protect against external changes to data, but it does help to identify them.

Phase 2

This phase starts if the data is to be changed. The prerequisite is that the original read data has not been changed. The process steps are:

  1. Consistency of read data and optimistic lock is checked.

  2. Check to verify that the conversion of the optimistic lock to an exclusive lock will not collide with an existing lock.

  3. Propagation of the change to external owners of optimistic locks by invalidating the external optimistic locks.

  4. Optimistic lock is converted into an exclusive lock.

  5. The change itself is executed and becomes visible to all.

  6. The lock is released.

Steps 1-4 must be completed in an atomic flow –this means either all the steps must be carried out, or none at all. The change in the data causes a collision to be detected in external transactions by the check in step 2; phase 2 cannot be continued. A conflict resolution strategy needs to be implemented.

The graphic below shows the process flow:

This graphic is explained in the accompanying text.

Optmistic Lock in an SAP Transaction


Possible conflict scenarios:

  • Conflict in Phase 1

    The user’s attempt to set the optimistic lock fails, because the object has already been exclusively locked by another owner (or locked non-cumulatively by the same owner). The result is the user cannot switch to change mode.

  • Conflicts in Phase 2

    • The optimistic lock has been set, but when the user tries to save the (changed) data, it emerges that another optimistic lock has already been converted into an exclusive lock. In this process the optimistic lock has been removed from this transaction.

    • The optimistic lock is still valid, but an external shared lock (lock mode S), or an exclusive lock that the user has inherited, exists, which would collide with the optimistic lock when it is converted into an exclusive lock.

More Information

Optimistic Lock Conflicts