public class CachingConnectionFactory extends SingleConnectionFactory { private int sessionCacheSize = 1; private booleancacheProducers = true; private boolean cacheConsumers = true; private volatile boolean active = true; private final MapcachedSessions = new HashMap();
Spring中發送消息的核心是JmsTemplate，然而Jmstemplate的問題是在每次調用時都要打開/關閉session和producter，效率很低，所以引申出了PooledConnectionFactory連接池，用於緩存session和producter。然而這還不是最好的。從spring2.5.3版本后，Spring又提供了CachingConnectionFactory，這才是首選的方案。然而CachingConnectionFactory有一個問題必須指出，默認情況下，CachingConnectionFactory只緩存一個session，在它的JavaDoc中，它 聲明對於低並發情況下這是足夠的。與之相反，PooledConnectionFactory的 默認值是500。這些設置，在很多情況下，需要親自去測試並驗證。我將其設置為100，對我來說還是很不錯
==============
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.
轉自：https://blog.csdn.net/caolaosanahnu/article/details/8617854