哪个更好：PooledConnectionFactory或CachingConnectionFactory？

1 回答

• 34

  来自here：

  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还能够缓存消费者 . 使用此功能时需要注意，以便您知道根据博客文章中提到的规则缓存消费者 .

  • But most importantly, the CachingConnectionFactory will work with any JMS compliant MOM. It only requires a JMS connection factory. This is important if you are using more than one MOM vendor which is very common in enterprise organizations (this is mainly due to legacy and existing projects). The important point is that the CachingConnectionFactory works very well with many different MOM implementations, not only ActiveMQ.

  来自here：

  • If you have clustered ActiveMQs, and use failover transport it has been reported that CachingConnectionFactory is not a right choice.

  • 我遇到的问题是，如果一个盒子出现故障，我们应该开始在另一个盒子上发送消息，但它似乎仍在使用旧连接（每次发送超时） . 如果我重新启动程序，它将再次连接，一切正常 . 资料来源：Autoreconnect problem with ActiveMQ and CachingConnectionFactory

  • The problem is that cached connections to the failed ActiveMQ was still in use and that created the problem for the user. Now, the choice for this scenario is PooledConnectionFactory.

  • If you’re using ActiveMQ today, and chances are that you may switch to some other broker (JBoss MQ, WebSphere MQ) in future, do not use PooledConnectionFactory, as it tightly couples your code to ActiveMQ.

  回复于 2024-04-26T05:34:47+08:00