PooledConnectionFactory或CachingConnectionFactory在MQ中那个更好

PooledConnectionFactory和CachingConnectionFactory之间的区别是不同的实现.以下是它们之间不同的一些特征：

>尽管PooledConnectionFactory和CachingConnectionFactory都声明它们是每个池连接,会话和生成器,但PooledConnectionFactory实际上并没有创建多个生产者的缓存.当请求一个缓存生成器时,它只需使用单例模式来发出一个缓存的生成器.而CachingConnectionFactory实际上创建一个包含多个生产者的缓存,并且在请求一个生产者时从缓存中移出一个生产者.

> PooledConnectionFactory构建在用于池化JMS会话的Apache Commons Pool项目之上.这允许对池进行一些额外的控制,因为Commons池中没有被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.

从here：

>如果您已经集群ActiveMQs,并使用故障转移传输,则已报告CachingConnectionFactory不是正确的选择.
>我遇到的问题是,如果一个盒子掉下来,我们应该开始
在另一个发送消息,但它似乎仍在使用旧的
连接(每次发送超时).如果我重新启动程序,它会的
再次连接,一切正常.资源：
Autoreconnect problem with ActiveMQ and CachingConnectionFactory>问题是缓存的连接到失败的ActiveMQ是仍然在使用,并为用户创造了问题.现在这种情况的选择是PooledConnectionFactory.>如果您今天使用ActiveMQ,并且有可能将来可能切换到其他代理(JBoss MQ,WebSphere MQ),请勿使用PooledConnectionFactory,因为它紧密耦合你的代码ActiveMQ的.