Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Appendix A. Optimizing Performance of JMS Single- and Multiple-Resource Transactions

Abstract

There are many ways you can optimize the performance of JMS transactions—both single-source transactions that use the resource's internal transaction manager and multiple-resource transactions that use an external XA transaction manager.

Optimization tips for all JMS transactions
링크 복사

These tips apply to both single- and multiple-resource transactions:
  • When working with Spring JMS/camel-jms, use a pooling-enabled Connection Factory, such as ActiveMQ’s PooledConnectionFactory, to prevent clients from reopening JMS connections to the broker for each message consumed.
  • When using camel-jms to do local transactions through an external transaction manager, configure the transaction manager to use a pooling-enabled Connection Factory.
  • ActiveMQ’s PooledConnectionFactory eagerly fills the internal connection pool, the size of which is bound by the maxConnections property setting.
    Each call to PooledConnectionFactory.createConnection() creates and adds a new connection to the pool until maxConnections is reached, regardless of the number of connections in use. Once maxConnections is reached, the pool hands out only connections it recycles. So different JMS sessions (in different threads) can potentially share the same JMS connection, which the JMS specification specifically allows.
    Note
    The PooledConnectionFactory also pools JMS sessions, but the session pool behaves differently than the connection pool. The session pool creates new sessions only when there are no free sessions in it.
  • A camel-jms consumer configuration needs only one JMS connection from the connection pool, regardless of the setting of the concurrentConsumers property. As multiple camel routes can share the same PooledConnectionFactory, you can configure the pool’s maxConnections property equal to the number of Camel routes sharing it.
  • For local (transacted="true") JMS transaction using the activemq component, duplicate messages can occur on
 failover from master to slave. To prevent this from happening, set the
 lazyCreateTransactionManager property to
 false. NOTE: Do not set this property to false for XA transactions

Optimization tips for JMS XA transactions
링크 복사

These tips apply to multiple-resource transactions only:
  • With XA transactions, you must use CACHE_NONE or CACHE_CONNECTION in camel-jms or plain Spring JMS configurations. As CACHE_CONSUMER is not supported in these configurations, you need to use a pooling-enabled JMS Connection Factory to avoid opening a new connection for every message consumed.
  • Configure a prefetch of 1 on the ActiveMQ ConnectionFactory when not caching JMS consumers to eliminate any overhead generated by eager dispatch of messages to consumers. For example, 
    failover:(tcp://localhost:61616)?jms.prefetchPolicy.all=1
    Copy to Clipboard Toggle word wrap
  • When working with JMS providers other than ActiveMQ, wrap the 3rd-party JMS drivers in the generic XA-aware JcaPooledConnectionFactory (for details, see Section 6.6, “Generic XA-Aware Connection Pool Library”). For example, to wrap a WebSphereMQ endpoint: 
    <bean id="FuseWmqXaConnectionFactory" class="org.apache.activemq.jms.pool.JcaPooledConnectionFactory">
  <property name="connectionFactory" ref="WMQConnectionFactory"/> 
  <property name="transactionManager" ref="transactionManager"/>
  <property name="maxConnections" value="5"/>
  <!-- note we set a unique name for the XA resource" -->
  <property name="name" value="ibm-wmq" />
</bean>
<bean id="WMQConnectionFactory" class="com.ibm.mq.jms.MQXAConnectionFactory">
  <property name="hostName" value="localhost" />
  <property name="port" value="1414" />
  <property name="queueManager" value="QM_VM" />
  <property name="channel" value="TEST" />
  <property name="transportType" value="1" />
</bean>
    Copy to Clipboard Toggle word wrap
    The wrapper provides the means for the Aries/Geronimo transaction manager to access and write the name of the participating WebSphereMQ resource to its HOWL recovery log file. This and other information stored in its recovery log file enables Aries to recover any pending transactions after a crash occurs.
  • Always declare a resource manager for each resource involved in an XA transaction. Without a resource manager, pending XA transactions cannot be recovered after a JBoss Fuse crash, resulting in lost messages.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat