hibernate lock mechanism
1. Pessimistic lock
It refers to the modification of data by outsiders hold a conservative attitude. The assumption that at any time access to data, may also have another client to access the same data, in order to maintain the consistency of data operations, so the data taken by the database-level locking, and to rely on database lock mechanism to achieve .
Jdbc-based implementation of database locking is as follows:
select * from account where name = "Erica" for update
In the update process, the database is in locked state, any other data for this operation will be delayed. Service after the submission of this unlock.
And pessimistic locking hibernate specific implementation is as follows:
String sql = "query";
Query query = session.createQuery (sql);
query.setLockMode ( "Object", LockModel.UPGRADE);
Here, it refers to the locking hibernate mode:
LockMode.NONE: no lock mechanism.
LockMode.WRITE: Hibernate Record in Insert and Update will automatically obtain the time.
LockMode.READ: Hibernate Record in read access time automatically.
These three are locked mode hibernate for internal use, and has nothing to do with the database locking:
LockMode.UPGRADE: the use of the database locked for update everything.
Here we must note that: only in the query prior to the beginning (that is, generate sql statements before hiernate) locking, will really lock mechanism through the database locking handle. Otherwise, the data has been passed does not contain a clause for updata the sql statement to load in, the so-called database locking it out of the question.
However, the performance of the system up to consider, for single or small systems, this is not a problem, but if it is on the network system, there will be much the same time-line, assuming that has hundreds or thousands or even many concurrent accesses, we how to do? If we wait until the database unlock operation for the following, we are the number of wasted resources? - This also led to the emergence of optimistic locking.
2. Optimistic locking
Optimistic locking (optimistic locking) is positive that the information access rarely happen simultaneously access the problem and therefore it is not for database-level locking, in order to maintain the correct data, the use of optimistic locking application logic implementation version control methods .
For example, if two clients, A to read the customer account balance 100 yuan, followed by B also read the customer account balance 100 of the data, A customer extract 50 million, made changes to the database when the database The balance of 50 yuan, B customers have to extract 30 yuan, according to information obtained by it, 100-30 for 70 the balance, if at this time and then make changes to the database, the final balance will be incorrect.
It does not support pessimistic locking strategy, data inconsistency but one happened, there are several solutions, one is to update the main one is to update the main post, the more complex is to check changes happen data to achieve, or the inspection of all property to achieve optimistic locking.
Hibernate in check through the version number to update the main post-implementation, this is the approach recommended by Hibernate in the database add a column VERSON Record, in the read data, together with the version number when read together, and when the incremental update data in the version number , and then than to the version number and database version number, if the database is greater than the version number will be updated, otherwise return error.
Just examples, A customer account balance read 1,000 yuan, in conjunction with reading the version number is 5, then, B customers at this time also to read account balance 1,000 yuan, the version number for 5, A post-paid customers in the account balance 500, at this time will be the version number plus one, the version number is currently 6, and the database version number is 5, so to be updated, update the database, the database at this time amounted to 500, the version number is 6, B recipients after the customer To change the database, its version number is 5, but the database version 6, this time not to update, B customer data to re-read the database of new data and re-flow before changes in the database business.
Hibernate version number in order to achieve control lock, we object to add a version property, such as:
public class Account (
private int version;
....
public void setVersion (int version) (
this.version = version;
)
public int getVersion () (
return version;
)
....
)
In the image file, we use optimistic-lock attribute set version control, <id> after an additional attribute column <version> label, as follows:
<hibernate-mapping>
<class name = "onlyfun.caterpillar.Account" talble = "ACCOUNT"
optimistic-lock = "version">
<id...../>
<version name="version" column="VERSION"/>
....
</ class>
</ hibernate-mapping>
After setting a good version control, in the above example, if B tries to update customer data, StableObjectStateException would trigger an exception, we can catch this exception, in the treatment and re-read the data in the database, at the same time B data with the current customer database data show up just to let customers have the opportunity to B than to inconsistencies in data to decide to change part of the design program or you can automatically read the new information and repeat the debit business processes, until the data can be updated so that this All can run in the background, rather than let your customers know.
However, optimistic locking has not solve the problem also exists: already mentioned above optimistic locking mechanism for implementation is often based on the system data storage logic, in our system implementation, from external system users to update the balance of forces beyond our control , may result in illegal data has been updated to a database. Therefore, we make e-commerce at the time, must be careful attention to the existence of the problem, using a more reasonable logic of authentication, to avoid the implementation of the wrong data.
Session can also use the load () or lock () when the specified lock mode for lock.
If the database does not support the specified lock mode, Hibernate will choose a suitable replacement lock, rather than out of an exception.
1. Pessimistic lock
It refers to the modification of data by outsiders hold a conservative attitude. The assumption that at any time access to data, may also have another client to access the same data, in order to maintain the consistency of data operations, so the data taken by the database-level locking, and to rely on database lock mechanism to achieve .
Jdbc-based implementation of database locking is as follows:
select * from account where name = "Erica" for update
In the update process, the database is in locked state, any other data for this operation will be delayed. Service after the submission of this unlock.
And pessimistic locking hibernate specific implementation is as follows:
String sql = "query";
Query query = session.createQuery (sql);
query.setLockMode ( "Object", LockModel.UPGRADE);
Here, it refers to the locking hibernate mode:
LockMode.NONE: no lock mechanism.
LockMode.WRITE: Hibernate Record in Insert and Update will automatically obtain the time.
LockMode.READ: Hibernate Record in read access time automatically.
These three are locked mode hibernate for internal use, and has nothing to do with the database locking:
LockMode.UPGRADE: the use of the database locked for update everything.
Here we must note that: only in the query prior to the beginning (that is, generate sql statements before hiernate) locking, will really lock mechanism through the database locking handle. Otherwise, the data has been passed does not contain a clause for updata the sql statement to load in, the so-called database locking it out of the question.
However, the performance of the system up to consider, for single or small systems, this is not a problem, but if it is on the network system, there will be much the same time-line, assuming that has hundreds or thousands or even many concurrent accesses, we how to do? If we wait until the database unlock operation for the following, we are the number of wasted resources? - This also led to the emergence of optimistic locking.
2. Optimistic locking
Optimistic locking (optimistic locking) is positive that the information access rarely happen simultaneously access the problem and therefore it is not for database-level locking, in order to maintain the correct data, the use of optimistic locking application logic implementation version control methods .
For example, if two clients, A to read the customer account balance 100 yuan, followed by B also read the customer account balance 100 of the data, A customer extract 50 million, made changes to the database when the database The balance of 50 yuan, B customers have to extract 30 yuan, according to information obtained by it, 100-30 for 70 the balance, if at this time and then make changes to the database, the final balance will be incorrect.
It does not support pessimistic locking strategy, data inconsistency but one happened, there are several solutions, one is to update the main one is to update the main post, the more complex is to check changes happen data to achieve, or the inspection of all property to achieve optimistic locking.
Hibernate in check through the version number to update the main post-implementation, this is the approach recommended by Hibernate in the database add a column VERSON Record, in the read data, together with the version number when read together, and when the incremental update data in the version number , and then than to the version number and database version number, if the database is greater than the version number will be updated, otherwise return error.
Just examples, A customer account balance read 1,000 yuan, in conjunction with reading the version number is 5, then, B customers at this time also to read account balance 1,000 yuan, the version number for 5, A post-paid customers in the account balance 500, at this time will be the version number plus one, the version number is currently 6, and the database version number is 5, so to be updated, update the database, the database at this time amounted to 500, the version number is 6, B recipients after the customer To change the database, its version number is 5, but the database version 6, this time not to update, B customer data to re-read the database of new data and re-flow before changes in the database business.
Hibernate version number in order to achieve control lock, we object to add a version property, such as:
public class Account (
private int version;
....
public void setVersion (int version) (
this.version = version;
)
public int getVersion () (
return version;
)
....
)
In the image file, we use optimistic-lock attribute set version control, <id> after an additional attribute column <version> label, as follows:
<hibernate-mapping>
<class name = "onlyfun.caterpillar.Account" talble = "ACCOUNT"
optimistic-lock = "version">
<id...../>
<version name="version" column="VERSION"/>
....
</ class>
</ hibernate-mapping>
After setting a good version control, in the above example, if B tries to update customer data, StableObjectStateException would trigger an exception, we can catch this exception, in the treatment and re-read the data in the database, at the same time B data with the current customer database data show up just to let customers have the opportunity to B than to inconsistencies in data to decide to change part of the design program or you can automatically read the new information and repeat the debit business processes, until the data can be updated so that this All can run in the background, rather than let your customers know.
However, optimistic locking has not solve the problem also exists: already mentioned above optimistic locking mechanism for implementation is often based on the system data storage logic, in our system implementation, from external system users to update the balance of forces beyond our control , may result in illegal data has been updated to a database. Therefore, we make e-commerce at the time, must be careful attention to the existence of the problem, using a more reasonable logic of authentication, to avoid the implementation of the wrong data.
Session can also use the load () or lock () when the specified lock mode for lock.
If the database does not support the specified lock mode, Hibernate will choose a suitable replacement lock, rather than out of an exception.
Responses to “Hibernate pessimistic locking mechanism for locking and optimistic locking”