我遇到了一个偶尔会死锁的 Web 应用程序的问题

涉及3个查询。2 正在尝试更新表

一个正试图插入到表中

死锁图显示了页面锁和交换事件的一种循环排列，并且 2 个更新查询具有相同的服务器进程 ID。

如果有人对我应该如何解决这个问题有任何想法，将不胜感激。

如果有人需要，我可以发布死锁图。

谢谢卡尔 R

我用户 sun jdk 1.5 ThreadPoolExecutor(24, 24,60,TimeUnit.SECONDS, new LinkedBlockingQueue())。soemtime 我使用 jdb 工具查找线程池中所有线程的状态是“在监视器中等待”，代码是：

“同步（key.intern（））”有问题吗？

我使用 jdb 工具得到以下信息，24 个线程的状态是“在监视器中等待”，这意味着 24 个线程在“key.intern()”处死锁。

(java.lang.Thread)0x28 pool-3-thread-2 在监视器中等待

(java.lang.Thread)0x27 pool-3-thread-3 在监视器中等待

(java.lang.Thread)0x1b pool-3-thread-4 在监视器中等待

(java.lang.Thread)0x1a pool-3-thread-5 在监视器中等待

(java.lang.Thread)0x19 pool-3-thread-6 在监视器中等待

(java.lang.Thread)0x18 pool-3-thread-7 在监视器中等待

(java.lang.Thread)0x17 pool-3-thread-8 在监视器中等待...

所以结果是：在多线程环境下，Sting intern() 方法可能会死锁，好吗？

我正在尝试跟踪我们的 SQL 2005 数据库（64 位）中发生的死锁。我们目前没有启用快照隔离。

我打开了 tf-1204 并收到了下面的输出。

从这个输出中，我能够确定节点 1 是一个存储过程，它选择数据并且只修改 #temp 表中的值。

节点 2 是另一个存储过程，它对单行数据执行基于简单主键的更新。

我无法确定的是这里争用的实际资源。10:72057594060734464 和 10:72057594038910976 的 Keys 允许我确定数据库，但是无法使用 object_name 解析这些对象 ID。事实上，它们应该是 int 值，所以我不确定这些大数字是从哪里来的。

在研究这个问题时，我也能够从对象 ID 的活动监视器中获得类似的值。

如何解析这些对象标识符？

这是死锁 tf-1204 输出：

我是线程新手，需要帮助。我有一个数据输入应用程序需要花费大量时间来插入新记录（即 50-75 秒）。所以我的解决方案是通过 ThreadPool 发送一个插入语句，并允许用户在插入运行时开始输入记录的数据，该插入返回一个新的记录 ID。我的问题是用户可以在从该插入返回新 ID 之前点击保存。

我尝试放入一个布尔变量，当可以安全保存时，该变量通过来自该线程的事件设置为 true。然后我输入

我认为这是个坏主意。如果我在胎面返回之前运行保存方法，它就会卡住。

所以我的问题是：

1. 有没有更好的方法来做到这一点？
2. 我在这里做错了什么？

谢谢你的帮助。
道格

编辑以获取更多信息：

它正在插入一个非常大（接近最大大小）的 FoxPro 数据库。该文件有大约 200 个字段和几乎一样多的索引。
在你问之前，不，我不能像以前那样改变它的结构，而且有大量的遗留代码在攻击它。第一个问题是，为了获得一个新 ID，我必须首先在表中找到 max(id)，然后对其进行递增和校验。这大约需要 45 秒。然后第一个插入很简单，插入新的 id 和一个 enterdate 字段。该表不是/不能放入 DBC 中，因此排除了自动生成的 id 等。

@joshua.ewer
你的过程是正确的，我认为短期内我只会禁用保存按钮，但我会研究你将其传递到队列中的想法。您是否有任何我应该看一看的 MSMQ 参考资料？

以下代码会导致在 .NET 上使用 C# 导致死锁吗？

我有一个包含 4 个 MDB 的应用程序，每个 MDB 通过 JMS 从 MQ 接收 SOAP 消息。收到消息后，我们将 XML 处理为对象模型并进行相应的处理，这始终涉及通过 Hibernate 将消息加载或保存到 Oracle 数据库。

此外，我们有一个石英进程，每分钟触发一次，可能会触发也可能不会触发这些动作，这些动作也可以使用 Hibernate 读取或写入数据库。

当系统处于高负载下时，即处理大量 1k + 并可能执行由我们的石英进程触发的一些数据库读/写，我们不断看到在我们的日志中抛出以下异常。

