当前位置：文江博客话题详情

连接池“泄漏”发展中。可能是由于 JUnit 测试设置所致？

发布于 2024-10-21 03:28:42 字数 328 浏览 1 评论 0原文

我正在尝试追踪开发中的数据库连接池“泄漏”，我想知道它是否是由于单元测试的设置方式造成的。有些东西正在从 Glassfish 池中获取数据库连接，但完成后没有关闭它们。最终池最大连接被用完，应用程序无法获取任何新的数据库连接。

我们的 JUnit 测试在 setUp() 方法中从池中获取连接，然后在 TeaDown() 方法中关闭该连接。我们能确定tearDown()方法总是会运行吗？如果发生未处理的异常，是否可以绕过tearDown()方法？

关于我们应该寻找什么还有其他想法吗？

我应该指出，我们使用 Jakarta Cactus 在 Glassfish 应用服务器上运行这些单元测试。

原文

分享到QQ

分享到微博

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

发布评论

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

宣告ˉ结束 2024-10-28 03:28:42

预防和报告数据库连接泄漏的一个建议：

首先找出每个连接的范围。

例如，对于许多 Web 应用程序来说，请求范围内需要连接。

定义了范围后，您需要做的就是在范围生命周期结束时以确定的方式关闭连接。

在 Web 应用程序中断言数据库连接始终关闭的一种方法是创建一个 servlet 过滤器，该过滤器将在请求传入时获取连接，并在发送响应时关闭连接。通过将连接放入 ThreadLocal 变量中，可以将连接从过滤器传递到其他对象。

范围的另一个示例是每个事务需要连接的情况。您可能需要使用执行周围方法模式来获取在范围开始之前连接并以确定的方式在结束时关闭它。

如果您实现这些想法中的任何一个，您甚至可以在关闭连接之前记录哪些连接未关闭，以帮助识别泄漏。

祝你好运，我希望这有帮助，否则请告诉我。

更新：

我刚刚通过向数据库连接池实现 apache DBCP 添加调试参数解决了遗留代码中的数据库连接泄漏。
即使您不想在生产中使用 DBCP，您仍然可以在测试中对其进行设置，以检测借用未关闭连接的确切行代码。

在我的环境中，我使用 Tomcat 和 JNDI 数据源配置，如下所示：

  <Resource auth="Container"
       name="jdbc/APP_NAME"
       username="user"
       password="password"
       url="jdbc:oracle:thin:@server.domain:1521:development"    
       type="javax.sql.DataSource"
       driverClassName="oracle.jdbc.driver.OracleDriver"

       maxIdle="10"
       maxWait="5000"
       maxActive="10"
       validationQuery="select 1 from dual"
       validationInterval="30000"
       testOnBorrow="true"
       testOnReturn="false"
       testWhileIdle="true"
       timeBetweenEvictionRunsMillis="5000"
       numTestsPerEvictionRun="3"
       minEvictableIdleTimeMillis="30000"


 <!-- These 3 settings saved me hours of headache -->

 logAbandoned="true" <!-- Will report the stacktrace of the faulty code --> 

 removeAbandoned="true" <!-- Will remedy the connection starvation while leaky code is not fixed-->

 removeAbandonedTimeout="60"<!-- Interval for fixing connection starvation while leaky code is not fixed-->

 />

请参阅：Apache DBCP 配置

One suggestion to prevent and report the database connection leaks:

First find out the scope of each connection.

Example, for many web applications a connection is needed in the scope of a request.

With the scopes defined all you need to do is to close the connection in a deterministic way by doing it at the end of the scope life cycle.

One way to of asserting that a database connection is always closed in a web application is to create a servlet filter that will get the connection when a request comes in and close the connection when the response is sent. The connection can be passed from the filter to other objects by putting it in a ThreadLocal variable.

Another example of scope is when a connection is needed per transaction. You may want to use the Execute Around Method pattern to get the connection before the scope begin and close it at the end in a deterministic way.

If you implement any of these ideas you may even log which connections were not closed before you close it to help identify the leak.

Good luck, I hope this helps, please let me know otherwise.

Update:

I just solved a database connection leak in legacy code by adding debugging parameters to the database connection pool implementation apache DBCP.
Even if you don't want to use DBCP in production you could still set it up in test just to detect the exact line code that borrowed the unclosed connection.

In my environment I used tomcat with the JNDI datasource config like so :

  <Resource auth="Container"
       name="jdbc/APP_NAME"
       username="user"
       password="password"
       url="jdbc:oracle:thin:@server.domain:1521:development"    
       type="javax.sql.DataSource"
       driverClassName="oracle.jdbc.driver.OracleDriver"

       maxIdle="10"
       maxWait="5000"
       maxActive="10"
       validationQuery="select 1 from dual"
       validationInterval="30000"
       testOnBorrow="true"
       testOnReturn="false"
       testWhileIdle="true"
       timeBetweenEvictionRunsMillis="5000"
       numTestsPerEvictionRun="3"
       minEvictableIdleTimeMillis="30000"


 <!-- These 3 settings saved me hours of headache -->

 logAbandoned="true" <!-- Will report the stacktrace of the faulty code --> 

 removeAbandoned="true" <!-- Will remedy the connection starvation while leaky code is not fixed-->

 removeAbandonedTimeout="60"<!-- Interval for fixing connection starvation while leaky code is not fixed-->

 />

See : Apache DBCP configuration

回复收藏 0 原文