在数据库管理系统（DBMS）的领域中，术语“并发性”用于表示不止一个应用程序基本上（从用户的角度来看）同时访问同一数据的能力。因为 DBMS 的主要优点之一就是可以在多个用户和多个应用程序中共享数据，所以数据库系统应该提供一种管理并发访问数据的方法。DBMS 必须确保维护数据的一致状态和数据的完整性。

    取得该效果的一种方法就是实施只串行（serial-only）模式来处理数据库请求。即每个事务都要等待另一事务（具有更高的优先权或者比它早启动）完成其工作。然而，对于现在的在线系统和客户异常来说，这种处理方式所产生的性能水平简直令人无法接受。

    而另一种方法就是，DBMS 可以通过 锁的方式管理多个应用程序对数据的访问。锁是一种软件机制，用于在维护数据完整性和一致性的同时，允许尽可能大的吞吐量（通过最大限度地并发访问数据）。

    并发性控制的重要性

    如果没有控制并发性的有效方法，就可能损害数据的完整性和一致性。DBMS 必须保护数据库，防止发生下列状况：

    丢失更新—— 假设应用程序 A 和应用程序 B 同时读取数据库中的同一行，并且都为其中某一列计算新值。如果应用程序 A 先用其新值更新该行，随后应用程序 B 又更新同一行，那么第一次的更新（由应用程序 A 执行的）就会丢失。
不可重复读—— 某些应用程序进程可能要求完成以下事件序列：程序 A 从表中读取特定的一行，然后继续进行其他的 SQL 请求。稍后，程序 A 再次读取开始的那一行，并且必须在所有的列中找到与第一次读取相同的值。如果缺乏合适的并发性控制，另一应用程序就可能在这两次读取操作之间修改该行数据。
访问未提交的数据—— 应用程序 A 更新一行中的某些列的值，而在提交该修改之前，应用程序 B 读入该行的新（更新）值。如果应用程序 A 接着又“撤销”更新值（通过程序逻辑中的 SQL ROLLBACK 语句，或者因为发生错误由 DB2 UDB 自动进行回滚），那么，应用程序 B 对该行的处理就是基于未提交的（因而可能是不正确的）数据进行的。
在维护数据完整性的同时，提供多个应用程序同时访问数据的能力称作 并发性控制。

    锁

    锁是一种由 DB2 UDB 用于完成并发性控制的软件机制。锁实质上就是一个控制块，将 DB2 UDB 对象或资源与应用程序关联起来，并控制其他应用程序如何访问同一对象或资源。与 DB2 UDB 资源有关联的应用程序被称为“持有”或“拥有”该锁。

    通过使用锁，DB2 UDB（管理该数据库）可以防止发生上述几类问题。DB2 UDB 与另一 MVS 地址空间 IRLM 配合管理这些锁。IRLM 将跟踪这些锁及其所有者，以确定应用程序请求的 DB2 UDB 资源是否可用于该类工作。资源可以是 锁定的或 共享的，这取决于当前资源上的锁的“持有者”所进行的处理类型，以及请求应用程序所预期的处理类型。

    锁模式

    最常用的两种锁模式是 共享的和 排他的。共享锁与只读操作有关联，这意味着持有该锁的应用程序可以读取数据，而其他应用程序也可以读取该数据。排他锁与写操作有关联，这意味着持有该锁的应用程序有资格更新数据，但在锁所有者完成更新（将修改提交给数据库）并释放该锁之前，其他应用程序无法使用该数据。

    DB2 UDB 和 IRLM 使用其他类型和子类型的锁模式来实现锁定和并发性控制。您可以在 DB2 UDB Administration 手册中找到关于这点的更多详细描述。

    锁定粒度

    除了使用各种锁模式，DB2 UDB 还提供了不同的锁定级别，用以控制被锁定数据的范围。各种级别表示了 DB2 UDB 使用的锁定粒度，其范围可以从单个行到整个表空间。DB2 UDB 根据锁定粒度来使用不同的锁模式。

    具有多种锁定级别的理由十分简单。某些应用程序可能要求有权读取或更新大范围的数据，而其他应用程序则可能只要求访问窄得多的范围。如果只能使用一种锁定级别，则会降低整个系统性能。例如，一下子锁定太多数据会强制其他应用程序进行不必要的等待。否则，DB2 UDB 可能使用过多的系统资源，尝试服务对附加数据资源进行锁定的附加请求。能够实现多种级别的锁粒度可以极大地提高并发性水平。

    暂挂

    若一个应用程序进程请求一个锁，而该锁已被另一应用程序进程所拥有，且不能共享，此时，就称该进程为 暂挂的。请求应用程序会被挂起，即它将暂时停止运行。锁请求的优先次序如下：将新来的锁请求按照接收次序进行排队。已经持有锁的应用程序的请求以及进行锁提升的请求要比新应用程序的请求先得到服务。而在那些分组中，请求次序则为“先进先出（first in，first out，FIFO）”。

    超时

    当应用程序处于暂挂状态（见上面）超过了预设的一段时间间隔，那么就要终止该应用程序。该应用程序被称为已经超时。在终止该应用程序之前，会在 SQLCA 中收到一条合适的错误消息。SQLCA（SQL 通信域）是 SQL 应用程序预留的一块大小固定的存储区域，用于从 DB2 UDB 向程序传递条件代码和其他信息。

    某些操作，如 COMMIT 和 ROLLBACK，就不能超时。在下面的子标题 RESOURCE TIMEOUT 中，将对决定应用程序进程可以等待资源多长时间的预设时间间隔进行讨论。

    死锁

    当两个或更多应用程序每个都持有另一应用程序所需资源上的锁，没有这些资源，那些应用程序都无法继续完成其工作时，这时就会出现死锁的状况。

    以下是一个简单的死锁场景：

    应用程序 A 访问表 T，并请求页面 X 上的排他（非可共享的）锁。

    应用程序 B 访问表 T，并请求页面 Y 上的排他锁。

    然后，应用程序 A 请求页面 Y 上的锁，同时仍然持有页面 X 上的排他锁。应用程序 A 将被挂起，因为应用程序 B 具有页面 Y 上的排他锁。

    然后，应用程序 B 请求页面 X 上的锁，同时仍然持有页面 Y 上的排他锁。应用程序 B 将被挂起，因为应用程序 A 具有页面 X 上的排他锁。

    这是一种僵持情况。应用程序 A 和 B 都无法继续工作。
在一段预设的时间间隔之后（请参阅标题 DEADLOCK TIME 下面的讨论），DB2 UDB 将终止当前工作单元，因为某个应用程序陷入死锁状态（通常为所做工作最少的应用程序）。这将释放终止程序所持有的锁，并允许剩余的应用程序继续下去。 DB2 UDB 将向被终止的应用程序的 SQLCA 发送描述性的错误消息和信息。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。