事务环境中的数据库挑战:事务锁、两阶段提交与死锁
1. 引言
数据库的访问是在短期和长期事务的框架内进行的。每个事务由一系列对数据库的操作组成,执行事务的时间和操作数量几乎没有预先设定的限制。
当客户端应用程序发送登录请求时,会话开始。数据库的操作是在事务隐含的操作以及构成这些操作的原子单元的视角下完成的。数据库的一致性要求要么所有原子单元都被执行,要么都不执行。事务的结束通过请求提交或中止来表示。
与数据库信息元素(IE)相关的锁的使用遵循一组简单的规则。读锁防止读写冲突,写锁防止写写冲突。持有读锁或写锁的事务能保证该信息元素不会被其他事务修改;持有写锁的事务还能保证在可能导致并发冲突的事件序列中,该信息元素不会被其他事务读取。
当登录数据库时,数据库管理系统(DBMS)通常会开启一个会话,并通过创建数据库的私有副本来启动事务。虽然实际上没有复制数据,但这个副本会向用户(人、终端或程序)呈现所有被授权访问的信息元素(就像事务开始时它们的存在状态)。
在执行期间,访问和计算在事务的生命周期内有效。执行结束后,可见的更改仅为应用程序在事务执行期间所做的更新、添加或删除操作。从基本意义上讲,读写事务允许在本地副本的上下文中检查和修改数据库,直到相关操作以提交、中止或注销结束。
提交操作会通知DBMS通过合并事务期间所做的所有更改来更新数据库。如果更改成功合并且事务提交完成,DBMS会向会话呈现更新后的数据库副本。中止事务会丢弃由于该事务可能对数据库所做的任何更改而产生的可能已更新的副本。注销消息会中止事务并结束会话,而不更新数据库。在新事务开始时,会使用包含在中止事务进行期间其他提交会话所做的所有更改的全新数据库副本。 </
超级会员免费看
订阅专栏 解锁全文

被折叠的 条评论
为什么被折叠?



