MVCC locks acquired for querying (reading) data do not conflict with
locks acquired for writing data,and so reading never blocks writing
and writing never blocks reading
因此,even for READ_COMMITTED,UPDATE语句将锁定当前受影响的行,以便其他事务无法修改它们,直到当前事务提交或回滚为止.
如果并发事务在锁定的行上发出UPDATE,则第二个事务将阻塞,直到第一个事务释放它的锁.
>这种行为是trying to prevent the write-write conflicts吗？
>丢失的更新仍然可以在READ_COMMITTED中发生,因为在第一个事务提交之后,第二个将覆盖该行(即使数据库在UPDATE查询开始和查询结束之间已经更改).因此,如果仍然可以丢失更新,为什么第二笔交易必须等待？是否可以使用行级快照来存储未提交的事务更改,以避免事务必须等待释放写锁？
为了避免脏写,快照隔离的原始定义是“第一个提交者获胜” – 也就是说,允许发生冲突的写入,但只有发出COMMIT的第一个事务才能 – 所有其他冲突的事务都必须ROLLBACK.但是这种编程模型虽然不浪费,但有些问题,因为事务可能会更新数据库的很大一部分,但最终会被拒绝COMMIT的能力.因此,代替“第一个提交者获胜”,大多数支持MVCC的DBMS系统使用相当传统的两阶段锁定来实现“第一个更新者获胜”.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
