• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Bulk Updates with Optimistic Lock

 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From WhizLabs, diagnostic exam, question 45.
WhizLabs wrote:Bulk update operations bypass the optimistic locking checks and directly map to the database.


Is this correct? Why it is designed to bypass the optimistic locking in this case?
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, this is correct, it bypasses the version check.
It does this because the version check is implemented in a way that it is a parameter to an update statement, for example "update book set ... where version = 17 and id = 1". Tthis SQL (not JPQL) when issues through JDBC returns the number of rows changes, and if it is 0, it means the book with id = 1 had a different version number in the database, and this in turn means you have an outdated book instance (the db would have its version higher), or that you messed up the version in the instance you have (that's why you are discouraged from doing anything about the version attribute). This is the case for a simple EntityManager.merge(). Note that the merge() operation takes only a single entity which you have (it is either managed or detached).
When you have a bulk update, you don't have the entities you want to bulk update, you just issue a query that goes straight to the database, and performs the update. There is no version to compare it to.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Raf. If that is true, I consider it as a bug.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic