Original here: http://www.cn-java.com/download/hibrnate_dev_guide.pdf
Optimistic Locking relatively pessimistic, the optimistic lock mechanism has adopted a more relaxed mechanism. Most of the pessimistic locks rely on the lock mechanism of the database to ensure maximum exclusibility of operation. But then the database is a large number of overhead of database performance, especially for long matters, such overhead is often unbearable. Such as a financial system, when a operator reads the user's data, and performs modification based on the read user data (such as changing the user account balance), if the pessimistic lock mechanism is used, the entire operation process is meant Zhong (from the operator read data, start modification until the whole process of submitting the modification results, even including the time of the operator to cook coffee), the database record is always in a state of lock, you can imagine that if you face hundreds Concurrent, such a situation will cause what consequences. The optimistic lock mechanism solves this problem to a certain extent. Optimistic lock, mostly based on the Data version (Version) record mechanism. What is the data version? That is, add a version ID to the data, in a database based on the database table, generally achieved by adding a "Version" field for the database table. When reading the data, the version number is read by reading this version, and then updated, add one. At this time, the version data of the submitted data is compared with the current version information recorded by the database table. If the submitted data version number is larger than the database table current version number, it will be updated, otherwise it is considered expired data. For examples of modifying user account information above, assuming that there is a version field in the account information table in the database, the current value is 1; the current account balance field (Balance) is $ 100.1 operator A. Read it at this time ( Version = 1) and deduct $ 50 ($ 100- $ 50) from its account balance. 2 In the process of operator A operation, operator B also reads this user information (Version = 1) and deduct $ 20 ($ 100- $ 20) from its account balance. 3 Operator A completed the modification work, plus the data version number (Version = 2), and submitted to the database update with the account deduction (Balance = $ 50), at which time the submission data version is larger than the database record current version, data Updated, the database record Version update is 2.4 operator B completed the operation, and the version number is added (Version = 2) attempts to submit data to the database (Balance = $ 80), but at this time, it is discovered when the database records. The data version number submitted by the operator B is 2, the database record current version is also 2, which is not satisfied. "The submission version must be greater than the record of the current version to perform updates", so the submission of the operator B is dismissed. In this way, the operator B is possible to cover the operation result of the operator A with the result of the old data based on Version = 1. From the above example, it can be seen that the optimistic lock mechanism avoids the database lock overhead in long transactions (the operator A and the operator B operation, there is no biggest increase in the database data). System overall performance.
It should be noted that the optimistic lock mechanism is often based on the data storage logic in the system, so there is also a certain limitability. In the above example, due to the optimism lock mechanism is implemented in our system, user balance from external systems is updated. The operation is not controlled by our system, so that dirty data may be updated to the database. In the system design phase, we should take into account the possibility of these situations and make corresponding adjustments (such as implementing optimism lock policies in the database store process, external to data update channels based on this stored procedure, rather than The table is disclosed directly). Hibernate has built an optimistic lock in its data access engine. If you don't have to consider the update operation of the external system for the database, use Hibernate's transparet optimistic lock implementation, will greatly improve our productivity. Hibernate can be specified in conjunction with the Version descriptor through the Optimistic-Lock property of the CLASS descriptor. Now, we add an optimistic lock mechanism for the Tuser in the previous example. 1. First add an Optimistic-Lock property to the Class descriptor of Tuse: Name = "org.hibernate.sample.tuser"
Table = "t_user"
Dynamic-update = "True"
Dynamic-insert = "True"
Optimistic-Lock = "Version"
>
......
Optimistic-lock attributes have the following optional value:? None no optimistic lock? Version is optimistic to achieve optimistic lock through version mechanism? Dirty is optimistic to achieve an optimistic lock by checking all attributes. The optimistic lock mechanism is an optimistic lock implementation of Hibernate, and it is also hibernate, and the only lock mechanism is still unique in the case of data objects to be modified by session. Therefore, in general, we have chosen the Version mode as a Hibernate optimistic lock implementation mechanism. 2. Add a Version property descriptor
Name = "org.hibernate.sample.tuser"
Table = "t_user"
Dynamic-update = "True"
Dynamic-insert = "True"
Optimistic-Lock = "Version"
>
Name = "id"
COLUMN = "ID"
TYPE = "java.lang.integer"
>
COLUMN = "Version"
Name = "Version"
TYPE = "java.lang.integer"
/>
......
