深入理解CachingConnectionFactory

http://windows9834.blog.163.com/blog/static/27345004201311834632915/

深入理解CachingConnectionFactory  

CachingConnectionFactory类扩展自SingleConnectionFactory，主要用于提供缓存JMS资源功能。具体包括MessageProducer、MessageConsumer和Session的缓存功能。

public class CachingConnectionFactory extends SingleConnectionFactory {

 private int sessionCacheSize = 1;

 private boolean cacheProducers = true;

 private boolean cacheConsumers = true;

 private volatile boolean active = true;

 private final Map cachedSessions = new HashMap();

Spring中发送消息的核心是JmsTemplate，然而Jmstemplate的问题是在每次调用时都要打开/关闭session和producter，效率很低，所以引申出了PooledConnectionFactory连接池，用于缓存session和producter。然而这还不是最好的。从spring2.5.3版本后，Spring又提供了CachingConnectionFactory，这才是首选的方案。然而CachingConnectionFactory有一个问题必须指出，默认情况下， CachingConnectionFactory只缓存一个session，在它的JavaDoc中，它 声明对于低并发情况下这是足够的。与之相反，PooledConnectionFactory的 默认值是500。这些设置，在很多情况下，需要亲自去测试并验证。我将其设置为100，对我来说还是很不错

 

 

==============

http://singztechmusings.wordpress.com/2011/06/21/pooledconnectionfactory-vs-cachingconnectionfactory-which-one-is-a-perfect-match-for-spring-jmstemplate/

PooledConnectionFactory vs CachingConnectionFactory: Which one is a perfect match for Spring JmsTemplate?

 

JmsTemplate, part of Core Spring JMS framework, simplifies the use of JMS since it handles the creation and release of resources when sending or synchronously receiving messages. As discussed in this post – http://singztechmusings.wordpress.com/2011/04/24/problem-with-creating-jms-messageproducer-using-spring-jmstemplate-how-to-solve/ – we need to have pooling in place to make it efficient.

We’ve got two JMS provider choices: ActiveMQ‘s PooledConnectionFactory or Spring’s own CachingConnectionFactory

They’re meant for the same purpose – to pool Connection, Session and MessageProducer instances. But we need to consider a thing or two before deciding to use one of these:

1. If you have clustered ActiveMQs, and use failover transport (Eg. failover:(tcp://firstbox:61616,tcp://secondbox:61616)?timeout=30000), it has been reported that CachingConnectionFactory is not a right choice.

The problem I’m having is that if one box goes down, we should start sending messages on the other, but it seems to still be using the old connection (every send times out). If I restart the program, it’ll connect again and everything works.
Source: http://stackoverflow.com/questions/5916638/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.

2. 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.