Spring Integration多DefaultMessageListenerContainer与JMS出站适配器事务配置疑问

Hey there! Let's break down the key issues in your Spring Integration JMS configuration and walk through how to fix them step by step.

From your description, two critical points need addressing:

• Mismatched Connection Factories: Your DefaultMessageListenerContainer uses jmsConnectionFactory, but the platformTransactionManager relies on a different JMS connection factory. This will break transactional integrity for JMS operations.
• Missing CachingConnectionFactory: Without a cached connection factory, your listeners will create a new JMS connection/session for every message, leading to significant performance overhead in production.

1. Align Connection Factories for Transactions #

JMS transactions are scoped to connections/sessions created from the same ConnectionFactory. If your transaction manager uses a different factory than the listener container, the listener's JMS operations won't be bound to the transaction—meaning message acknowledgment or rollback won't work as expected.

Update your transaction manager to use the same connection factory as your listener containers:

<!-- Ensure the transaction manager uses the identical ConnectionFactory as listeners -->
<bean id="platformTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
    <property name="connectionFactory" ref="jmsConnectionFactory"/>
</bean>

2. Add CachingConnectionFactory for Performance #

Wrap your raw jmsConnectionFactory with CachingConnectionFactory to reuse connections, sessions, and consumers. This is a must-have for production JMS setups to avoid excessive resource creation.

Here's how to configure it:

<!-- Wrap your base ConnectionFactory with caching -->
<bean id="cachingJmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory">
    <property name="targetConnectionFactory" ref="jmsConnectionFactory"/>
    <property name="sessionCacheSize" value="10"/> <!-- Adjust based on your concurrency needs -->
    <property name="cacheConsumers" value="true"/> <!-- Cache consumers for listener containers -->
</bean>

<!-- Update listener containers to use the cached factory -->
<bean id="messageListenerContainer1" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
    <property name="connectionFactory" ref="cachingJmsConnectionFactory"/>
    <property name="transactionManager" ref="platformTransactionManager"/>
    <!-- Add your destination, messageListener, concurrency settings, etc. -->
</bean>

<bean id="messageListenerContainer2" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
    <property name="connectionFactory" ref="cachingJmsConnectionFactory"/>
    <property name="transactionManager" ref="platformTransactionManager"/>
    <!-- Your second listener's config -->
</bean>

<!-- Update the transaction manager to use the cached factory too -->
<bean id="platformTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
    <property name="connectionFactory" ref="cachingJmsConnectionFactory"/>
</bean>

3. Configure Outbound Channel Adapters Consistently #

For your <jms:outbound-channel-adapter> beans, use the same cachingJmsConnectionFactory to maintain consistency and performance. If you want outbound operations to participate in the same transaction as the listener, enable session-transacted:

<jms:outbound-channel-adapter id="jmsOutboundAdapter1"
                              channel="outboundChannel1"
                              connection-factory="cachingJmsConnectionFactory"
                              destination="outQueue1"
                              session-transacted="true"/>

<jms:outbound-channel-adapter id="jmsOutboundAdapter2"
                              channel="outboundChannel2"
                              connection-factory="cachingJmsConnectionFactory"
                              destination="outQueue2"
                              session-transacted="true"/>

To confirm your setup works correctly:

• Enable DEBUG logging for org.springframework.jms and org.springframework.transaction to check that transactions are bound to the same connection/session across listeners and outbound adapters.
• Test failure scenarios: Throw an exception in your listener logic and verify that the message is rolled back to the queue (no duplicate consumption unless you have redelivery policies configured).
• Monitor JMS resource usage: Check your broker's metrics to confirm connections/sessions are being reused instead of created on every message.

内容的提问来源于stack exchange，提问作者Yogesh Chavan