您如何测试数据库中的竞争条件？

我尝试编写数据库代码以确保它不受争用条件的影响，以确保锁定了正确的行或表。但是我经常想知道：我的代码正确吗？是否可以强迫任何现有的竞赛条件表现出来？我想确保，如果它们确实发生在生产环境中，我的应用程序将做正确的事情。

我通常确切地知道哪个并发查询可能会导致问题，但是我不知道如何强制它们并发运行以查看是否发生了正确的行为（例如，我使用了正确的锁类型），正确的错误是抛出等

注意：我使用PostgreSQL和Perl，因此，如果不能一概而论，就应该重新标记它。

更新：如果解决方案是程序化的，我希望使用它。这样，我可以编写自动化测试以确保没有回归。

我一直在用T-SQL模块来做。

本质上，您需要做的就是从两个或多个连接中循环运行模块几分钟。通常，假设您有一个带有适当CPU的SQL Server盒，那么所有潜在问题都会在几分钟之内暴露出来。

我在这里和这里写了一些例子。

我通常使用RDBMS的命令行工具，只是启动了2个（或更多）CLI实例。然后，您可以一个接一个地重放您的应用程序层正在发送的SQL语句，作为竞赛（看起来像一个动作RPG）。您应该尝试/感觉一下正在使用的锁定系统，因为CLI会“挂起”一点，等待其他CLI释放锁定。

如果听起来像泥泞，请毫不犹豫地说;-)

竞争条件需要多个执行线程，因此要进行单元测试，您将需要能够启动一个或多个线程。在Oracle中，我将使用DBMS_Scheduler运行一个过程来模拟第二个用户。如果PostgreSQL / Perl可以以编程方式启动第二个进程，那么您应该能够执行以下操作：

过程1过程2

启动过程2。>>                            
延迟允许2个执行它的工作。 
。锁定行或更改数据。
。延迟允许1进行工作。
尝试锁定行或更改数据。。
检查以确保正确处理。。
结束 。
                                                结束

很高兴看到关于如何处理比赛条件的思考，更重要的是如何对它们进行单元测试。

只要锁定行，就不会出现竞争状况，因为通常情况是在没有锁定的情况下引起的。

但是，如果一个问题阻塞您的问题的时间过长，您可能会陷入僵局。

这很难测试，因为随着数据库的增长查询时间会改变。

可以很好地处理10万行测试数据的查询，排在图表的前10万行。

这种类型的问题可能很难预先发现，但是许多DB都有识别慢查询的某种方法。

通过定期使用该规则，您应该能够以充分的警告捕获所有陷入麻烦的查询。

如果您自己锁定，那就另当别论了，但是我无能为力。