JSP数据库死锁DBComms.receive socket closed

问题描述：

页面报错显示如下：

com.microsoft.sqlserver.jdbc.SQLServerException: 使用 DBComms.receive 方法期间发生异常。操作:socket closed。上下文:(377250) [Thread[http-80-Processor144,5,main], IO:65c79, Dbc:null]。PktNum:0。TotalReceived:0。PktSize:4,096。
java.lang.NullPointerException

 

select语句有返回结果，update insert 和 delete 语句全是以上的错误提示。

 

     经过从网上的调查以及同学之间的分析，另外还请教了一位公司的技术指导，得出结论是数据库死锁的问题。

 

另外还有提示：

http://peter-kong.iteye.com/blog/44328中对这个问题是这样描述的：程序中的代码是非线程安全的, JDBC对象是不能被多个线程共用的. 产生这个异常的原因可能是一个线程中Connection正在关闭或Statement正在被重新执行的时候另一个线程正在使用.

 

      也就是说两个访问数据库的线程形成了死锁，造成所有数据库更新的语句全都无法运行。导致的直接结果就是，客户能够登录系统，客户在系统中能够进行所有的查看操作，给客户造成了错觉，认为系统正常。结果是客户所有做过的修改和保存操作都没有效果。需要一提的是，为了从客户体验的角度出发，很多系统中的错误提示都在系统后台提出了，前台都没有告诉过客户现在系统运行不正常。

 

解决办法：

     经过对数据库死锁资料的研究，我认为减少数据库死锁的发生概率没有特别直接的方法，只能是在项目测试阶段加强系统的负载测试，尽可能的将系统中所有数据库的操作放在事务去处理。（本系统中对数据库的操作五花八门，在连接池的基础上有批处理，有直连直接运行，还有存储过程，没有对此作出规范）     

     经过对数据库服务器的重启之后，以上的报错没有了，但是我们对于系统没有作出任何的改动，只能是静静等待下一次错误的发生了......

     （如果各位大牛遇见了以上的问题，并且有比较好的解决办法，拜托拜托给我一点儿提示啦，先谢过了）

 

后续（2009年7月15日16:40:09）：

 

     问题昨天晚上又出现了，重启了远端服务器的tomcat暂时解决了这一问题，但是，昨晚一直没有在自己的电脑上模拟出该问题。

     经过今天一天的处理，终于模拟出了这个错误，具体模拟步骤如下（以供参考）：

     将数据库操作范围最大的一个类中的方法，0.1秒的频率运行1000遍（多台机器同时访问），最终爆出了文章开头列出的错误。

 

     目前解决方法，将该类的所有数据库语句尽可能的精简，然后放在事务中运行。这样就算再出现死锁，事务也会回滚，并且能够自动牺牲某个进程来延续服务器的正常运行。精简SQL语句之前，将原来复杂的SQL语句放在事务中运行也会出现死锁，但是都能够自动处理掉，不会像原来一样影响到服务器的正常运行（具体症状见文章开头）。