在数据库管理系统(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 手册中找到关于这点的更多详细描述。