Tuesday, December 10, 2019

Locking in Hibernate || JPA || Spring boot

https://www.baeldung.com/jpa-optimistic-locking

https://www.baeldung.com/jpa-pessimistic-locking

https://dzone.com/articles/concurrency-and-locking-with-jpa-everything-you-ne

Difference b/w Optimistic & Pessimistic Locking

It's good to know that in contrast to optimistic locking JPA gives us pessimistic locking. It's another mechanism for handling concurrent access for data.

We cover pessimistic locking in one of our previous articles – Pessimistic Locking in JPA. Let's find out what's the difference and how we can benefit from each type of locking.

As we've said before, optimistic locking is based on detecting changes on entities by checking their version attribute. If any concurrent update takes place, OptmisticLockException occurs. After that, we can retry updating the data.




We can imagine that this mechanism is suitable for applications which do much more reads than updates or deletes. What is more, it's useful in situations where entities must be detached for some time and locks cannot be held.

On the contrary, pessimistic locking mechanism involves locking entities on the database level.

Each transaction can acquire a lock on data. As long as it holds the lock, no transaction can read, delete or make any updates on the locked data. We can presume that using pessimistic locking may result in deadlocks. However, it ensures greater integrity of data than optimistic locking.


https://www.baeldung.com/java-jpa-transaction-locks

https://medium.com/slalom-engineering/optimistically-locking-your-spring-boot-web-services-187662eb8a91
In Spring Data, Optimistic Locking (last tutorial) is enabled by default given that @Version annotation is used in entities.

No comments:

Post a Comment