2

Recently I have been studying database transaction and one article quotes as following

JPA provide automatic support of row versioning via the @Version annotation.When you have entity with @Version annotatted field or property, optimistic locking will be enabled automatically.

My understanding is that database isolation level strategies are maintained using different locks like

  1. Read uncommitted: implemented with exclusive write-locks
  2. Read committed: implemented using shared read locks and exclusive write-locks.

so on. So, transactional isolation is implemented by different locking which I guess by using pessimistic locking.

My question is when a field is declared as @Version annotatted does it override the underlying default isolation level and optimistic locking take place ?

Bhupati Patel
  • 1,400
  • 2
  • 13
  • 18

2 Answers2

3

No, they are different things. By default, isolation level is configured to read-commited so no change could be read until transaction commit.

If you decide to use optimistic locking by means of @Version, you are not changing isolation level at all, but it is assumed you want to use read-commited isolation level, because I think it has no sense to use read-uncommited or read-serialized when you are using optimistic locking, but you can.

You define isolation level when creating transaction, usually you specify read-only mode, isolation level, propagation mode and a name for the transaction.

Optimistic locking is controlled by ORM infrastructure, taking care of object's proper number version when persisting. So, they are different things.

Hope it helps!

malaguna
  • 4,183
  • 1
  • 17
  • 33
2

No, you cannot override the underlying database's isolation level with JPA's optimistic locking.

If somehow you were able to do that, and doing that would be no good.

Most of the databases adopt READ_COMMITED isolation level as their default.

Consider the following scenario under READ_COMMITED isolation level.

  • Two Managers loads a Product entity
  • Both of them decides to increase price and then save it.
  • One price update gets committed before the other.
  • So one manager's Price will be overridden from the other manager's price with out managers knowing that.

Although this scenario is trivial, these kind of things could happen in non trivial scenarios.

This unintended scenario could have been avoided by using Optimistic Locking with the database's default isolation level.

Hope this helps.

tharindu_DG
  • 8,900
  • 6
  • 52
  • 64
  • tharindu_DG in my case I am using mysql database which default isolation level is repeatable read. So along with isolation level repeatable read I can use optimistic locking or pessimistic locking based on my requirement, right ? – Bhupati Patel Dec 23 '15 at 10:22
  • `repeatable reads` is a higher isolation level that `read committed`, because it not only blocks on writes but also on reads, to avoid `non-repeatable reads` problem. Anyway, I guess it is compatible with optimistic locking. – malaguna Dec 24 '15 at 09:50