【数据库CS751：事务处理Transaction Processing，如何为远程并发访问的系统安全地执行组合更新】——并发性、锁与隔离

目录

一、前言

二、并发性

1.数据库使用的典型架构

2.并发性

<1>不相交数据事务：

<2>Disjoint-access parallelism (DAP) 不相交数据库并行：

如何分辨数据的不相交性？

3.并发性的解决：

---

一、前言

我们来详细说一说并发性、锁与隔离的概念和应用。

二、并发性

1.数据库使用的典型架构

2.并发性

上一节我们已经说过了并发性的概念，同时也说了并发性的其中一个解决方案，我们来回顾一下：

不同的客户端可能会干扰，系统需要一直检查所有的可用航班，并告知用户，如何能做到避免订单的提交干扰？

可能的解决方案：每次只执行一个用户订单。这个叫做DB-wide Mutual exclusion，数据库范围的互斥。那么在这种方案下，我们就需要确定什么时候一个事务结束，什么时候一个事务开始，那么就要进行事务划分。但是存在可伸缩性限制:DB-wide互斥对系统的吞吐量有严格的限制。

这种DB-wide方式是非常耗时的，同时处理速度非常的慢，并且不一定适用于所有的数据：

<1>不相交数据事务：

冲突对象:一个集合中的多个事务访问的数据对象。

1.如果一组事务没有冲突对象，那么它就是数据不相交的。

现实中，如果并发事务访问一个巨大数据库中的随机数据，那么我们认为这是一个不相交数据事务。

2.此外，如果交易涉及不相关的事项，那么大概率这也是一个不相交事务。

<2>Disjoint-access parallelism (DAP) 不相交数据库并行：

原理:数据不相交的事务不干涉

因此事务的处理不应该延后，因为完全具备并行的特质。

但是DB-wide Mutual exclusion需要逐个执行，并对其他事务进行延后阻碍。

所以此时，DB-wide Mutual exclusion就不适合处理这类事务。

如何分辨数据的不相交性？

隐式事务处理：除了事务划分之外，脚本不能提供更多的锁定命令

结果:脚本不需要关心是否应用了db范围的互斥锁

连续变量反馈：

事务脚本在单个操作之后从DB获得反馈(甚至比Online TP所需的时间范围更小)

3.并发性的解决：

第一个解决方案:简单调度程序

简单调度程序对每个数据对象使用互斥锁，也就是每个对象使用一个排他锁。

在事务结束时释放一个事务持有的所有锁。

如果事务在一个循环中等待对方释放锁:死锁，中止循环中的一个事务。

严格两相锁：R2PL

事务在其生命周期(第一阶段)获得锁。

在事务结束时释放所有锁

严格两相锁不需要显式的锁命令(只有提交):对于编写事务的程序员来说，没有中断抽象。

R2PL避免了发生错误时的级联中止。