事务丢失更新问题及乐观锁、悲观锁机制

2019-08-26 06:48:25来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

事务丢失更新问题及乐观锁、悲观锁机制

学习计划的第四天,仍然是对数据库事务方面进行学习。毕竟数据库操作在后端开发中有着举足轻重的作用。
那么,今天的学习内容是:事务丢失更新问题及乐观锁、悲观锁机制。
话不多说,进入正题。
什么是事务的丢失更新问题?
两个或多个事务更新同一行,但这些事务彼此之间都不知道其它事务进行的修改,因此第二个更改覆盖了第一个修改 。
这样说太抽象,举个例子:在数据库表中存在一条数据

id:100
name:张散
age:20

此时,两个管理员同时查询到了这条数据,此时,A管理员发现该数据的名字出错了,于是更新数据,将该数据改为

id:100
name:张三
age:20

然后A管理员提交了更新操作。这个时候,B管理员也发现该数据的年龄出错了,于是准备进行更改,但是B管理员根本就不知道A管理员进行了姓名的更改,于是B管理员进行了如下修改

id:100
name:张散
age:21

然后B管理员提交了更新操作。操作完成后,数据库表的数据变为了

id:100
name:张散
age:21

这时候问题就出现了,A管理员发现姓名出错进行了修改,而B管理员却把正确的名字给改了回去,B管理员的修改就覆盖了A管理员的修改,这种现象就是丢失更新。
贴张图方便大家理解。
在这里插入图片描述
那么该如何解决丢失更新问题呢?(丢失更新问题的解决)

  • 悲观锁(Pessimistic Locking)

  • 乐观锁(Optimistic Locking)

现在来依次解读两个方法解决丢失更新问题。
悲观锁原理:使用数据库内部锁机制,进行数据库表的锁定。就是在A管理员修改数据时,A管理员就将数据锁定,此时B管理员无法进行修改、查询。避免两个事务同时修改,也就解决了丢失更新问题。
很多人觉得这个名字很奇怪,为什么要叫悲观锁,可以顺带解释一下,因为我们假设丢失更新会发生,是一个悲观的态度。

还是举个例子实现一下:
在MySQL中,默认情况下,当你修改数据,会自动地为数据加锁,以防止两个事务同时修改数据,但是有个前提,就是必须在事务中才会自动加锁,事务和锁是不可分开的,锁一定是在事务中才能使用,当事务关闭锁自动释放。
开启两个MySQL窗口,并查询表数据
在这里插入图片描述
然后在两个窗口均开启一个事务,接下来在左边窗口输入

update account set money = money - 100 where name = 'ccc';

但是不要提交,然后两边分别查询数据
在这里插入图片描述
这个情况肯定是可以理解的,因为左边窗口未提交,所以右边窗口数据未改变。此时,在B窗口输入

update account set money = money - 100 where name = 'ccc';

会发现,当你执行该条语句后,数据库被阻塞了,因为数据被加上了锁,不允许两个事务同时修改。但是在左边窗口是可以进行数据修改的,右边窗口才会进入阻塞状态。
需要注意的是,虽然右边窗口无法进行修改,但是是可以进行查询的,所以这把锁是读锁。
由此,我们来了解一下MySQL的锁类型。
在MySQL内部有两种常用的锁,一种叫读锁,又叫共享锁;另一种叫写锁,也叫排它锁。一张表可以添加多个读锁,如果某张表添加了读锁,但又不是当前事务添加的,该表就不允许修改。添加读锁的sql语句为

select * from table lock in share mode;

演示一下。
在左边窗口开启一个事务,然后输入

select * from account lock in share mode;

此时该表就被加上了读锁,只允许加锁的事务修改。
现在,在两个窗口分别重新开启一个事务,然后分别输入

 select * from account lock in share mode;

此时,该表就被加上了两把读锁,这时候两个窗口都将不能修改表数据。如果在两个窗口分别执行更新语句,将会因为两个窗口都在互相等待对方释放锁从而发生死锁问题。
强调一下,读锁是非常容易发生死锁问题的。
接下来要分析的便是写锁了。

要注意,一张表只能加一个排它锁,排它锁和其它的共享锁都具有互斥效果。通俗一点说就是,一张表如果想加排它锁,在它之前,就不能加别的共享锁和排它锁。添加写锁的sql语句为

select * from table for update;

当一张表在一个事务中加上了写锁后,别的事务将不能够修改该表数据,因为修改数据会自动加上读锁,进而产生互斥。
那既然有两种方法可以解决丢失更新问题,那到底选择哪种方法是关键。
其实解决丢失更新问题是不能用读锁去解决的,而应该使用写锁解决,原因前面也说了,读锁的弊端是显而易见的。

我们可以使用写锁实现悲观锁来解决丢失更新问题。在原来的案例上加上写锁,B管理员在查询时会因为A管理员在修改数据而等待,直到A管理员提交了事务之后,锁被释放,此时B管理员允许查询,查询到的是A管理员修改后的数据,从而避免了丢失更新问题。

乐观锁原理:使用的不是数据库的锁机制,而是一个特殊标记字段,通过控制字段状态和内容得知数据是否发生了并发访问,正如其名,我们假设丢失更新不会发生,是一个乐观的态度,所以名为乐观锁。那特殊标记字段是什么呢?在实际开发中,一般用到该字段timestamp,(时间戳字段)。
演示一下。
创建一张表,并初始化数据

create table blog(
    id int primary key,
    title varchar(40),
    updatetime timestamp
);

insert into blog values(1,'java学习',null);

创建成功后,查询表数据
‘’
会发现,timestamp字段在插入时自动生成当前时间。
当你修改数据后再次查询,会发现timestamp字段会自动更新为当前时间。
根据该原理,上面的案例中,可以在数据表中新增一个timestamp类型的updatetime字段,然后A、B管理员分别查询数据,然后编写程序,比较用户提交的updatetime与数据表中的updatetime是否一致,如果一致,证明在你修改数据的过程中其他人没有修改过。而当A管理员提交修改后,updatetime字段会自动更新为当前时间,再当B管理员修改数据并提交时,程序比较updatetime字段,发现两者并不一样,证明数据已经被修改了,此时应该通知B管理员重新修改。


原文链接:https://www.cnblogs.com/blizzawang/p/11411341.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Java学习第十六天

下一篇:《Java 8 in Action》Chapter 5:使用流