Improve Javadocs for DMLC Regarding JmsTransactionManager [SPR-9200]

[spring-projects-issues]

Gary Russell opened SPR-9200 and commented

A number of errors have crept into the DMLC Javadocs.

For example:

• setCachLevel() says that while the default is CACHE_NONE with an external txManager, it can be overridden. This is not the case because a new connection is obtained for each poll and bound to the thread.
• setTransactionManager refers to AMLC class Javadocs, which in turn imply that for downstream JmsTemplate within an @Transacted method needs the LC to have an external JmsTransactionManager.

"* The effect is similar to "sessionTransacted" set
 * to "true", the difference being that this external transaction management
 * will also affect independent JMS access code within the service layer
 * (e.g. based on {@link org.springframework.jms.core.JmsTemplate} or
 * {@link org.springframework.jms.connection.TransactionAwareConnectionFactoryProxy}),
 * not just direct JMS Session usage in a {@link SessionAwareMessageListener}."

In fact, even with sessionTransacted=true the session is bound to the thread via a LocallyExposedJmsResourceHolder and no external txManager is required and, if provided, precludes caching in the DMLC (CCF is needed).

It is now generally recommended that an external txManager only be provided if JTA is needed.

Suggest a thorough review of all Listener Container documentation regarding the use of JmsTransactionManager.

---

Affects: 3.1.1

Reference URL: http://forum.springsource.org/showthread.php?123631-JMS-DMLC-not-caching-connection-when-using-TX-despite-cacheLevel-CACHE_CONSUMER

Issue Links:

• Better abstraction for transactional configuration in DMLC [SPR-7879] #12536 Better abstraction for transactional configuration in DMLC ("is duplicated by")

Referenced from: commits 674bad4

[spring-projects-issues]

Stéphane Nicoll commented

Actually, the cache level works as advertized and can be overridden even when a transaction manager is present. That being said, as a general rule, it is best to fetch a fresh connection and session. Some JavaEE server may accept that extra tuning though.

Also clarified the role of sessionTransacted that can be seen as a (almost) full replacement of what used to be done by JmsTransactionManager.