==================================================== ============================= 在 com.integrasp.iatrade.logic.MessageContextRouting.lookup(MessageContextRouting.java:150) 在 com .integrasp.iatrade.logic.RequestResponseManager.findRequestDestination(Reque stResponseManager.java:153) 在 com.integrasp.iatrade.logic.RequestResponseManager.findRequestDestination(请求 stResponseManager.java:174) 在 com.integrasp.iatrade.logic.IOLogic.processResponse (IOLogic.java:411)< br /> 在 com.integrasp.iatrade.logic.FxOrderQuoteManager.requestQuote(FxOrderQuoteManage r.java:119) 在 com.integrasp.iatrade.logic.FxOrderQuoteManager.processRequest(FxOrderQuoteMana ger.java:682) ) 在 com.integrasp.iatrade.eo.SubmitOrderRequest.process(SubmitOrderRequest.java:60) 在 com.integrasp.iatrade.ejb.BusinessLogicRegister.perform(BusinessLogicRegister.j ava:85) 在 com.integrasp.iatrade.ejb.mdb.OrderSubmissionBean.onMessage(OrderSubmissionBean .java:147) 在 com.ibm.ejs。 jms.listener.MDBWrapper$PriviledgedOnMessage.run(MDBWrapper.java:30 2) 在 com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63) 在 com.ibm.ejs.jms.listener.MDBWrapper .callOnMessage(MDBWrapper.java:271) 在 com.ibm.ejs.jms.listener.MDBWrapper.onMessage(MDBWrapper.java:240) 在 com.ibm.mq.jms.MQSession.run(MQSession.java:1593) 在com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:970) 在 com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSessio n.java:891) 在 com.ibm.ejs.jms.listener .ServerSession.onMessage(ServerSession.java:656) 在 com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:623) 在 sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) 在 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:43) 在 java.lang.reflect.Method.invoke(Method.java:615) 在com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatch er.java:37) 在 com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:96) 在 com.ibm.ejs.container.MDBWrapper .onMessage(MDBWrapper.java:132) 在 com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:481) 在 com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473 ) 引起：java.lang.reflect.Method.invoke( Method.java:615) 在 org.hibernate。transaction.WebSphereExtendedJTATransactionLookup$TransactionMana gerAdapter$TransactionAdapter.registerSynchronization(WebSphereExtendedJTATransa ctionLookup.java:225) ... 30 更多原因：com.ibm.websphere.jtaextensions.NotSupportedException at com.ibm.ws.jtaextensions.ExtendedJTATransactionImpl.registerSynchronizationCall backForCurrentTran(ExtendedJTATransactionI .java:247)

... 34 更多

任何机构都可以帮助阐明 com.ibm.websphere.jtaextensions.NotSupportedException 的含义。IBM 文档说

“如果尝试在环境中注册 SynchronizationCallback 或在此功能不可用时，事务管理器会抛出异常。”

对我来说，这听起来像是容器拒绝休眠调用以启动事务。如果有人对容器为什么会抛出消息有任何想法，请告诉我。

提前致谢

卡尔

这可能是非常基本的，所以请耐心等待（另一方面，可能有一个很好的闪亮的干货答案！）。

我目前正在诊断一个死锁问题，实际上我可以看到我的一个会话被另一个会话阻止了。（死锁的另一端是 Java 线程以相反的顺序相互等待。）在 Management Studio 的进程资源管理器中显示进程的详细信息为我提供了阻塞会话的 SQL，但阻塞会话的 SQL仅显示作为“ EXEC sp_unprepare 807”。

现在我明白这与准备好的陈述有关，所以我本身并不为此感到不安。但是，我想知道实际的 SQL 是什么，这样我就知道在代码库中的何处投下怀疑的眼光。那么在这一点上，将其与该线程执行的实际 SQL 相关联的最佳方法是什么？是否有一个系统表，我可以在其中查找准备好的语句到他们的 SQL 的映射？可能是一个存储会话的最后n 个SQL 语句的表，该会话有望保持prepare调用？是否可以在数据库驱动程序连接上设置一个标志，以完全禁用此会话的准备好的语句？

我也欢迎解决这个问题的替代方法，如果它们是更好的方法（基本上我高度怀疑有一些 Java 代码在修改表后无法提交，我想知道 SQL 来提供帮助我找出它在哪里）。

以下 C# 类用于多线程环境。我删除了很多实际代码。几乎同时调用 MethodA 和 MethodB 时会出现问题。IsDepleted 属性中的锁顺序并不能解决问题。从 IsDepleted 属性中删除 lock(WaitingQueue) 可以解决死锁，但是当另一个线程在 WaitingQueue.Count == 0 和 Processing.Count == 0 语句之间从 WaitingQueue 添加/删除项目时，此解决方案会导致问题。

我正在帮助解决使用 SQL Server 2005 的 .NET 应用程序中的一些死锁问题。我有来自下面跟踪的 XML 数据。

PK_Exp_Experience_PriorFirm真正让我困惑的是当事务隔离级别被读取提交时RangeX-X 锁定。

我读过的所有内容都表明您使用事务隔离级别“可序列化”只会获得一个键范围锁。到目前为止，我在我们的应用程序中找不到将隔离级别设置为读取提交以外的任何位置，并且下面的 XML 也表明我们正在使用读取提交。

但是，如果我们使用已提交读，我不明白跟踪如何显示存在键范围锁。有没有人知道如何发生这种情况？

我经常收到此错误，但在生产环境中的应用程序中的 2 页上并不一致。我只有以下错误的一些屏幕截图。

事务（进程 ID XX）在锁上死锁 | 与另一个进程通信缓冲区资源，并已被选为死锁牺牲品。重新运行事务。

解决此错误的方法应该是什么。数据库服务器是 SQL Server 2005。