C3p0-MSSQL上的明显死锁，但不是PostgreSQL或MySQL

我们有这样的例外

com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@5b7a7896 -- APPARENT DEADLOCK!!! Complete Status: 
Managed Threads: 3
Active Threads: 3
Active Tasks: 
    com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StatementCloseTask@55bc5e2a (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
    com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StatementCloseTask@41ca435f (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2)
    com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StatementCloseTask@460d33b7 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0)
Pending Tasks: 

在MSSQL 2008 R2上对我们的应用程序进行负载测试时（jTDS或官方的MS JDBC无关紧要）。在对PostgreSQL或MySQL运行相同的测试时，我们从未遇到此异常

我们不只是想增加c3p0的辅助线程数量（这解决了问题，但需要多长时间？）。我们想知道问题是什么，因为它与其他DBMS一起工作

应用程序的行为类似于：

• 发送X个请求
• 等待一段时间->死锁
• 发送X个请求
• 等待一段时间->死锁

有人知道或者知道为什么我们在MSSQL中有这种行为吗

谢谢，阿德里安

---

（顺便说一句，BoneCP工作起来也没有任何问题。）

与PostgreSQL或InnoDB相比，SQL Server的锁定策略更具限制性

特别是，它将阻止从不同连接/事务（在默认安装中）更新的行（表？）上的选择

您应该确保在一个会话中没有选择从另一个会话更新的相同行

如果您不能更改代码的顺序，那么在SQL Server中使用“脏读”可能会得逞

如果我没记错的话，这是通过在SELECT语句中添加

WITH NOLOCK

来实现的（但我不能完全确定）

编辑

---

另一种可能性（如果您使用的是SQL Server 2005或更高版本）是使用新的“快照隔离”来避免阻塞选择。

SQL Server也有快照隔离。@MartinSmith:我知道。这就是为什么我说“默认安装”。但你有一个观点：切换到快照隔离也可以解决这个问题。你没有说“默认安装”。也许你是这么想的！这个实用程序是什么？为什么它报告“明显的死锁”而不是实际的死锁？SQL Server将检测实际的死锁。您可以跟踪死锁图，然后诊断死锁发生的原因。您好，Martin，SQL Server本身没有死锁。似乎只是c3p0（Java的连接池库）假设出现了死锁。阿德里安——你能澄清一下使用BoneCP是否避免了问题吗？@tgdavies是的，BoneCP避免了问题，但我不知道为什么，因为c3p0（很遗憾）是为我们设置的，我们没有深入挖掘其他池库。我认为BoneCP在技术上更先进，可能使用更好或更乐观的标准配置。