标签:申请 数据对象 如何 数据不一致 数据库数据 覆盖 获取 程序员 数据库事务
在多个事务并发做数据库操作的时候,如果没有有效的避免机制,就会出现种种问题。大体上有四种问题,归结如下:
如果两个事务都要更新数据库一个字段X,x=100
事务A | 事务B |
---|---|
读取X=100 | 读取X=100 |
写入x=X+100 | 写入x=X+200 |
事务结束x=200 | 事务结束x=300 |
无 | 最后x=300 |
两个不同事物同时获得相同数据,然后在各自事务中同时修改了该数据,那么先提交的事务更新会被后提交事务的更新给覆盖掉,这种情况事务A的更新就被覆盖掉了、丢失了。
防止一个事务读到另一个事务还没有提交的记录。 如:
事务A | 事务B |
---|---|
无 | 写入x=X+100 (x=200) |
读取X=200 (读取了事务B未提交的数据) | |
无 | 事务回滚x=100 |
无 | 事务结束x=100 |
事务结束 |
事务读取了未提交的数据,事务B的回滚,导致了事务A的数据不一致,导致了事务A的脏读 !
一个事务在自己没有更新数据库数据的情况,同一个查询操作执行两次或多次的结果应该是一致的;如果不一致,就说明为不可重复读。
还是用上面的例子
事务A | 事务B |
---|---|
读取X=100 | 读取X=100 |
读取X=100 | 写入x=X+100 |
无 | 事务结束, x=200 |
读取X=200(此时,在同一个事务A中,读取的X值发生了变化!) | |
事务结束 |
这种情况事务A多次读取x的结果出现了不一致,即为不可重复读 。
事务A读的时候读出了15条记录,事务B在事务A执行的过程中 增加 了1条,事务A再读的时候就变成了 16 条,这种情况就叫做幻影读。
不可重复读说明了做数据库读操作的时候可能会出现的问题。
两个锁:
排他锁 被加锁的对象只能被持有锁的事务读取和修改,其他事务无法在该对象上加其他锁,也不能读取和修改该对象
共享锁 被加锁的对象可以被持锁事务读取,但是不能被修改,其他事务也可以在上面再加共享锁。
特别的,对共享锁: 如果两个事务对同一个资源上了共享锁,事务A 想更新该数据,那么它必须等待 事务B 释放其共享锁。
在运用 排他锁 和 共享锁 对数据对象加锁时,还需要约定一些规则,例如何时申请 排他锁 或 共享锁、持锁时间、何时释放等。称这些规则为封锁协议(Locking Protocol)。对封锁方式规定不同的规则,就形成了各种不同的封锁协议。
一级封锁协议是:事务 在对需要修改的数据上面(就是在发生修改的瞬间) 对其加共享锁(其他事务不能更改,但是可以读取-导致“脏读”),直到事务结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。
一级封锁协议不能避免 丢失更新,脏读,不可重复读,幻读!
二级封锁协议是:
1)事务 在对 需要更新的数据 上(就是发生更新的瞬间) 加 排他锁直到事务结束, 防止其他事务读取未提交的数据,这样,也就避免了 “脏读” 的情况。
2)事务 对当前 被读取的数据 上面加 共享锁 (当读到时加上共享锁),** 一旦读完该行,立即 释放该 该行的共享锁** - 从数据库的底层实现更深入的来理解,既是,数据库会对游标当前的数据上加 共享锁 , 但是当游标离开当前行的时候,立即释放该行的共享锁。
二级封锁协议除防止了“脏读”数据,但是不能避免 丢失更新,不可重复读,幻读 。
但在二级封锁协议中,由于读完数据后 立即 释放共享锁,所以它不能避免可重复读 ,同时它也不能避免 丢失更新 ,如果事务A、B同时获取资源X,然后事务A先发起更新记录X,那么 事务B 将等待事务 A 执行完成,然后获得记录X 的排他锁,进行更改。这样事务 A 的更新将会被丢失。 具体情况如下:
事务A | 事务B |
---|---|
读取X=100(同时上共享锁) | 读取X=100(同时上共享锁) |
读取成功(释放共享锁) | 读取成功(释放共享锁) |
UPDATE X=X+100 (上排他锁) | |
无 | UPDATING A(等待事务A释放对X的排他锁) |
事务成功(释放排他锁)X=200 | |
无 | UPDATE X=X+200(成功上排他锁) |
无 | 事务成功(释放排他锁)X=300 |
由此可以看到,事务A的提交被事务B覆盖了,所以不能防止 丢失更新。
如果要避免 丢失更新,我们需要额外的操作, 对凡是读到的数据加 共享锁 和 排他锁 ,这个往往需要程序员自己编程实现,比如在Oracle 中,需要加 SELECT FOR UPDATE 语句,表明,凡是该事务读到的数据,额外的加上排他锁,防止其他数据同一时间获取相同数据,这样就防止了 丢失更新 !
三级封锁协议是:二级封锁协议加上事务 在读取数据的瞬间 必须先对其加 共享锁 ,但是 直到事务结束才释放(与二级区别) ,这样保证了可重复读(既是其他的事务职能读取该数据,但是不能更新该数据)。
三级封锁协议除防止了“脏”数据 和不可重复读 。但是这种情况不能避免 幻读 和 丢失更新 的情况,在事务 A 没有完成之前,事务 B 可以新增数据,那么 当事务 A 再次读取的时候,事务B 新增的数据会被读取到,这样,在该封锁协议下,幻读 就产生了。 如果事务A 和 事务B 同时读取了资源X=100,同样,如果事务A先对X进行 更新X=X+100,等待事务A执行完成X=200,那么事务B 获得X的排他锁,进行更新 X=X+200,然后提交 X=300,同样A的更新被B所覆盖!( 如果要避免 丢失更新,我们需要额外的操作, 对凡是读到的数据加 共享锁 和 排他锁 ,这个往往需要程序员自己编程实现,比如在Oracle 中,需要加 SELECT FOR UPDATE 语句,表明,凡是读到的数据,我会加 排他锁,防止其他数据同一时间获取相同数据 ) !
进阶:repeatable read 导致死锁的情况(即便是 不同的资源在相同的顺序下获取 )。 比如 事务1 读取 A,同时 事务2 也读取 A,那么事务1和事务2 同时对 A 上了共享锁,然后事务1 要UPDATE A,而此时 事务2 也要 UPDATE A,这个时候 事务1 等待 事务2 释放其在 A 上的共享锁,然后 事务2 要等待 事务1 释放其在 A 上的共享锁,这样,事务1 和 事务2 相互等待,产生死锁!(SQL Server/DB2 里面有 UPDATE LOCK 可以解决这种情况,具体的思路是,在 repeatable read 的情况下,将读取的数据 上的 UPDATE 锁,介于 共享锁 和 排他锁之间的一种锁,该锁的作用是 当出现上面这种情况后,事务1 和 事务2 对 A 上的是 UPDATE 锁,那么谁先 要修改 A,那么该事务就会将 UPDATE 锁可以顺利升级为 排他锁对该数据进行修改!)
四级封锁协议是对三级封锁协议的增强,其实现机制也最为简单,直接对 事务中 所 读取 或者 更改的数据所在的表加表锁, 也就是说,其他事务不能 读写 该表中的任何数据。这样所有的 脏读,不可重复读,幻读 ,都得以避免!
标签:申请 数据对象 如何 数据不一致 数据库数据 覆盖 获取 程序员 数据库事务
原文地址:https://www.cnblogs.com/john8169/p/9256519.html