mysql - C3p0 - MSSQL 上的表观死锁，但不是 PostgreSQL 或 MySQL

Question

我们遇到这样的异常

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 也可以正常工作。)

Answer 1

与 PostgreSQL 或 InnoDB 相比，SQL Server 具有更加严格的锁定策略。

特别是它会阻止从不同的连接/事务(在默认安装中)更新的行(表？)上的 SELECT。

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

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

如果我没记错的话，这是通过在 SELECT 语句中添加 WITH NOLOCK 来实现的(但我不完全确定)

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