我们在Tomcat 6中运行的Java Web应用程序遇到问题，该应用程序使用JDBC连接到SQL Server数据库。
在几次请求之后，应用程序服务器就死了，在日志文件中我们发现了与数据库连接失败有关的异常。
我们现在没有使用任何连接池，我们使用标准的JDBC / ODBC / ADO驱动程序桥连接到SQL Server。
我们是否应考虑使用连接池来消除问题？
另外，我们应该将驱动程序更改为jTDS吗？
答案 0 :(得分：1)
我肯定会试试jTDS。我过去使用它与Tomcat 5.5没有任何问题。这似乎是一个相对快速，影响较小的变化，可以作为调试步骤。我想你会发现它更快更稳定。它还具有开源的优势。
从长远来看，我认为出于性能原因，您需要研究连接池。当你这样做时，我建议你看看c3p0。我认为它比Tomcat的内置池选项更灵活，我通常更喜欢“out of container”解决方案，以便在将来切换容器时不那么痛苦。
答案 1 :(得分：1)
真的很难说，因为你提供的关于实际失败的信息很少：
经过几次请求后，申请 服务器死了，在日志文件中 我们找到与数据库相关的例外 连接失败。
你能告诉我们：
我编写了很多与数据库相关的java代码（几乎所有代码都与数据库相关），并使用了MS驱动程序，jdt驱动程序和jnetDirect中的代码。
我确定您是否向我们提供了更多可以帮助您的详细信息。
答案 2 :(得分：1)
如果您没有关闭JDBC连接，这是正确的行为。
当您使用完每个JDBC资源以及使用它获得的其他JDBC资源时，您必须调用每个JDBC资源的close（）方法。
适用于Connection，Statement / PreparedStatement / CallableStatement，ResultSet等
如果你没有这样做，那么对于初学者来说，你正在囤积SQL服务器上可能非常庞大且可能非常有限的资源。
最终，不会授予连接，执行查询并返回结果将失败或挂起。
如果未在每次事务结束时提交（）或rollback（），如果尚未将autoCommit属性设置为true，也可能会注意到INSERT / UPDATE / DELETE语句挂起。
我所看到的是，如果将上述严格应用于JDBC客户端代码，那么JDBC和SQL服务器将非常顺利地运行。如果你写垃圾，那么一切都会像垃圾一样。
许多人编写JDBC调用，希望通过调用close（）来释放每个东西，因为这很无聊，应用程序和服务器在离开时不会立即失败。
确实如此，但那些程序员已经编写了他们的程序，用他们的服务器播放“99瓶啤酒”。
资源将耗尽，请求将导致以下一种或多种情况发生：连接请求立即失败，SQL语句立即失败或永久挂起或直到一些神圣的冗长事务超时计时器到期等等。
因此，解决这些类型的SQL问题的最快方法不是责怪SQL服务器，应用程序服务器，Web容器，JDBC驱动程序，或者Java垃圾收集器中嵌入的人工智能缺乏令人失望。
解决这些问题的最快方法是拍摄在您的应用程序中编写JDBC调用的人，他们使用Nerf dart与您的SQL服务器通信。当他说，“你为......做了什么？”只需指出这篇文章并告诉他阅读它。 （记住不要为了眼睛，手中的东西，可能危险/脆弱的东西等而射击。）
至于连接池解决你的问题......没有。对不起，连接池只需加快通话速度，即可为应用程序提供预先分配的，可能是回收的连接。
牙仙在你的枕头下放钱，复活节兔子放鸡蛋和放心在你的灌木丛下的糖果，圣诞老人把礼物放在你的树下。但是，抱歉打破你的幻想 - SQL服务器和JDBC驱动程序不会关闭所有内容，因为你“忘记”关闭你自己分配的所有内容。