Background: For the same record in the database, if two people modify the data at the same time and then finally synchronize it to the database, the result will be unpredictable because of the concurrency. The easiest solution is to add a version field to the record in the table. When modifying the record, you need to compare whether the version matches. If it matches, it will be updated, and if it doesn't match, it will fail directly. If the update is successful, version+1 is set, which is the so-called optimistic lock. Of course, such logic is best to be transparent to developers, and this plug-in is here to do this.
1. Usage method: Add the following configuration to the mybatis configuration file and it is completed.
<plugins> <plugin interceptor="com.chrhc.mybatis.locker.interceptor.OptimisticLocker"/></plugins>
2. Description of plug-in configuration:
The Java attribute corresponding to the optimistic lock column of the default database configuration for the plug-in is version. Here you can customize attribute life, for example:
<plugins> <plugin interceptor="com.chrhc.mybatis.locker.interceptor.OptimisticLocker"> <property name="versionColumn" value="xxx"/><!--Column name of the database--> <property name="versionField" value="xxx"/> <!--java field name--> </plugin></plugins>
3. Effect:
Previously: update user set name = ?, password = ? where id = ?
After: update user set name = ?, password = ?, version = version+1 where id = ? and version = ?
4. Description of version value:
1. When PreparedStatement obtains the version value, the plug-in will automatically increase by 1.
2. The entire control process of optimistic lock is transparent to the user, which is very similar to Hibernate's optimistic lock, and users do not need to care about the value of optimistic lock.
5. Plug-in principle description:
The plug-in intercepts the update statement executed by mybatis and adds an optimistic lock mark on the original SQL statement. For example, the original SQL is:
update user set name = ?, password = ? where id = ?,
Then the user does not need to modify the SQL statement. With the help of the plug-in, the above SQL statement will be automatically rewritten as:
update user set name = ?, password = ?, version = version + 1 where id = ? and version = ?,
Form, users do not have to care about the value before and after version. All actions are transparent to users, and the plug-in completes these functions themselves.
6. Default convention:
1. The Statements of the update statement intercepted by this plug-in are all PreparedStatement, which is only valid for SQL in this way;
2. The <update> tag of mapper.xml must correspond to the interface mapper method, that is, using the method recommended by mybatis, but multiple interfaces can correspond to a mapper.xml <update> tag;
3. This plug-in will not do anything to the results of SQL, and what SQL itself should return is what;
4. The plug-in intercepts all update statements by default. If the user does not want optimistic lock control for a certain update, then add @VersionLocker(false) or @VersionLocker(value = false) to the corresponding mapper interface method, so that the plug-in will not do anything to this update, which is equivalent to not having this plug-in;
5. This plug-in currently does not support optimistic locks for batch updates for the time being. The reason is that batch updates do not have many application scenarios in actual development, and it is difficult to develop optimistic locks for batch updates;
6. The parameter type of the Mapper interface must be consistent with the actual type passed in. This is because in the JDK version, there is no method below JDK8 to obtain the parameter list name of the interface. Therefore, the plug-in uses parameter types and parameters as mappings to match the method signature;
github address: https://github.com/xjs1919/locker
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.