Getting started 29 - optimistic lock
Pessimistic locks When accessing data at all times, another customer is also accessing the same data, thus adopting the database hierarchical lock state, and other customers cannot access the data in the locked time. For stand-alone or small systems, this is not a problem, however if there is a system on the network, there will be many online, if each read data is locked, the subsequent access must be waiting, this will There is a problem that the function is caused, causing a long time waiting for the successor. Optimistic Locking is optimistic that the access of the data rarely occurs at the same time, and thus does not make the locks at the database level, in order to maintain the correct data, optimistic lock uses the logic implementation version control on the application. . For example, if there are two clients, the A customer first reads the account balance 1000 yuan, and then B customers also read data of the account balance of 1000 yuan, and the client has extracted 500 yuan, and the database is changed. At this time, the database The balance is 500 yuan, and the B customer has to extract 300 yuan. According to the information it makes, the 1000-300 will be 700 balance. If the database is changed, the last balance will be incorrect. In the case where the pessimistic lock strategy is not implemented, the data is inconsistent, there are several solutions, one is the first update, one is the main update, more complicated is to check changes. Data is implemented, or check all properties to achieve optimism lock. Hibernate is updated by the version number, which is also recommended by Hibernate. Add a Verson column record in the database. Read together with the version number when reading, and increment when updating data No., then align the version number and version number in the database, if it is greater than the version number in the database, it will be updated, otherwise the error is returned. With the examples just now, the A client reads the account balance of 1,000 yuan, and the client also reads the version number 5, B customers also read the account balance 1000 yuan, version number is also 5, A customers are in the account balance after the customer For 500, at this time, the version number plus 1, the version number is currently 6, and the version number in the database is 5, so after updating the database, the database is updated, the database is at this time, the version number is 6, b customers after the customer To change the database, its version number is 5, but the version number of the database is 6, the B customer data rereads new data in the database and re-performing the business process to change the database. With Hibernate, the version number control is locked, and our object adds a version attribute, for example:
Public class account {
Private int.
....
Public void setversion (int version) {
THIS.VERSION = Version;
}
Public int getversion () {
Return Version;
}
....
}
In the image file, we use the Optimistic-Lock property to set the version of the Version control, the
Optimistic-Lock = "Version"> .... After setting the version control, in the previous example, if b Customer tries to update the data, it will trigger the StableObjectStateException exception, we can capture this exception, reread the data in the database, while the current data and databases of B customers The data show comes out, let B customers have the opportunity to compare the inconsistent data to determine some of the parties to be changed, or you can design the new information to automatically read new information, and repeat the deduction business process until the data can be updated. All can be performed on the background without having to let your customers know.
