从这里得知:
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 连接工厂。这在企业组织中非常常见(主要是由于遗留和现有项目)。重要的是,CachingConnectionFactory 与许多不同的 MOM 实现非常兼容,不仅限于 ActiveMQ。
来自这里:
如果您拥有集群化的ActiveMQ,并使用故障转移传输,据报道,CachingConnectionFactory不是正确的选择。
我遇到的问题是,如果一个盒子下线了,我们应该开始在另一个盒子上发送消息,但似乎仍在使用旧的连接(每个发送都超时)。 如果我重新启动程序,它将重新连接并且一切正常。来源:Autoreconnect problem with ActiveMQ and CachingConnectionFactory
问题在于缓存的连接仍在使用失败的ActiveMQ,这为用户创建了问题。 现在,这种情况的选择是PooledConnectionFactory。
如果您今天正在使用ActiveMQ,并且未来有可能切换到其他代理(JBoss MQ,WebSphere MQ),请勿使用PooledConnectionFactory,因为它会紧密地将您的代码与ActiveMQ耦合在一起。
但是Spring实现的缺点是它不支持XA事务。但是ActiveMQ实现支持它(XAPooledConnectionFactory)。所以,如果您正在使用其他资源和另一个JMS代理与JMS,并且想要进行事务处理,则使用ActiveMQ实现。当然,PooledConnectionFactory也适用于任何符合JMS标准的MOM。