带有 DB2 表锁定的事务性 Web 应用程序

Question

我们有一个 Java Web 应用程序，在安装时选择一个 DBMS 来存储应用程序的数据。我们有大约 8 种选择，其中 MS SQL Server、Oracle、MySQL 和 PostgreSQL 是我们客户最喜欢的。我们显然使用 JDBC 与这些数据库交互。大多数数据库调用只是事务中的 SQL，偶尔我们会使用数据库序列，或者如果序列在所选数据库中不可用，则使用存储过程。使用的 SQL 非常基本，无需修改或特定于数据库的语法即可在所有支持的数据库上运行。

DB2 是一个安装选项，但我们似乎在表锁定和暂停事务方面存在问题，尤其是对于同时从同一个表读取或写入的并发用户。也许我应该将这些锁称为死锁，因为它们会停止使用同一张表的所有事务。默认情况下，我们使用 READ_COMMITTED 的事务隔离级别来强制执行事务完整性。将其更改为 READ_UNCOMMITTED 可以摆脱锁定，但这显然不是运行事务的好方法。

我们现有的所有代码都可以与 MySQL、PostgreSQL 和 Oracle 一起“正常工作”。 在 SQL Server 中，我们在数据库上启用了 SNAPSHOT ISOLATION，并且在数据库级别没有任何问题死锁。

我们目前正在 DB2 9.1 上进行测试，并且正在发生这些死锁。 已使用默认选项安装 DBMS。

我对 DB2 的经验很少，不知道有什么办法可以解决这些锁定问题，或者 DB2 是否就是这样工作的。

有什么简单的方法可以使这项工作无需同步代码，从而不会同时访问数据库表。我也不想修改 SQL 以包含 DB2 特定的锁定语法。我不排除我们的代码存在问题，但在其他 DBMS 上似乎一切正常。

有什么想法或建议吗？

Answer 1

DB2 锁定机制的工作方式与您提到的其他数据库略有不同，这经常暴露出一些惰性编程实践——我的意思是没有冒犯，这只是生活中的事实。顺便说一句，你看到的不是死锁——这些是锁等待。

在 DB2 中，锁定问题最常见的解决方法是减少事务的大小（更频繁地提交，在每个事务中处理更少的行）和适当的索引。

从 DB2 9.7 开始，您可以选择启用 "currently committed" semantics，这使得 DB2 的行为更像其他数据库，因为查询不会等待更新行上的锁被释放，而是访问先前提交的版本那些行。但是，这种方法有其自身的负面影响。