CODEWITHSUNDEEP
javamysql
Michael
Michael

Reputation: 591

How to properly implement Optimistic Locking at the application layer?

I am a little confused as to why Optimistic Locking is actually safe. If I am checking the version at the time of retrieval with the version at the time of update, it seems like I can still have two requests enter the update block if the OS issues an interrupt and swaps the processes before the commit actually occurs. For example:

latestVersion = vehicle.getVersion();
if (vehicle.getVersion() == latestVersion) {
    // update record in database
} else {
    // don't update record 
}

In this example, I am trying to manually use Optimistic Locking in a Java application without using JPA / Hibernate. However, it seems like two requests can enter the if block at the same time. Can you please help me understand how to do this properly? For context, I am also using Java Design Patterns website as an example.

Upvotes: 4

Views: 1339

Answers (2)

Mariusz Lotko
Mariusz Lotko

Reputation: 384

If you mean implementing some kind of safety on REST interface, please have a look at this article https://sookocheff.com/post/api/optimistic-locking-in-a-rest-api/ What this article is not mentioning is posaibility to enforce conditional PUT/PATCH and even DELETE with HTTP 428 error code. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/428

Your approach with relying on version seems to be legit to me. Also, you'll need to handle some kind of optimistic locking exception and also convert it to 412 code.

Upvotes: 0

Bill Karwin
Bill Karwin

Reputation: 562320

Well... that's the optimistic part. The optimism is that it is safe. If you have to be certain it's safe, then that's not optimistic.

The example you show definitely is susceptible to a race condition. Not only because of thread scheduling, but also due to transaction isolation level.

A simple read in MySQL, in the default transaction isolation level of REPEATABLE READ, will read the data that was committed at the time your transaction started.

Whereas updating data will act on the data that is committed at the time of the update. If some other concurrent session has updated the row in the database in the meantime, and committed it, then your update will "see" the latest committed row, not the row viewed by your get method.

The way to avoid the race condition is to not be optimistic. Instead, force exclusive access to the record. Doveryai, no proveryai.

If you only have one app instance, you might use a critical section for this.

If you have multiple app instances, critical sections cannot coordinate other instances, so you need to coordinate in the database. You can do this by using pessimistic locking. Either read the record using a locking read query, or else you can use MySQL's user-defined locks.

Upvotes: 0

Related Questions