jboss/wildfly 中的缓存连接管理器 [英] Cached connection manager in jboss/wildfly
问题描述
我为 JBoss AS 7.4 定义了一个数据源，包括最小/最大池大小、空闲连接跟踪等.
我对数据源 use-ccm 属性感到困惑.
- 它有什么作用?
- 为什么要使用它?
我认为数据源本身管理连接池.
它有什么作用?
它只是一个有用的调试工具，可通过检查其日志记录来检测手动管理事务 (BMT) 中的连接泄漏.在调试模式下打开时，它将记录应用程序代码获取和释放的所有连接以及查询.这可用于跟踪应用程序代码中的连接泄漏.
JBoss AS 5 管理指南比JBoss AS 7 管理指南 及更新版本.WildFly 文档中甚至没有它.以下摘录来自 JBoss AS 5 指南:
<块引用>3.1.缓存连接管理器
缓存连接管理器用于调试数据源连接并支持事务中数据源连接的延迟登记，跟踪它们是否被应用程序正确使用和释放.以一些开销为代价，它可以提供使用跟踪，并确保来自数据源的连接不会被您的应用程序泄漏.尽管这看起来是一个优势，但在某些情况下它被认为是一种反模式，因此应该避免.
[...]
在默认、标准和所有配置中，CachedConnectionManager 被配置为在调试模式下位于 servlet 容器中.它也在生产配置中配置，但调试模式关闭.如果您不使用 BMT，和/或您没有前面描述的反模式，最好删除 CachedConnectionManager.
<块引用>
为什么要使用它?
仅当您不使用容器管理事务 (CMT) 而是手动管理事务 (BMT) 时才在调试模式下打开它并且您遇到连接泄漏问题，而您无法不要确定.一旦根据 CCM 的日志发现并在应用程序代码中修复，最好将其关闭以节省性能.
如果您使用 CMT，即您无需在应用程序中手动处理 Connection 和/或 UserTransaction 实例，而只是让 EJB+JTA 完成它们的努力工作，不要着急.
<块引用>
我认为数据源本身管理连接池.
它仅在服务器和数据库之间执行此操作.它不会在服务器和应用程序代码之间这样做.使用 CMT 时，这一切都会自动发生.使用 BMT 时，应用程序代码开发人员对此负责.在这种情况下遇到连接泄漏时，可以使用 CCM 来确定它.
另见 Mastertheboss.com - 如何使用 JBoss 和 WildFly 跟踪 JDBC 语句.
I have defined a datasource for JBoss AS 7.4, with min/max pool sizes, tracing of idle connections etc.
I am confused about the datasource use-ccm property.
- What does it do?
- Why use it?
I thought the datasource itself manages the connection pool.
What does it do?
It's just a useful debugging tool to detect connection leaks in manually managed transactions (BMT) by inspecting its logging. When turned on in debug mode, it will log all connections acquired and released by application code, along with the queries. This can be used to trackback connection leaks in application code.
The JBoss AS 5 Administration Guide does a better job in explaining this than the JBoss AS 7 Administration Guide and newer. It's even absent in WildFly documentation. Below extract is from the JBoss AS 5 guide:
3.1. Cached Connection Manager
The Cached Connection Manager is used for debugging data source connections and supporting lazy enlistment of a data source connection in a transaction, tracking whether they are used and released properly by the application. At the cost of some overhead, it can provide tracing of the usage, and make sure that connections from a data source are not leaked by your application. Although that seems like an advantage, in some instances it's considered an anti-pattern and so to be avoided.
[...]
In the default, standard and all configurations, the
CachedConnectionManageris configured to be in the servlet container in debug mode. It's also configured in the production configuration but with debug mode off. If you do not use BMT, and/or you do not have the anti-pattern, described earlier, it's best to remove theCachedConnectionManager.
Why use it?
Only turn it on in debug mode when you aren't using container managed transactions (CMT), but are manually managing transactions (BMT) and you're having a connection leak problem which you couldn't nail down. Once found based on CCM's logging and fixed in application code, it is best to turn it back off to save performance.
If you're using CMT, i.e. you are nowhere in your application manually dealing with Connection and/or UserTransaction instances, but just letting EJB+JTA do their hard work, just keep it off.
I thought the datasource itself manages the connection pool.
It does that only between the server and the database. It does not do that between the server and the application code. When using CMT, this happens all automatically. When using BMT, the application code developer is responsible for that. When a connection leak is encountered in such case, CCM could be used to nail it down.
See also Mastertheboss.com - How to trace JDBC statements with JBoss and WildFly.
这篇关于jboss/wildfly 中的缓存连接管理器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
