When it comes to pessimistic locks and optimistic locks, it's about the concurrency of the database, and the higher the isolation level of the database, the worse the concurrency.
Concurrency:After the current system has been serialized, you read the database, others can not query, called concurrency is not good
1. Pessimistic lock
With exclusive (I lock the current data, than people do not see this data), pessimistic lock is generally by the database mechanism to do
pessimistic lock implementation: usually relies on the database mechanism, in the renovation process to lock the database, no other users can read or modify
pessimistic lock of the applicable scenario:
Pessimistic lock is generally suitable for short things more (such as a certain data after the addition of 1, immediately released)
Example:
User 1, User 2 read the data at the same time, but the user 2 first-200, then the database is 800, now the user 1 also start-200, you can user 1 just read the data is 1000, now users with just a start to read the data 1000-200, and the user 1 in the database in the update data is 800, the user 1 should be 800-200=600, so that the update is lost. This situation can be solved in two ways: pessimistic lock, optimistic lock.
Pessimistic Lock: User 1 Read the data, lock the data it reads, the user 2 is not read data, only the user 1 release lock after users 2 can read, the same user 2 read data is also locked, so you can resolve the update lost.
Entity classes:
public class Inventory {
private int itemno;
Private String ItemName;
private int quantity;
public int Getitemno () {return
itemno;
}
public void Setitemno (int itemno) {
This.itemno = ItemNo;
}
Public String Getitemname () {return
itemname;
}
public void Setitemname (String itemname) {
this.itemname = itemname;
}
public int getquantity () {return
quantity;
}
public void setquantity (int quantity) {
this.quantity = quantity;
}
}
mapping File:
use of pessimistic locks:
If you want to use pessimistic locks, you must lock the data when loading it, usually with a for UPDATE statement
Hibernate using load for pessimistic lock loading
Session.load (Class Arg (), Serializable Arg1,lockmode arg2) throws Hibernateexception
Lockmode: Pessimistic lock mode (commonly used Lockmode.upgrade)
Session = Hibernateutils.getsession ();
tx = Session.begintransaction ();
Inventory INV = (Inventory) session.load (Inventory.class, 1, lockmode.upgrade);
System.out.println (Inv.getitemname ());
Inv.setquantity (Inv.getquantity () -200);
Session.update (INV);
Tx.commit ();
If you use pessimistic locks, then lazy (lazy load) is invalid
2. Optimistic lock optimistic locking: Is not a lock, is a conflict detection mechanism, optimistic lock concurrency is good, because I change the time, others can arbitrarily modify the implementation of optimistic locks: commonly used is the version of the way (each datasheet has a version of the field versions, a user updates the database, Version number +1, another user modified after +1, when the user updates found that the current version of the database and read the data is inconsistent with the version number, equal to or less than the database version number is not updated.
hibernate use optimistic locks need to be configured in the mapping file to take effect
Entity Classes
public class Inventory {
private int itemno;
Private String ItemName;
private int quantity;
private int Version;//hibernate User-implemented version optimistic lock, but need to configure public
int Getitemno () {return
ItemNo
in the mapping file public void Setitemno (int itemno) {
This.itemno = ItemNo;
}
Public String Getitemname () {return
itemname;
}
public void Setitemname (String itemname) {
this.itemname = itemname;
}
public int getquantity () {return
quantity;
}
public void setquantity (int quantity) {
this.quantity = quantity;
}
public int getversion () {return
version;
}
public void setversion (int version) {
this.version = version;
}
}