{"id":55441,"date":"2022-09-09T11:38:07","date_gmt":"2022-09-09T06:08:07","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=55441"},"modified":"2022-09-13T11:42:41","modified_gmt":"2022-09-13T06:12:41","slug":"optimistic-locking-in-spring-boot","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/optimistic-locking-in-spring-boot\/","title":{"rendered":"Optimistic Locking in Spring Boot"},"content":{"rendered":"

Overview<\/strong><\/h3>\n

We know that for large-scale software applications that handle a large number of database transactions, implementing a concurrency management mechanism is essential so that we can handle multiple database calls simultaneously and effectively without any data loss<\/span>.<\/span><\/p>\n

One of the ways to implement concurrency control is the optimistic locking<\/strong> mechanism provided by Java Persistence API<\/strong>.<\/span><\/p>\n

Contrary to pessimistic locking, optimistic locking doesn\u2019t apply locks on the database and hence reduces the isolation level of the system and increases the throughput capacity of the software. Also, there is no chance of deadlock in this like in pessimistic locking.<\/span><\/p>\n

It allows transactional conflicts to occur and detects them while committing the transaction, and then we can handle the flow according to our use case.<\/span><\/p>\n

Implementation of Optimistic Locking<\/b><\/h3>\n

The implementation of optimistic locking is simple. It can be implemented using a new property <\/span>version<\/b> in the entity (annotating it with @Version). Although there have been multiple implementations of this attribute, the most effective and widely used is a simple integer type numeric counter type version whose value will be auto-incremented each time we update the data. We also need to ensure that the entity’s state is not getting fetched from the cache for this.<\/span><\/p>\n

\"\"<\/p>\n

Let\u2019s try to understand the use of the version attribute.<\/span><\/p>\n

\"\"<\/p>\n

1) Both investor1 and investor2 will fetch the same data with, let\u2019s say version=1,<\/span><\/p>\n

2) investor1 will be saved first, and the version will be automatically updated to 2(vesrion=version+1).<\/span><\/p>\n

3) now, when we try to save investor2, the query similar to the following query will be run<\/span><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>Update investor\u00a0<\/b><\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Set version=2, firstName=\u2019XYZ\u2019<\/b><\/p>\n

\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Where uuid=randomUuid<\/b><\/p>\n

\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 and version=1<\/b><\/p>\n

\u00a04) now as we know, that version is already updated by investor1 while saving, so no row will be fetched while updating investor2, and <\/span>optimisticLockingException <\/b>will be thrown for investor2 hence preventing the silent data loss of investor1.<\/span><\/p>\n

Handling of optimisticLockingException:<\/b><\/h3>\n

There are mainly two ways to handle this exception:<\/span><\/p>\n

1) In the catch block, we can fetch the data again for investor2, then try to make changes in the data if possible and then try saving the data again.<\/span><\/p>\n

2) The Second option could be that we just show a message to the user that either some other user updated the data or an error has occurred and ask the user to update the data again.<\/span><\/p>\n

So depending on our use cases, we can implement either of the above methods.<\/span><\/p>\n

Conclusion<\/h3>\n

Although optimistic locking cannot be implemented to handle all types of concurrency issues, whether to implement optimistic locking depends on a case-by-case basis. For example, it can be used where there are more read transactions than written transactions. It can be used where we don\u2019t want a single transaction to acquire the lock on a database or, in fact, where we can afford the loss of data. Also, like in pessimistic locking, it doesn’t put a lock on the data, so it can be used where we put data into a detached state after fetching it, but at the same time, needless to say, pessimistic locking provides greater data integrity.<\/span><\/p>\n

 <\/p>\n

<\/pre>\n
 <\/p>\n
<\/div>","protected":false},"excerpt":{"rendered":"
Overview We know that for large-scale software applications that handle a large number of database transactions, implementing a concurrency management mechanism is essential so that we can handle multiple database calls simultaneously and effectively without any data loss. One of the ways to implement concurrency control is the optimistic locking mechanism provided by Java Persistence […]<\/p>\n","protected":false},"author":1489,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":215},"categories":[446],"tags":[5015],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55441"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1489"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=55441"}],"version-history":[{"count":9,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55441\/revisions"}],"predecessor-version":[{"id":55465,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/55441\/revisions\/55465"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=55441"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=55441"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=55441"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}