Optimistic Locking

Oracle Health Insurance applications process workload from different users at the same time. An application can call integration points, allow users to use the Oracle Health Insurance user interface, and process generic HTTP requests at any moment. It is important to manage concurrent access to the application properly. This means handling changes made by all those simultaneous users in an effective and error-free way.

Oracle Health Insurance applications do that by using a technique called Optimistic Locking. In contrast with locking, the application does not lock data with a single user during change. Instead, it assumes optimistically that the current user is the only one who wants to make changes. Hence, the word optimistic.

Understanding Optimistic Locking

Every updatable object in Oracle Health Insurance has an object Version. It is a number that the system maintains and is hidden from the user. The object Version keeps track of the number of changes to the object. When a user queries data, the object Version is also retrieved.

When a user attempts to save changes to the system, the application checks the Version of the data again. The application checks whether the current data matches the one in the query and has the same object Version. This makes sure that no one changed the data since it was last read.

If another user has changed the data in the meantime, the Version is different. In that case, the application throws an OptimisticLockException and returns a message saying "<object> cannot be updated because it has changed or been deleted since it was last read".

Otherwise, the Oracle Health Insurance application changes the data and increments the object Version by one.

Scenario with Two Users

  1. User 1 retrieves Claim A and the object Version 1.

  2. User 2 retrieves the same Claim A with the object Version 1.

  3. User 2 makes a change.

  4. The change from User 2 commits successfully.

  5. Now, User 1 attempts to make a change, still having a record with object Version 1. This fails, as the system does not find any matching rows. The object Version is already incremented to 2 by User 2.

How Can User 1 Continue Working?

User 1 cannot save any changes, as this overwrites the changes by someone else (User 2). So, User 1 is forced to query the Claim again to get hold of the latest object Version 2. User 1 can redo changes to Version 2 and commit.

Advantages of Optimistic Locking

  • High throughput because of short locking times.

  • Prevents users from changing stale data.

  • Notifies the user of any locking violations immediately while updating data.

  • Prevent deadlocks in the application.

Disadvantages of Optimistic Locking

  • If multiple users change the same data, only the first one that makes the commit is successful.

  • Optimistic locking does not prevent users from selecting and changing the data that is being changed by other users at the same moment.

Optimistic locking is not a sign of a system error. If optimistic locking exceptions occur frequently it may be useful to prevent simultaneous changes to the same data by rethinking the work distribution and the workflow.