DBCP 返回关闭的连接

发布于 2024-12-03 08:58:26 字数 864 浏览 5 评论 0原文

我们看到来自 org.apache.commons.dbcp.BasicDataSource 的数据库连接因套接字写入错误而终止的情况：

com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset by peer: socket write error

当然，所有后续写入连接的尝试都会失败：

com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.

将代码更新为捕获此类异常并在发生时请求新连接，但又失败了。我是否正确怀疑调用 DataSource#getConnection() 实际上并没有在每次调用时提供新连接？不就是重用已经关闭的现有连接吗？

如果我是正确的，丢弃旧连接并请求新连接的正确方法是什么？

编辑：这是我想知道的更简洁的版本：

Connection c1, c2;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c2 = DatabaseManager.getConnection();

“c1 == c2”是一个真实的陈述吗？或者已经分配了两个连接？如果是后者，像这样的代码是否代表“连接池泄漏”：

Connection c1;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c1 = DatabaseManager.getConnection();

原文

We are seeing situations where our database connection from org.apache.commons.dbcp.BasicDataSource is dying with socket write errors:

com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset by peer: socket write error

All subsequent attempts to write to the connection fail, of course:

com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.

After updating the code to catch such exceptions and request a new connection when it occurs, it failed again. Am I correct in suspecting that calling DataSource#getConnection() is not actually giving a new connection each time it is called? Isn't it just reusing the existing connection, which is closed?

If I am correct, what is the right way to throw away the old connection and request a new one?

EDIT: Here's a more succint version of what I'd like to know:

Connection c1, c2;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c2 = DatabaseManager.getConnection();

Is "c1 == c2" a true statement? Or have two connections been allocated? And if it's the latter, would code like this represent a "connection pool leak":

Connection c1;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c1 = DatabaseManager.getConnection();

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

乖乖 2024-12-10 08:58:26

数据库已关闭池连接。这可能意味着两件事：

连接池将连接保持打开状态的时间过长。
数据库在太短的时间后关闭连接。

理论上，增加/减少两侧的超时以使其对齐应该可以解决问题。

在 DBCP 上，最好的办法是在返回之前通过 testOnBorrow=true 和 validationQuery 设置（例如 SELECT 1）验证连接。您可以在 Tomcat JDBC 数据源文档< /a>.

根据您的更新更新：

这是我想知道的更简洁的版本：
连接 c1, c2;
c1 = DatabaseManager.getConnection();
// c1.close() 未调用
c2 = DatabaseManager.getConnection(); 
“c1 == c2”是一个正确的陈述吗？或者已经分配了两个连接？

这是两个不同的联系。仅当您调用 c1.close() 时，c2 才有可能返回相同的连接。

如果是后者，这样的代码是否代表“连接池泄漏”：
连接 c1;
c1 = DatabaseManager.getConnection();
// c1.close() 未调用
c1 = DatabaseManager.getConnection();

是的，它肯定会泄漏第一个连接，因为它从未返回到池中。您应该始终在 try-finally 块中关闭尽可能短范围内的所有数据库资源。然而，可以配置一个不错的连接池来获取废弃的连接，但这绝对不应该用作“解决方法”。

The pooled connection has been closed by the DB. That can mean 2 things:

The connection pool holds connections open for too long.
The DB closes connections after a too short time.

In theory, increasing/decreasing the timeout on either sides to align it should fix the problem.

On DBCP, your best bet is to validate connections before returning by a testOnBorrow=true and a validationQuery setting, e.g. SELECT 1. You can find configuration options in the Tomcat JDBC data sources documentation.

Update as per your update:

Here's a more succint version of what I'd like to know:
Connection c1, c2;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c2 = DatabaseManager.getConnection(); 
Is "c1 == c2" a true statement? Or have two connections been allocated?

It are two distinct connections. Only if you call c1.close() then there's a reasonable chance that c2 returns the same connection.

And if it's the latter, would code like this represent a "connection pool leak":
Connection c1;
c1 = DatabaseManager.getConnection();
// c1.close() not called
c1 = DatabaseManager.getConnection();

Yes, definitely it will leak the first connection as it's never been returned to the pool. You should always close all DB resources in the shortest possible scope in a try-finally block. A bit decent connection pool is however configureable to reap abandoned connections, but this should definitely not be used as "workaround".

回复收藏 0 原文