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();
The core message is sent Spring is JmsTemplate, however Jmstemplate question is to be open in each call / session and closed producter, inefficient, so come out of PooledConnectionFactory connection pool for caching session and producter. However, this is not the best. From spring2.5.3 version, Spring also provides a CachingConnectionFactory, this is the preferred option. However, there is a problem CachingConnectionFactory must be noted that, by default, CachingConnectionFactory only cache a session, in its JavaDoc, which declared for the low concurrency, which is sufficient . In contrast, PooledConnectionFactory the default value is 500 . These settings are, in many cases, need to go and test and verify. I set it to 100, still very good for me
==============
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.
Transfer: https: //blog.csdn.net/caolaosanahnu/article/details/8617854