Hibernate LockModes/LockOptions

Question

I am going through Hibernate Documentation an came across the LockModes. Are these same as Isolation levels that we use for database? How are they diff

Answer 1

Isolation Levels affect what you see.

Lock Modes affect what you are allowed to do.

The normal settings for hibernate are read-committed isolation and optimistic locks.

With optimistic locking, when two people try to edit the same data at the same time, the second one to commit will get an exception.

1. User 1 loads DomesticCat#1066 without upgrade lock.
2. User 2 loads DomesticCat#1066 without upgrade lock.
3. User 2 changes cat's name and commits.
4. User 1 changes cat's birthday, attempts to commit, an exception is thrown.

If pessimistic locks are in use, by selecting LockMode UPGRADE, then nobody else will be allowed to alter the data until the person who asked for the Lock UPGRADE releases it.

1. User 1 loads DomesticCat#1066 with upgrade lock.
2. User 2 loads DomesticCat#1066 without upgrade lock.
3. User 2 changes cat's name and attempts to commit. This operation is not allowed until User 1 releases the lock, so the database blocks and User 2's session sits and waits.
4. User 1 changes cat's birthday, commits.
5. User 2's update can now try to commit, but since they used optimistic locking now they will be the one who sees an exception.

The reason the query has to be executed as soon as you load when you upgrade is that it's implemented using the select ... for update statement and hibernate promises you that you'll have the lock when that method returns, so it has to execute the statement right away. When you don't need to hold the lock, hibernate can be lazy and defer loading the data until you show that you actually do need it.

Generally you upgrade the lock level when you have an operation that must complete regardless of what other people are doing. For example, when it's users, you can just show them the error and they can adjust their work and try again. But if the updates are being made by a messaging server or background process, handling exceptions and trying again can be very complicated, so it might be better to just lock the record so you can be sure your update goes in.