Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Polishing

Browse Source
This commit is contained in:
Juergen Hoeller
2014-09-29 23:50:23 +02:00
parent 49cf30e964
commit 7bc8e5199e
2 changed files with 72 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
spring-jms/src/main/java/org/springframework/jms/listener/DefaultMessageListenerContainer.java
View File

@@ -43,7 +43,7 @@ import org.springframework.util.backoff.FixedBackOff;
* Message listener container variant that uses plain JMS client APIs, specifically
* a loop of {@code MessageConsumer.receive()} calls that also allow for
* transactional reception of messages (registering them with XA transactions).
* Designed to work in a native JMS environment as well as in a J2EE environment,
* Designed to work in a native JMS environment as well as in a Java EE environment,
* with only minimal differences in configuration.
*
* <p>This is a simple but nevertheless powerful form of message listener container.
@@ -60,7 +60,7 @@ import org.springframework.util.backoff.FixedBackOff;
* abstraction. By default, the specified number of invoker tasks will be created
* on startup, according to the {@link #setConcurrentConsumers "concurrentConsumers"}
* setting. Specify an alternative {@code TaskExecutor} to integrate with an existing
* thread pool facility (such as a J2EE server's), for example using a
* thread pool facility (such as a Java EE server's), for example using a
* {@link org.springframework.scheduling.commonj.WorkManagerTaskExecutor CommonJ WorkManager}.
* With a native JMS setup, each of those listener threads is going to use a
* cached JMS {@code Session} and {@code MessageConsumer} (only refreshed in case
@@ -71,11 +71,11 @@ import org.springframework.util.backoff.FixedBackOff;
* {@link org.springframework.transaction.PlatformTransactionManager} into the
* {@link #setTransactionManager "transactionManager"} property. This will usually
* be a {@link org.springframework.transaction.jta.JtaTransactionManager} in a
* J2EE environment, in combination with a JTA-aware JMS {@code ConnectionFactory}
* obtained from JNDI (check your J2EE server's documentation). Note that this
* Java EE environment, in combination with a JTA-aware JMS {@code ConnectionFactory}
* obtained from JNDI (check your Java EE server's documentation). Note that this
* listener container will automatically reobtain all JMS handles for each transaction
* in case an external transaction manager is specified, for compatibility with
* all J2EE servers (in particular JBoss). This non-caching behavior can be
* all Java EE servers (in particular JBoss). This non-caching behavior can be
* overridden through the {@link #setCacheLevel "cacheLevel"} /
* {@link #setCacheLevelName "cacheLevelName"} property, enforcing caching of
* the {@code Connection} (or also {@code Session} and {@code MessageConsumer})
@@ -209,7 +209,7 @@ public class DefaultMessageListenerContainer extends AbstractPollingMessageListe
* of concurrent consumers.
* <p>Specify an alternative {@code TaskExecutor} for integration with an existing
* thread pool. Note that this really only adds value if the threads are
* managed in a specific fashion, for example within a J2EE environment.
* managed in a specific fashion, for example within a Java EE environment.
* A plain thread pool does not add much value, as this listener container
* will occupy a number of threads for its entire lifetime.
* @see #setConcurrentConsumers
@@ -262,11 +262,11 @@ public class DefaultMessageListenerContainer extends AbstractPollingMessageListe
* <p>Default is {@link #CACHE_NONE} if an external transaction manager has been specified
* (to reobtain all resources freshly within the scope of the external transaction),
* and {@link #CACHE_CONSUMER} otherwise (operating with local JMS resources).
* <p>Some JavaEE servers only register their JMS resources with an ongoing XA
* <p>Some Java EE servers only register their JMS resources with an ongoing XA
* transaction in case of a freshly obtained JMS {@code Connection} and {@code Session},
* which is why this listener container by default does not cache any of those.
* However, depending on how smart your JavaEE server is with respect to the caching
* of transactional resource, consider switching this setting to at least
* However, depending on the rules of your server with respect to the caching
* of transactional resources, consider switching this setting to at least
* {@link #CACHE_CONNECTION} or {@link #CACHE_SESSION} even in conjunction with an
* external transaction manager.
* @see #CACHE_NONE