multithreading - oracle行争用在高吞吐量JMS应用程序中导致死锁错误

Question

摘要:

我想知道对于具有批量消息试图更新同一行并获得oracle死锁错误的高吞吐量应用程序的最佳实践是什么。我知道您无法避免这些错误，但是如何从这些错误中优雅地恢复，而不会被此类反复发生的死锁错误所困扰。

详细信息:

我们正在构建一个高吞吐量的JMS消息传递应用程序。生产环境将是两个weblogic 11g节点(每个节点运行6个MDB监听器实例)。当我们收到约1000条消息都试图更新oracle数据库中的同一行时，我们遇到了Oracle死锁错误(ORA-00060)。在标准的Java线程API中，跨节点的Java同步是不可能的(除非没有其他解决方案，我们不想使用任何第三方解决方案，例如terracotta等)。

我们希望Oracle的“选择更新等待n秒”语句将有所帮助，因为这实际上会使竞争线程(对于同一行)在第一个线程(首先获得该行锁定)之前等待几秒钟。 。

“SELECT FOR UPDATE WAIT n”的第一个问题是不允许使用毫秒作为等待时间。这开始对我们的应用程序的吞吐量产生负面影响，因为放置1秒的WAIT(最短等待时间)会导致消息延迟。

其次，我们摆弄了weblogic队列重新传送延迟参数(在本例中为30秒)。每当线程由于死锁错误而反弹时，它将等待30秒钟，然后重新尝试。

根据我们的经验1000条竞争性消息，在很多情况下，由于死锁不断地反复发生，需要花费很多时间来处理它们。

我知道，在当前架构下，无论(如果有1000条竞争消息)，我们都应该遇到死锁错误，但是应用程序应具有足够的弹性，以在重试循环消息后从这些错误中恢复过来。

知道我们在这里缺少什么吗？有人曾经处理过类似的问题吗？

我正在寻找一些设计想法，这些想法可以使该工作有弹性地工作，以使其从这种死锁情况中恢复过来，并最终在合理的时间内处理所有消息，而无需使用太多额外的硬件。

计算详细信息:
这1000条消息将分别创建4个不同位置类型的4个对象，每个对象都具有与之关联的数量。这些数量将必须合并到这4个不同的插槽中(取决于仓位类型)。当每个单独的线程正在更新这四个单独的插槽时，就会发生死锁。在应用到数据库行之前，我们已经按照特定的顺序对这些单独的更新进行了排序，以避免任何可能的争用条件。

Answer 1

死锁意味着每个线程都试图在单个事务中更新多行，并且这些更新是在线程之间以不同的顺序进行的。因此，最简单的可能答案是修改代码，以便以某种定义的顺序(即，按主键的顺序)应用同一事务中的消息。这样可以确保您永远不会出现死锁，尽管在一个线程等待另一个线程提交其事务时，您仍然会获得阻塞锁。

但是，退后一步，当您无法预测更新的顺序时，您似乎不太希望真正有很多线程更新表中的同一行。极有可能导致大量更新丢失以及某些相当不可预测的行为。确切地说，您的应用程序在执行什么操作会使这种事情变得明智？您是否正在执行类似将行插入到明细表中之后更新汇总表的操作(即，除了记录有关特定 View 的信息外，还更新帖子所包含的 View 数的计数)？如果是这样，那么这些操作真的需要同步吗？还是可以通过汇总过去N秒内的 View 来定期更新另一个线程中的 View 计数？