MySQL database optimization (3)—MySQL pessimistic locking and optimistic locking (concurrency control)

1. Pessimistic lock
1. Exclusive lock. When a transaction operates data, this part of the data is locked until the operation is completed and then unlocked. , only other transaction operations can operate on this part of the data. This will prevent other processes from reading or modifying the data in the table.

## 2. Implementation: In most cases, it relies on the locking mechanism of the database to achieve

Generally use select ...for update locks the selected data, for example select * from account where name=”Max” for update, this sql The statement locks all records in the account table that meet the retrieval conditions (name="Max"). Before this transaction is committed (the lock during the transaction will be released when the transaction is committed), the outside world cannot modify these records.

2. Optimistic locking 1. If someone updates before you, your update should be rejected. Allows the user to re-operate.

2. Implementation: Most implementations are based on the data version (Version) recording mechanism

Specific details can be This is achieved by adding a version number or timestamp field to the table. When the data is read, the value of the version field is read out together. Each time the data is updated, the version value is incremented by one. When we submit an update, we determine the size of the current version information and the version value taken out for the first time. If the current version number of the database table is equal to the version value taken out for the first time, it will be updated. Otherwise, it will be considered as expired data and rejected. Update and let users re-operate.

3. Application of pessimistic lock and optimistic lock in ORM framework

Generally, pessimistic locks and optimistic locks need to be implemented through the setting of SQL statements, data design and code. For example, the version number field in optimistic locks is purely for database operations, and you need to implement optimism yourself. Locking, in short, means that the version number or timestamp field is maintained by the program itself, and self-increment, size determination, and whether to update are all implemented through code judgment. The database provides two ideas, optimistic and pessimistic, for concurrency control.

##For common java persistence frameworks, this mechanism of the database has its own implementation. Taking Hibernate as an example, let’s summarize the ORM framework Application of pessimistic lock and optimistic lock

1. Hibernate’s pessimistic lock:

Implementation of locking mechanism based on database. The following query statement:

##

String hqlStr ="from TUser as user where user.name=Max";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加锁
List userList = query.list();//执行查询，获取数据

Observe the SQL statement generated by Hibernate during runtime:

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, 
tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update

这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。对返回的所有user记录进行加锁。
2、Hibernate的加锁模式有：
Ø LockMode.NONE ： 无锁机制。
Ø LockMode.WRITE ：Hibernate在写操作（Insert和Update）时会自动获取写锁。
Ø LockMode.READ ： Hibernate在读取记录的时候会自动获取。
这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
Ø LockMode.UPGRADE ：利用数据库的for update子句加锁。
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。
注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

3、Hibernate的乐观锁

Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。具体实现方式如下：
现在，我们为之前示例中的TUser加上乐观锁机制。
实现一、 配置optimistic-lock属性：

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
           ……
     </class>
</hibernate-mapping>

optimistic-lock属性有如下可选取值：
Ø none：无乐观锁
Ø version：通过版本机制实现乐观锁
Ø dirty：通过检查发生变动过的属性实现乐观锁
Ø all：通过检查所有属性实现乐观锁

通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。
实现二、添加一个Version属性描述符

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user"   dynamic-update="true" dynamic-insert="true" optimistic-lock="version"> 
	<id name="id" column="id" type="java.lang.Integer">
		<generator class="native"/>
	</id>
	<version column="version" name="version" type="java.lang.Integer"/>
……
     </class>
</hibernate-mapping>

注意version 节点必须出现在ID 节点之后。这里声明了一个version属性，用于存放用户的版本信息，保存在TUser表的version字段中。

测试：

此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：

Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();

每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Max的用户进行操作，下面模拟并发更新时的情况：

Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Max"));
List userList = criteria.list();
List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();

     执行并发更新的代码，在tx.commit()处抛出StaleObjectStateException异常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。

     这就是hibernate实现悲观锁和乐观锁的主要方式。

四、总结

     悲观锁相对比较谨慎，设想现实情况应该很容易就发生冲突，所以我还是独占数据资源吧。

     乐观锁就想得开而且非常聪明，应该是不会有什么冲突的，我对表使用一个时间戳或者版本号，每次读、更新操作都对这个字段进行比对，如果在我之前已经有人对数据进行更新了，那就让它更新，大不了我再读一次或者再更新一次。

     乐观锁的管理跟SVN管理代码版本的原理很像，如果在我提交代码之前用本地代码的版本号与服务器做对比，如果本地版本号小于服务器上最新版本号，则提交失败，产生冲突代码，让用户决定选择哪个版本继续使用。
     在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法        另外，Mysql在处理并发访问数据上，还有添加读锁（共享锁）、写锁（排它锁），控制锁粒度【表锁（table lock）、行级锁（row lock）】等实现，有兴趣可以继续研究。

 以上就是MySQL数据库优化（三）—MySQL悲观锁和乐观锁（并发控制）的内容，更多相关内容请关注PHP中文网（www.php.cn）！