On mybatis optimistic lock plug-in

Background: for the same record in the database, if two people modify the data at the same time, and then finally synchronize to the database, the results are unpredictable because of concurrency. The simplest solution is to add a version field to the records of the table. When modifying the records, you need to compare whether the versions match. If they match, they will be updated, and if not, they will fail directly. If the update is successful, version + 1, the so-called optimistic lock, will be. Of course, such logic should be transparent to developers. This plug-in is to do this.

1. Usage: add the following configuration to the mybatis configuration file.

2. Description of plug-in configuration:

For the plug-in configuration above, the Java attribute corresponding to the optimistic lock column of the default database is version. Here, you can customize the attribute, for example:

3. Effect:

Before: 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 the Preparedstatement obtains the version value, the plug-in will automatically increment by 1.

2. The whole control process of optimistic lock is transparent to users, which is very similar to hibernate optimistic lock. Users do not need to care about the value of optimistic lock.

5. Description of plug-in principle:

The plug-in intercepts the update statement executed by mybatis and adds an optimistic lock flag on the basis of 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 =?, version = version + 1 where id = ? and version = ?，

Form, users do not need to care about the values before and after version. All actions are transparent to users, and the plug-in completes these functions by itself.

6. Default agreement:

1. The statements of update statements intercepted by this plug-in are preparedstatements, which are only valid for SQL in this way;

2、mapper. The < update > tag of XML must correspond to the method of interface mapper, that is, use the method recommended by mybatis, but multiple interfaces can correspond to one mapper < update > tag of XML;

3. This plug-in will not do any operation on the results of SQL. What SQL itself should return is what it should return;

4. The plug-in intercepts all update statements by default. If the user does not want optimistic lock control for an update, add @ versionlocker (false) or @ versionlocker (value = false) to the corresponding mapper interface method, so that the plug-in will not do any operation on this update, which is equivalent to the absence of this plug-in;

5. At present, the plug-in does not support batch update optimistic locks because there are few application scenarios for batch update in actual development. In addition, batch update optimistic locks are difficult to develop;

6. The parameter type of mapper interface must be consistent with the actual type passed in. This is because in JDK version, no method below jdk8 can 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