jboss / wildfly中的缓存连接管理器 [英] Cached connection manager in jboss/wildfly
问题描述
我已经为JBoss AS 7.4定义了一个数据源，包括最小/最大池大小，跟踪空闲连接等。
I have defined a datasource for JBoss AS 7.4, with min/max pool sizes, tracing of idle connections etc.
我对数据源<$ c感到困惑$ c> use-ccm property。
I am confused about the datasource use-ccm property.
- 它做什么用？
- 为什么要使用它？
我认为数据源本身可以管理连接池。
I thought the datasource itself manages the connection pool.
推荐答案
它做什么用？
它只是一个有用的调试工具，可以通过检查其日志记录来检测手动管理事务（BMT）中的连接泄漏。在调试模式下打开时，它将记录应用程序代码获取和释放的所有连接以及查询。这可用于跟踪应用程序代码中的连接泄漏。
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.
JBoss AS 5管理指南比 JBoss AS 7管理指南及更新版本。它甚至没有出现在WildFly文档中。以下摘录来自JBoss AS 5指南：
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。缓存连接管理器
缓存连接管理器用于调试数据源连接并支持事务中数据源连接的延迟登记，跟踪它们是否正确使用和释放通过申请。以一些开销为代价，它可以提供对使用情况的跟踪，并确保来自数据源的连接不会被应用程序泄露。虽然这似乎是一个优点，但在某些情况下它被认为是一种反模式，所以要避免。
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.
[...]
在默认，标准和所有配置中， CachedConnectionManager 被配置为在调试模式下位于servlet容器中。它也在生产配置中配置，但关闭了调试模式。如果您不使用BMT，和/或您没有前面描述的反模式，最好删除 CachedConnectionManager 。
In the default, standard and all configurations, the CachedConnectionManager is 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 the CachedConnectionManager.
为什么要使用它？
只有在不使用容器管理事务（CMT）但是手动管理事务时才在调试模式下打开它（BMT）和您遇到了无法确定的连接泄漏问题。一旦根据CCM的日志记录找到并修复了应用程序代码，最好将其关闭以保存性能。
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.
如果你正在使用CMT，即你无处可去在您的应用程序中手动处理连接和/或 UserTransaction 实例，但只是让EJB + JTA付出艰苦的努力，保持关闭。
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.
我认为数据源本身管理连接池。
它只在服务器和数据库之间进行。它不会在服务器和应用程序代码之间执行此操作。使用CMT时，会自动完成。使用BMT时，应用程序代码开发人员负责。在这种情况下遇到连接泄漏时，可以使用CCM来确定它。
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.
参见 Mastertheboss.com - 如何使用JBoss和WildFly跟踪JDBC语句。
这篇关于jboss / wildfly中的缓存连接管理器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
