C3p0 - MSSQL上的APPARENT DEADLOCK,但不是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请求
• 等一会儿 - > DEADLOCK
• 发送X请求
• 等一会儿 - > DEADLOCK

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

谢谢,阿德里安

(顺便说一句,BoneCP也没有任何问题.)

Answer 1

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

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

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

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

如果我没记错的话，这是通过添加WITH NOLOCK到 SELECT 语句来完成的（但我不完全确定）

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