{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner
java,nosql,concurrency,tips and tricks,tools & methods,mongdb

MongoDB and Optimistic Locking

When moving from JPA to MongoDB, you start to realize how many JPA features you've previously taken for granted. JPA prevents "lost updates" through both pessimistic and optimistic locking. Optimistic locking doesn't end up locking anything, and it would have been better named optimistic locking-free or optimistic concurrency control, because that's what it does anyway.

So, what does it mean to "lose updates"?

A real-life example would be when multiple background tasks update different attributes of some common Entity.


In our example we have a Product Entity with a quantity and a discount which are resolved by two separate batch processors.

  1. the Stock batch loads the Product with {quantity:1, discount: 0}
  2. the Stock changes the quantity, so we have {quantity:5, discount: 0}
  3. the Discount batch loads the Product with {quantity:1, discount: 0}
  4. the Discount changes the discount, so we have {quantity:1, discount: 15}
  5. Stock saves the Product {quantity:5, discount: 0}
  6. Discount saves the Product {quantity:1, discount: 15}
  7. the saved quantity is 1, and the Stock update is lost

In JPA you may provide the @Version field (usually an auto-incremented number) and Hibernate takes care of the rest. Behind the scenes there is a safety mechanism that checks the updated rows number given a specific version. If no row was updated, then the version has changed and an optimistic locking exception is thrown.

UPDATE Product
SET quantity=1, discount=15
WHERE version=1; 

But if your storage is not a RDBMS system, but a Mongo database instead, you still want to prevent lost updates. Luckily Spring Data comes to the rescue, as it provides a set of Document oriented annotations, among which you can find a @Version annotation with the same semantic as its JPA counterpart.

An automatic retry mechanism should also be employed, as an optimistic locking exception is a recoverable one. It only needs to reload the latest Entity snapshot, merge the specific attributes and update.

So, Spring Data offers more than base repository support and simple query automation. The optimistic locking add-on provides the proper level of write consistency required by your application QoS.

Code available on GitHub

Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks