Org.hibernate.lockmode.pessimistic_write behavior
I have two services that are called at about the same time with id = 1. Service1 starts first, then Service2. However, Service2 ends first before Service1. What should be the expected values of the myClass variable after both are completed (assuming the starting color is "BLUE" and the height = 5)? it
- myClass is color "GREEN", height 5
- myClass has a height of 12, color "BLUE"
- or is myClass color "GREEN" and height 12?
Here are my classes:
class Service1{
private MyDao myDao;
public void method1(Integer id){
MyClass myClass = myDao.get(MyClass.class,id,LockMode.PESSIMISTIC_WRITE);
//change myClass
myClass.setColor("GREEN");
update(myClass);
}
}
class Service2{
private MyDao myDao;
public void method2(Integer id){
MyClass myClass = myDao.get(MyClass.class,id,LockMode.PESSIMISTIC_WRITE);
//different change in change myClass
myClass.setHeight(12);
update(myClass);
}
}
class MyDao{
public Object get(Class clazz, Serializable id, LockMode mode){
return getHibernateTemplate().get(clazz,id,mode);
}
}
Here I am interested in the PESSIMISTIC_WRITE behavior. My actual code is written with spring and I am tracking down a specific issue where the update is not being called. My suspect is that this has to do with PESSIMISTIC_WRITE, but I'm now sure why I want to confirm its behavior.
source to share
What is pessimite blocking?
Pessimistic locking is an approach in which an object is locked until the transaction of that object is completed. Locking can restrict or prevent another custom form from working with this object in the database.
Blocking area
- The blocking volume can be
-
entire database (database lock),
-
table (table lock),
-
rowset (page locks) or
-
one line (row locks).
Lock mode in pessimistic
From the docs .
LockMode.WRITE is acquired automatically when Hibernate updates or inserts a row.
LockMode.UPGRADE can be acquired upon explicit user request using SELECT ... FOR UPDATE on databases which support that syntax.
LockMode.UPGRADE_NOWAIT can be acquired upon explicit user request using a SELECT ... FOR UPDATE NOWAIT under Oracle.
LockMode.READ is acquired automatically when Hibernate reads data under Repeatable Read or Serializable isolation level. It can be re-acquired by explicit user request.
LockMode.NONE represents the absence of a lock. All objects switch to this lock mode at the end of a Transaction. Objects associated with the session via a call to update() or saveOrUpdate() also start out in this lock mode.
Now, in your situation, no.2 will be the value if executed the first time. Then another update will be prohibited. Remember that a is LockMode.WRITE
obtained automatically after it is requested, this means that the current lock holder (which is myClass in method2) intends to update the object in your situation, it locks the row. It will then prevent anyone (myClass in method 1) from reading, updating, and deleting the object.
Hope this was clear.
source to share