从这里：

PooledConnectionFactory和CachingConnectionFactory之间的差异是实现上的差异。以下是它们之间不同的一些特征：

• 尽管PooledConnectionFactory和CachingConnectionFactory都声明它们各自缓冲连接，会话和生产者，但PooledConnectionFactory实际上并不创建多个生产者的缓存。当请求一个生产者时，它仅使用单例模式来分发单个缓存的生产者。而CachingConnectionFactory实际上创建了一个包含多个生产者的缓存，并在请求一个生产者时从该缓存中分发了一个生产者。

• PooledConnectionFactory建立在Apache Commons Pool项目的顶部，用于池化JMS会话。这允许对池进行一些其他控制，因为Commons Pool中的某些功能没有被PooledConnectionFactory使用。这些附加功能包括增大池的大小而不是阻塞池，在池用尽时引发异常等。您可以利用以下功能来利用这些功能：使用自己的自定义设置创建自己的Commons Pool GenericObjectPool，然后通过将其传递给PooledConnectionFactory setPoolFactory方法。有关其他信息，请参见以下内容：http : //commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

• CachingConnectionFactory也可以缓存使用者。使用此功能时只需要注意，这样您就可以根据博客文章中提到的规则来缓存使用者。

• 但最重要的是，CachingConnectionFactory将与任何符合JMS的MOM一起使用。 它只需要一个JMS连接工厂。如果您使用多个MOM供应商，这在企业组织中非常常见（这主要是由于遗留项目和现有项目所致），则这一点很重要。重要的一点是，CachingConnectionFactory可以很好地与许多不同的MOM实现配合使用，而不仅仅是ActiveMQ。

从这里：

• 如果您已经将ActiveMQ群集在一起，并且使用了故障转移传输，则已经报告说CachingConnectionFactory不是正确的选择。

• 我遇到的问题是，如果一个盒子掉了，我们应该开始在另一个盒子上发送消息，但是它似乎仍在使用旧的连接（每次发送都超时）。如果我重新启动该程序，它将再次连接并且一切正常。来源： ActiveMQ和CachingConnectionFactory的自动重新连接问题

• 问题是与失败的ActiveMQ的缓存连接仍在使用中，这为用户造成了问题。 现在，此方案的选择是PooledConnectionFactory。

• 如果您今天使用的是ActiveMQ，并且有可能在将来切换到其他代理（JBoss MQ，WebSphere MQ），请不要使用PooledConnectionFactory，因为它会将您的代码紧密地耦合到ActiveMQ。